Couldn't the E4WorkbenchModelEditor be derived from the underlying ECore model?

[r-mennig]

Currently the E4WorkbenchModelEditor and all of its embedded editors in org.eclipse.e4.tools.emf.ui.internal.common.component (over 40 different classes) are hand coded and manually maintained.

On the surface it seems like it would be possible to derive all of the visual editing facilities from the underlying Ecore model (e.g. generating the possible tree items from the EClasses and the text boxes from EString attributes and so on).

Are there any (maybe historic) reasons why the editor was not designed this way?

[merks]

I think purely for social reasons folks are more inclined to write things by hand than to generate them, especially people from North America where Modeling is kind of frowned upon for no apparent good reason.

[HannesWell]

Are there any (maybe historic) reasons why the editor was not designed this way?

I don't know any (but I'm also not deeply familiar with that part of PDE).
But I'd say, try to convert it and if it works till the end I'm happy to have less handwritten code in PDE.

[merks]

Well, yes. keeping in mind that then you need to development a generator and you need to build and maintain said the generator, all with the hope that this produces better more maintainable results long term. Maybe it's just water under the bridge at this point given the model is really quite stable.

[merks]

Note that EMF Forms was focused on such a topic, but it's kind of not so much supported anymore.

[r-mennig]

I understand that a full redesign of the editor would be too much work for too little benefit right now.
But maybe a step towards such a design could be achieved by creating common abstractions for displaying certain data types?

For example, both blocks in the following snippet (taken from org.eclipse.e4.tools.emf.ui.internal.common.component.PartDescriptorEditor) create a similar UI representation (label + checkbox) of a boolean value, but use no common abstraction to do so.

[merks]

If you with to do some refactoring to make the editor more functional or even just more maintainable with less duplication, I see nothing that speaks against that. Quite the opposite, I think it would be a very good thing and would be appreciated.

[vogella]

From memory: The e4 model editor has much more functionality than the generated EMF editor, e.g. wizard integration, extra validation and a nicer UI and better UX. It is basically a tailored editor vs a generic generated one.

Stuff like:

• Display of images
• Translation strings are displayed
• Extract model fragments
• Less technical names
• Type-specific form editors per element (Window, Part, Command, KeyBinding, ...) instead of a generic reflective tree.
• List tab with filtering/sorting and a live XMI source tab.
• Fragment and snippet editing support.
• Contribution URI validation and PDE-based class/extension lookup.
• Duplicate-ID / label detection and repair handlers.
• CSS styling fields in the forms.
• Undo/redo via the EMF command stack.
• Resource-change listener for external edits.
• Filtered tree for large models.

[merks]

The question wasn't "why not use EMF's generated editor" (which definitely is not rich, specialized, and beautiful like the hand-written e4 editors) the question was "would be possible to derive all of the visual editing facilities from the underlying Ecore model".

I do expect that if you can hand write it, you can develop and tool that can generate it:

https://eclipse.dev/ecp/emfforms/

An important question now is whether it it worth the effort to develop such a generator and redo all the hand written code for a code base that is extremely stable?

[r-mennig]

Thanks @merks for the clarification.

What I meant was not to redesign the editor to just support what would be describable by ecore but for the editor to provide various visual editing capabilities based on the information contained in the model.

Such a design would enrich model-specific information (what editor exists and what values should be displayed) with model-independent functionality (image display, hyperlinking, undo/redo, search functionality, live XMI preview, ...).

The current design has no mechanism to react to model changes. If a new subclass of MenuElement were to be added to /org.eclipse.e4.ui.model.workbench/model/UIElements.ecore, the E4 editor would need manual adaptions in order to create such elements via the editor. With a generator-based design, only model changes which would require new UI functionality (like displaying a new EType) would require changes to the generator. Other model changes would just require a re-run of the generator to produce the updated E4 editor.

[merks]

Well, I'm the generator dude so I know there is much value in that approach. It's also often the case that whatever you can generate, you can instead do dynamically on the fly based on the same model information; that's often a little less readable/obvious but less duplicative.

[r-mennig]

Sure, such a design would work even better (as long as the on-the-fly calculation of the UI elements can be implemented in such a way that it would not add too much overhead when opening the editor)!