What I like and expect in every well-designed system is an intuitive design and predictability. Can I find what I am searching for in the expected location? In other words, is the interface intuitive and consistent? The IDE of Uniface is. Everything that a developers needs is exactly there where you expect it.
That’s one of the best things about Uniface 10. Having worked with several earlier versions of Uniface, I can confidently say that this latest version’s user interface gives the developer unprecedented levels of consistency, predictability and effectiveness. The design of the IDE is clever and supports the Uniface paradigm. In this article I will explain the elements of the IDE on a high level.
The IDE on a high level
What I love and expect in every well-designed system is predictability. Can I find what I am searching for on the expected location? In other words, is the interface intuitive and consistent. I have been working with most previous versions of Uniface in the past and, as we know, the user interface Uniface 10 differs from its predecessors. Working with the new Uniface 10 Integrated Development Environment (IDE) is effective, especially when you experience the consistency in the product.On a high level the IDE can be split into three main sections.
As shown in Figure 1 these main sections are header, editors and message output. The last section, message output, contains the output of performed actions in the IDE. Pretty obvious, isn’t it. In this article I want to focus on the other two sections, because here is where the magic happens.
A Uniface developer works in the editors’ section. The IDE contains several editors. Let’s start with the understanding of these.
Main development objects and their editors
Uniface has introduced the term object in version 10. It’s a generalization of the ‘things’ developers create and use, like projects, components, fields, etc. An object is a way for developers to communicate about their work without the need to know the implementation in detail. In the article ‘About templates, models and objects’ I have described this in more detail.
Objects can be nested as parents and childs where some objects, like fields for instance, can only exist as a child of a parent. Main development objects can exist without a parent and can have childs. Modeled entities, start-up shells and projects are examples of main development objects
All main development objects have a dedicated editor in Uniface 10. The objects that can only exist as a child of another object can only be maintained in an editor that is created for their parent. For instance, an entity painted on a component is the child of that component.
It’s important to understand the difference between an entity created in the entity editor, which is called modeled entity and an entity that is painted on the component in the component editor, which is called a derived entity.
Uniface has a specific editor for every main development object. In the non-modal development environment, a developer can work on several objects in the same environment. Every opened editor is identified by a tab.
Scope of your action
I started this article with the predictability of the IDE. In the previous paragraphs I explained that Uniface has an editor for every main development object. The daily activities of the Uniface developer are actions like create new components, modify properties of objects, write script code, compile components, etc. Some actions will be started from the IDE header, others in the editor section. To find the location of the ‘action’ you want to do in the IDE, it’s good to realize the scope of your action.
- Does it do ‘something’ with exactly one opened object? It will be in the editor of that object.
- Does your action involve more than one object or is not particular meant for an object in an opened editor? It will be in the header.
The short version. The header contains ‘global’ actions, while the editor contains actions for the content of the editor.
A few examples:
Compile all components in the repository. This is an action that is not bound to exactly one opened component. This compile action can be found on the main menu in the header.
Compiling a component. This is an action for an opened object in the component editor, so it’s to be found somewhere on the editor. Of course, it is also possible to compile the same component from the compile option in the header. The result is the same.
Export all child objects from a project. The boundary of this action is the project’s content. Therefor it is to be found in the projects editor.
You can actually draw an imaginary line between the header and the editor section. Everything that has something to do with one particular object is somewhere below that line.
Let’s focus on this editor section. Most editors in Uniface 10 have been completely rebuilt. Some of the less used objects, for instance the maintenance of glyphs and keyboard translation tables, still use the U9 editors. Due to Uniface’s continuous delivery these editors will be migrated to the new structure. Every experienced Uniface developer will recognize these immediately though.
Every worksheet contains one or more tools. These tools depend on the editor and the worksheet. A typical worksheet composition has a resource browser on the left, the properties inspector on the right and a large tool pane in the centre. In this pane the actual editing work is done. In this container the developer can, for instance edit the script, define the keyfields of an entity or compose the structure of a service component. The general structure in the IDE is: editor → worksheet → tool.
Let’s take the shown editor in Figure 2 as an example. This is the modeled entity editor. The active worksheet is the Define Structure. On this worksheet the left pane contains the ‘Resource Browser’, in the middle the ‘Fields Composer’ and on the right the ‘Properties Inspector’.
User Defined Worksheet
Zooming in on the worksheet tabs, something interesting I want to show you.
In Figure 3 the Uniface default worksheets are shown, but next to them are my own worksheets. In another article ‘Enhancing the provided toolset’ I wrote about these. These worksheets can be added to the Uniface editor(s) you prefer and make your work as Uniface developer even more efficient. The worksheets offer great flexibility and strength. In your own worksheet(s) you are not bound to the tool panes Uniface is using and there are no boundaries in the scope of your actions. You, the developer, are completely free to add a worksheet that performs actions outside the opened object, but it is advised to take the context of the object into consideration.
The IDE of Uniface 10 has the predictability I expect because it is a consistent implementation of the Uniface development paradigm. Uniface 10 is built by developers, for developers. It makes sense, common sense.
I can talk and write about the IDE for hours, but the best advice I can give is: just use it. I am convinced that you like it, just like I do.
This article is published on the Uniface Community website: https://community.uniface.com