Wednesday, September 30, 2009

EMF Tips #3: Why should I want to generate editors?

I thought about treating you with more of those beautiful flowers in Ed's garden but there's still material from our trip to Toronto. Thanks to Dave (Dave, the book, not the Google Bear!) and Kevin for organizing cool downtown and clubbing tours. And for demonstrating how dynamic IBM really is. Thanks also to Lynn and Kenn for showing us Ottawa. Damn, from getting almost one finger between Toronto and Ottawa on the map I deduced that it might be an hour's trip. It is not! Canada is sooo big.


So, why should I want to generate editors for my models? Have you ever thought about this? Or are you politely generating these editor plug-ins, just because it's possible? Or fun?


You might remember that I have 28 models in my workspace. Let's, for a moment, assume I generated 28 additional editor plug-ins into my workspace. A lot of code to maintain and we should be absolutely sure that this is (a) necessary and (b) appropriate!


To judge if it's necessary to generate editors on a per-model basis we need to compare the generated code of two such editor plu-ins. Interestingly, it boils down to a single difference in the initializeEditingDomain() method where the ItemProviderAdapterFactory for the model is added to the ComposedAdapterFactory. More interestingly, the editor will continue to function properly even if you remove this model-specific line! The reason is that the ComposedAdapterFactory delegates to a registry of descriptors which are contributed to the extension registry by the edit plug-ins. You see, it's clearly not necessary to have a generated editor per model.


And usually it's also not appropriate to have vast numbers of editors that are all alike. Model editors are a means to implement functionality that is orthogonal to the models. Things like ordering of nodes and properties, changing colors, fonts and so on are achieved by customizing the editor. I really don't want to duplicate all these UI-related, i.e. model-independent, aspects over 28 editors! And don't forget, your model can be used in other generated editors (other than the one that has been generated for this particular model).


All we need is a single generated editor for all our models.


Eventually we'll need additional editors for additional UI-related requirements, but not for additional models. The same arguments are certainly valid for the generated wizards. One difference between the generated editor plug-ins that I did not talk about, yet, is the editor and wizard markup in the plugin.xml. Our reusable editor would at least have to be prepared that it can be associated with different file extensions, depending on the set of deployed model or edit plug-ins.

4 comments:

  1. You're absolutely right - as long as the user is happy with the generic, tree-like UI of the editor.
    But lots of RCP applications that are intended to be used in other domains but software development, require a more convenient (e.g. form based) UI.
    So to me there seems to be no other way than to manually implement a very model-dependent editor for every single model.
    What do you think?

    ReplyDelete
  2. Hi Mario,

    You're also right, I exclusively referred to the default tree structure editors and their genericity. And yes, in the real world there are often requirements for more specialized UIs that comprise multiple editors or views. Whether these are best created manually, or fully or partly generated from a model is certainly another religious battle. I suspect this UI world is just not black xor white. I've seen evidence of both approaches being successful, although I tend to prefer the generative approach at least for things like typical CRUD forms. I've not yet had the time to look closely at the new EEF component but it strikes me that it can be very helpful.

    ReplyDelete
  3. Hi,

    A partial answer to your wish may actually be developed by the MoDisco project (http://www.eclipse.org/gmt/modisco/). The MoDisco project goal is to provide a set of modeling tools to improve the model discovery tool box.

    One of these tools is a generic model browser which can be customized to modify the colors, fonts and labels. A first version of this browser is available on the MoDisco web site (http://wiki.eclipse.org/MoDisco/ModelBrowser) and a new version has been contributed as a bug report (https://bugs.eclipse.org/bugs/show_bug.cgi?id=291378).

    Unlike what you are expected the tool is only a browser (read only). The MoDisco project chose to focus their work on the reading aspect because the editing (write/modify) feature is not required in the model discovery activity.

    Do not hesitate to share your ideas and expectations with the MoDisco team.

    Regards,
    Grégoire

    ReplyDelete
  4. Hi Grégoire,

    Thank you for your tip. I hope that I can find some time to play with your browser. Although the read-only restriction does not sound too appealing if we want to edit the models ;-)

    ReplyDelete