(Original creator: miketaylor)
As many of you may be aware, we have - for some time - been working on the new version of Uniface, v10. As befits a major version increment, there are quite a few changes in the development environment, as well as to some of the concepts of Uniface. Today I would like to describe one such change, that should help to make development more obvious.
Inheritance, from model to component, has always been a cornerstone of developing an application with Uniface. The model contains the global definition and the component the external variation, the external variation taking a higher precedence over the model when coming to compile. Let’s examine this concept in a little more detail in the area of local procs.
Imagine, if you will, that when using version 9 you have entries defined in the Local Procs Module trigger of a modelled field, and that the field is painted on a component. When you compile and run the component, any calls you have made to the local proc will cause you to execute the entry defined in the model. Now, if you were to create an external variation of the proc and run the component again, you would expect external variation to be used. So given this, the external variation wins out over modelled procs, right? Well, no, not quite! If I were to now paint a new modelled field with yet another version of the local proc defined and lower down the compile order of the component, what happens could be seen as unexpected – the modelled proc of the second field would be used. If the order of compile changes, i.e. the second entity is moved on the component paint tableau, the module that is used could change. This was not the intended behavior. In version 10 the process has been made much easier to understand – the external variation always takes precedence. All model definitions are compiled before the external variations are overlaid. This change will mean that the compilation becomes far more predictable with less “magic” and mistakes.
There has been another improvement in compilation of local procs - they are now overlaid. Prior to version 10 you could have, in the model, many entries defined in a single trigger, and if you wished to make a change to just one of them in the component, you would have to break inheritance to them all. Effectively, you would duplicate your code into each component where this was the case. Although it is possible to simulate the inheritance using included procs, it can take quite a bit of planning to implement. With version 10 you are now able to overlay just a single proc module, leaving the inheritance for all others.
So how does this look in the component editor of version 10? The first thing you will see is that only the external variation code is displayed, not the modelled code. To enable easy navigation to all the code compiled into the component, a Compiled Module Information (CMI) panel has been added to the editor. It shows all modules compiled into the component. Double clicking on a module in the CMI causes a navigation action and you will be taken to to the definition of the code module – opening a new editor (entity, included proc, etc.) if required. This is a big time saver for the developer.