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.

Tuesday, September 29, 2009

EMF Tips #2: Tweaking my Genmodel

The major part of this month I've been on vacation in Toronto and spent a wonderful time with René, Ed and Frank. Ed's garden is as beautiful as one might expect and I was busy collecting evidence of that.


Too busy to keep up with my EMF Tips blog series. In part #1 we discussed ways to easily generate multiple models. Thanks for all the helpful comments.


This part focusses on tayloring and tweaking the outputs of a single generator model. The default Genmodel properties lead to generation of four plug-ins: model, edit, editor and tests.


We will always need the model plug-in itself but often we don't need all of the other three outputs, so how do we exclude particular plug-ins from generation?


The Genmodel has a properties category for each of the output plug-ins: Edit, Editor and Tests. Completely switching off the generation of any of these is as simple as deleting the respective Directory property.


The generator UI will immediately reflect this by disabling the respective Generate menu item. Even the Shift+Alt+G dialog from tip #1 will adjust accordingly.


The next part of this series will focus on the interesting question "Why should I want to generate editors?". For now, you'd know how to avoid it. Stay tuned.


I was just told that there are still three seats available for the Eclipse Modeling Code Camp training that Ed and I will be giving next month (starting October, 12th) in Munich. Don't miss this great opportunity to spend four days with us and become

the world's greatest modeler!