Hi John,

Welcome to Uniface 10! 🙂

The rule in Uniface 10 is:

• An object created from a template is a copy of that template. So, no inheritance. 
• An object created from a model is derived from that model. There is inheritance

A big difference between Uniface 9 and 10 is that the script container of the IDE only shows the script modules that are defined in the object, either by the developer (typing) or copied from a template.

As soon as you compile the component the IDE shows a list of all modules that are going to be 'used' by the object. This includes all modules that are derived from the model. So, you don't see the modules in the script container, but in the CMI (the frame at the right side of the script container).

Double click on the name of the module in the CMI will open de editor of the model. To make an external variation of a proc module, just specify a module with the same name  in the object.

So, an example.
Let's assume you want to create a FRM component from a modeled object. The form is called: myForm. The modeled object is called: ourFormModel. A form is Main Development Object. That means it has a dedicated editor.
In the modeled form component, so ourFormModel, you have defined an execute operation, an operation called operTest and 2 proc modules (procLoad and procSave).
Once you create the form myForm from this modeled object is does not show any of these proc modules.
After compiling the CMI shows: operation Execute, operation operTest, entry procLoad and entry procSave.
In the tooltip of the names of the modules in the CMI you can see that they are inherited from the modeled component. Double click will open the editor of the modeled object ourFormModel.
Now create a entry procLoad on the form itself. After compiling the CMI should show a different icon and a tooltip explaining the inheritance is lost.

I have write an article about this: About templates, models and objects

Bottomline is: 

• Template → copy (NO inheritance, so everything is copied)
• Model → derive (inheritance)

It does not matter if the object is a field, entity, component, signature, etc. In the whole IDE it works on every 'level'. Very consistent!

Hopefully that explains a bit about this subject.  

If you have any questions, don't hesitate to ask 🙂

regards, Peter

Hello Peter,

Thanks for your comment.

If the derived component is a copy of the modeled component I would expect the script in the modeled component being copied as well. For instance in the modeled component I have an operation called csEvent with some basic code, then after deriving a component from that modeled component I would have that exact same operation csEvent for the developer to use. The only thing I see in the derived component is an empty declarations and empty script.

In our modeled components we have a lot of places where a developer can change the behavior of a derived component, like compile time constants which have to be filled in to tell the component which other components have to be started and operations to influence the behavior of the functionality of a standard modeled component.

Although I like the concept of the script container to be as clean as possible because all code is now put in the same script container which makes in my opinion the readability a fuzz. Luckily it is now possible to collapse the script for an operation.

Regards, John

Hi John,

A derived componet is NOT a copy of the modeled component. It is important to use the terminology with care: a component derived from a model is NOT a copy.

In the component you only see the procscript that is actually IN the component. 

So, in your example, the operation csEvent is NOT in the component. It is derived from the model. In the CMI you can see this operation. You can even open the editor with this operation in the model. That is the whole idea of the difference  between model and template. 

In the component you only see the local variations. In U9 you could not really see the difference between something that came from the/a model or was a local variation. Now, it is very clear.

The idea behind is that the modules in a model do not need any modification, only in rare situations.  Less distraction, reuse code, etc. When a developer must modify modules in derived by rule, it might be beter to reconsider the use of a modeled object. It is possible to create your own set of templates, these will copy instead of derive. 

regards,

Peter

The original question was not answered: "Is there a way to mark scripts that should be copied to the derived component so the programmer immediately can see what he can change to create the functionality he wants?"

I was discussing this same topic with a colleague last week. While I think the implementation of modeled code is more "correct" than it has been in the past, I disagree with the ease of access leading to ultimately change of the modeled code. To make a change to the modeled triggers of an entity in U9, I would have to traverse a pulldown menu structure to navigate to the area I needed to be to change it. In U10, I double-click on an item in a list of modules and if I happen to click on an entry that is only defined in the model (and not the component) then a new tab is opened and my cursor is ready to start editing. The danger I see in this is obvious and I think we can all see this happening.....someone is going to think they are editing the code in the component and not the model because we are all used to typing our code and hitting compile. While I would normally say that it's always better to accomplish the same amount of work in less steps, this particular decision for quickly allowing the editing of modeled code is more risk than reward.

I've been using Uniface for a very long time and will say that the transition to Uniface 10 is bittersweet. While I'm enjoying some of the improvements to the development environment, it hasn't come with its own set of trade-offs. That being said, I think there is a happy medium that could be worked out that allows the developer to see the code that will be executed in the component without giving them immediate access to edit it. I hope this is well-received and understood by those in the lab because there will be pockets of developers across the world that will continue this discussion in one shape or another as more transition to Uniface 10. In my opinion, the current version is more risk prone and a better version could give John what he's asking for and still be technically better than how it works in Uniface 9.