Uniface: Templates, Models, and Objects – What’s What?
As an experienced creator of software solutions (sounds better than “software developer,” doesn’t it?), I spend most of my time in Uniface’s Integrated Development Environment (IDE). In the latest version 10, terms like “template,” “model,” and “object” pop up in nearly every editor and in the documentation. They must be important! But what do they actually mean? And, more importantly, what’s the difference? Spoiler alert: it’s all about layers of abstraction.
At the end of the development process, there’s a user eagerly waiting for the application. This application is the result of a fantastic process, in which you, the software developer, play a critical role. In the IDE, you mold and shape your components until they’re ready for deployment. The final product consists of one or more compiled components, such as Forms (FRM), Services (SVC), and Dynamic Server Pages (DSP), plus an Application Startup Shell (APS) and some assignment files. But let’s face it—99.99% of the application you deliver is comprised of compiled components.
Outside of Uniface, I’m a fan of woodworking. In my workshop, tools are hung neatly on the wall, and the workbench holds only what I need for the project at hand. I even have a set of molds under the workbench to save time when repeating certain shapes. These molds aren’t part of the final product; they’re tools that help me work efficiently.
Similarly, Uniface’s IDE is your workshop. You have a variety of tools at your disposal—and templates. Need an edit box on a Form? There’s a template for that. Need an entity? There’s a template for that too. Templates in Uniface are molds you use to make copies of specific “objects.” (I’ll get to “objects” in a moment.)
Metaphors often fall short on the details, and here, woodworking and IDE development diverge. In woodworking, molds are optional helpers, while in the IDE, templates are essential for creating components. Every component you deliver to the end user is a collection of templates.
Components: Collections of Templates
So, every component is essentially a collection of templates—or more precisely, copies of templates. These copies can be adjusted, with properties that affect appearance and behavior. But what if you want to reuse these customized properties? Wouldn’t it be even better if there were a connection between a template and its modified copy in the component?
As any Uniface developer knows, this idea of inheritance from a model is a core feature of Uniface. Adjustments in the model directly impact components that are derived from it. This has been the reality for Uniface developers for years.
However, in the past—up to Uniface 9—terms like “model” and “template” were often used interchangeably. Starting in Uniface 10, these terms were given clear definitions and applied consistently. Now we have Development Objects, Models, and Templates. But what exactly is what?
Development Objects
The IDE is the Uniface developer’s workshop, with everything you need to build components.
Let’s start with the basics: Development Objects. After years of working in Uniface, I thought I’d seen it all, but “Development Object” was a new label introduced in Uniface 10. Essentially, a “Development Object” is a general term for everything we work with: fields, entities, menus, properties, components—you name it. They’re the building blocks we create and manage in the IDE. Simply put, a Development Object is anything you can assign a value to, change properties of, and save in the repository.
Most Development Objects have a parent. For instance, a field can’t exist without an entity, and a menu needs a library.
Development Objects can be nested. A component contains at least one entity, an entity can contain inner entities, and entities contain fields with properties and behavior. Look at it the other way around: fields with their properties and behaviors “belong” to an entity and can’t exist without it.
Some Development Objects, however, have no parent at all—components and application shells, for example. These are called “Main Development Objects” because they exist independently. Since each “Main Development Object” lacks a parent but still needs to be defined, each one has its own dedicated editor in the IDE.
Components
A component is a type of Main Development Object, combining behavior and, optionally, appearance. Components are what ultimately get delivered to the end user. Specializations of a component determine its final output, such as Form, Service, or Dynamic Server Page. For this discussion, the specifics don’t matter much, though.
Templates
As mentioned, every component is a collection of copies of templates. But this applies to every “Development Object” within the IDE, not just components.
When you use a template in a component, you’re actually using a copy of that template. This copy becomes a “Development Object.” Whatever happens to the original template later on, it doesn’t affect the copy. In other words, there’s no inheritance between the template and the copy.
Modeled Objects
Sometimes it’s useful to have a (technical) relationship between a template and its copy—the Development Object. That’s where Uniface’s Model comes in. A Model acts as an intermediate step between a Template and a Development Object. A Model is a copy of a Template but can also serve as the foundation for a Development Object.
There’s a (technical) relationship between a Model and a Development Object, meaning any changes made to the Model’s behavior or appearance will be inherited by the Development Object.
A Model is created and maintained in the IDE, making it a Development Object in itself. The term “Derived Development Objects” is sometimes used to describe objects derived from a Modeled Object, though developers often just refer to entities, fields, components, etc.
Abstraction
In Uniface, abstraction is the name of the game. Templates and modeled objects help developers create development objects, but here’s the kicker: templates are even more abstract than modeled objects. The key difference lies in inheritance
From Modeled to Derived Objects
Let’s illustrate with an example. Imagine an application with various components and database tables. From a business perspective, the data is central; the application exists to serve it. To ensure data consistency, Uniface developers define modeled entities. These entities have fields, keys, and relationships, all defined in the model layer. This approach allows developers to use data within components without worrying about database implementation.
This is Uniface’s strength! Once a modeled entity is used in a component, it becomes a derived entity, and its fields become derived fields.
Modeled entities and fields, along with templates, are daily tools for Uniface developers. Uniface 10 enhances model usage throughout the IDE, with templates and modeled objects present in every step of development, simplifying life and speeding up development.
Using modeled objects as much as possible is simply logical. If you want a model-driven approach to Uniface application development, models are essential.
And if, after reading all this, you think, “What’s new?”, you’re not alone. In fact, nothing has changed in this concept since the early days of Uniface. It’s the terminology—not the day-to-day practice—that has evolved.
Originally published on the Uniface community website: https://community.uniface.com
