Introduction
The repository is a feature of the SmartFramework supporting the definition, storing and retrieval of user interface and backend objects such as screen layouts or the schema of dynamic business entities. The SmartFramework provides tools to define the structure of object types (classes), their attributes and inheritance and relations (links) in the repository and to edit objects (masters) and instances of objects.
Basic structure of the SmartFramework repository are an evolution of the Progress Dynamics Repository (a development framework developed but no longer maintained by Progress Software). The structure in which classes (object types), objects (masters) and object instances and their attributes and relations are stored is conceptually similar to the Progress Dynamics Framework. The database schema of the Progress Dynamics repository has been adopted to our naming schemes. During the design of our repository, we have dropped some repository features not relevant and added some missed features such as the ability to have instances in a container contained in another instance (such as a group box in a viewer).
Repository based user interfaces are realized (rendered) at runtime using the regular frontend components of the SmartComponent Library.
User interface flexibility
We support rendering of user interfaces from the repository both to GUI for .NET and Angular based web and mobile applications. It is possible to render the same user interface to both user interface technologies or alternatively just to share selected objects (like a Viewer) in a container layout (Form). Customers or partners have also used the SmartFramework repository as the foundation for their own user interfaces.
The GUI for .NET user interface was the first UI technology implemented in the SmartComponent Library product. This is based on the ABL’s ability to utilize .NET Forms and Components for user interfaces. The user interface behavior is mostly implemented in ABL. In GUI for .NET we support screens mixed from static ABL .NET user controls (such as SmartViewers or custom user controls) and repository rendered components.
Angular web user interfaces utilize the SmartComponents for Angular product (SCLNG). This features a similar set of logical components as the GUI for .NET user interface. This user interface technology is based on the most recent version of the Angular framework for web applications and was initially developed based on AngularJS. The rendering process is based on a JSON markup defined by us. Like in GUI for .NET we support rendering screens that are based on a mix between static Angular components (HTML templates) and rendering based on our JSON markup. The JSON markup can be retrieved at runtime from the repository services running on the Progress Application server or be statically embedded into the Angular application.
The mobile Angular application we support are based on the NativeScript open-source product initially developed by Progress Software’s Telerik division. This product shares parts of the code-based of the SmartComponents for Angular product (SCLNG). Rendering of screens can also be based on our own JSON markup – which is the same markup as used in our Angular for web applications.
For designing applications based on these user interfaces we have the choice of using the dedicated tooling provided for those platforms or we can use the repository of the SmartFramework.
The tooling provided specifically for the different user interfaces consists of components like the GUI for .NET Visual Designer which is embedded into Progress Developer Studio for OpenEdge. During the development of the SmartComponent Library a primary design goal was the ability to set the majority of the configuration options in the Visual Designer.
For Angular based screens we can use our components in standard HTML templates, another primary design goal we have focused on. In modern web frameworks such as Angular a WYSIWYG screen designer is not a standard feature of the platform.
This mix allows developers to mix and match repository-based user interface components and static components as needed.
One of the benefits of the repository is that we can provide a consistent set of tooling for designing screens for GUI for .NET desktop applications, browser based applications and NativeScript mobile applications. We can also share the UI definition across all the target user-interfaces where feasible (taking different device and screen-sizes into account). Our own visual designer for repository based screens support designing screens and components that are rendered to all our supported user interface technologies. So, we do also close the gap of the missing Angular screen designer with our tooling.
Why do we still support screen components in the native platform? Typically, when using a repository for building screens, you will experience that for most of the screens – typically standard inquiry and data entry screens – are a good fit for the assumptions that were the foundation for designing the repository structures and rendering process.
But most applications will have screens or components that don’t fit into such a standardized pattern. This may be the case for screens such as a specialized dashboard or planning screen. But also, singleton screens like the application login screen are typically one of their kind. In business applications certain screens may have specific filter requirements, where there is very specific behavior implemented in the filter component. Components like that may be easier to implement outside of the repository tooling in the Visual Designer or your favorite Angular editor. This mix of repository based and static user interface offers a much bigger flexibility for developers.
For screens build in the native tooling and typically represented in source code we are using the term static screens. For repository based tools we are using the term dynamic screens.
Everything is Meta…
When we have designed the SmartFramework repository structures using tools as the soon to be introduced Attribute Maintenance or Object Type Maintenance we have deviated from our widely used naming prefix “Smart”.
We have done that to avoid confusion with our static component based classes such as “SmartViewer” or “SmartDataBrowser”.
We have chosen the term “Meta” as the naming prefix. So in the repository we’re building applications based on components like the “MetaViewer” or “MetaGrid”. We have chosen not to use the term “Dynamic” as the prefix as that might also be associated with the Progress Dynamics framework.
The Meta Components follow a class hierarchy maintained in the SmartFramework repository:
