As an experienced software solutions creator (sounds prettier than ‘software developer’, doesn’t it?), I spend most of my time in Uniface’s Integrated Development Environment (IDE). The latest version 10 mentions template, model and object on nearly every editor. I think it’s important to know what they mean and to understand the difference between them. Spoiler alert: it has something to the level of abstraction.
Let’s start with objects. I use Uniface to develop and deploy applications for many years and I know the ins and outs of Uniface, but I have never seen something which is called an object.
An object is a generalization term for things you and I work with every day. Anytime you read the word “object” you can replace it with anything you know in Uniface, like field, entity, menu, property, component, etc. These specializations are implementations of objects and are categorized as development objects. Development objects are created and maintained in the IDE.
Specialization and generalization
Some development objects have parents. A field can never exist without an entity and it’s impossible to define a menu without a library.
Development Objects can also be nested. For instance, a component contains at least one entity and an entity contains fields. The other way around: the fields have the entity as their parent and the entity has the component as its parent.
Development objects that don’t have a parent, like components and application shells are called main development objects. Main development objects have a dedicated editor in the IDE.
In the Uniface world, it’s all about the level of abstraction. Templates and modeled objects help you create your development objects. Templates are used to create both objects and modeled objects. The biggest difference between a template and a modeled object is inheritance. This is shown in figure 1.
The template is the most abstract level, while an object is concrete.
Anything created from a template has no inheritance from that template. A change in the template does not affect the (modeled) object at all. The (modeled) object is a separate copy from the template.
Uniface delivers a set of templates you can work with, but you can also create your own. In the new Uniface 10 development environment, the first thing a developer does is create a repository which will be based on templates. The first time Uniface is started, the developer must specify and load a set of templates. This can be the default Uniface set or a tailormade set of templates. But once loaded in the repository, they are static, they are not development objects.
Modeled objects are a kind of templates, but they are created and maintained in the current development repository. This means they add dynamics to the templates.
A modification made in the modeled object is inherited in the object based on it. This is the inheritance that we, Uniface developers, have known and used for many years.
Template or model
For us, Uniface developers, it’s common practice to define a modeled representation of the structured data in entities and fields. As soon as these modeled entities and fields are ‘painted’ on a component they become derived components. We know and trust that all properties and script are inherited from the model. That’s what makes Uniface so efficient. And that is why you and I use Uniface.
Let’s picture the template, model and object as layers and forget about the specialization of the objects for a minute.
According to the figure every object is a copy of a template. The model layer adds inheritance, but this is optional.
Every part of your development object is in fact based on templates. Every component, entity, field, etc is a copy of a template. If you want to save development time or enhance maintainability you add inheritance to properties or coding by adding a modeled object layer for these objects.
From modeled to derived objects
A small example to illustrate the above. An application has a few components and a couple of database tables with fields. From a business perspective the data is most important; the application is there to serve the data. To ensure the consistency of the data, it’s normal for us, Uniface developers, to define modeled entities. These modeled entities have fields, keys and relationships; all of these are modeled too. This model allows the developer to use the data on components without the need to know anything about the implementation of the database. This is a major strength of Uniface! Again as soon as a modeled entity is used on a component it is a derived entity and used fields are derived fields.
In case of the modeled entities and fields, every Uniface developer uses templates and models daily. Uniface 10 has enhanced the use of models through the whole environment. It’s up to the developer to use this concept. Templates and modeled objects are present on nearly every stage of the development process, they make lives of developers easier and efficient.
Using modeled objects as much as possible is a logical. When you want to take a model-driven approach to Uniface application development, using models is a must!
This article was published on the Uniface community website: https://community.uniface.com