Hi Thomas, Thanks for your interest :)
On Tue, Apr 29, 2008 at 9:00 AM, Thomas N. <[EMAIL PROTECTED]> wrote: > Hi Christian, > > welcome again here! Great idea to base the property panel generation on XMI! > Will the UML metamodel be the only input for the code generator, or do you > think that additional info has to be added, e.g. for layout? The layout info should be hand-written on a separate XML. Then a new XML can be composed, or both of them (per element) can be loaded and rendered. I didn't mentioned it yet on the list, but I intend to use some XML GUI engine like Jelly [1] or SwixNG [2], so we aren't really generating UI code. It seems I choose a bad title to the proposal. > If the latter is the case, then one could import the relevant part of the > XMI into ArgoUML, model these additional infos, and then the resulting XMI > will be useful for generating the whole property panel. Or did you plan to > add things during the XSLT transformation into the XML? IMHO, modifying the XMI for adding layout and positional info isn't a great idea. UML metamodel isn't an XMI that changes often, but we must maintain it on your own if we choose this approach, and it will become more complex. That's the reason for creating a new XML with that info. They'll be simpler, and modifying the rendering will be just changing some values in a simpler XML. We don't need to edit the XMI by hand. > What came into my mind is to use a MDA framework to get from XMI directly to > code in one step. AndroMDA can read XMI produced by ArgoUML. The AndroMDA > community knows us ArgoUML people, and there is documentation on writing > custom cartridges for code generation. One of the advantages (and the main reason) of my proposal is walk towards UML2, without forgotting about ArgoEclipse. AFAIK, if we want to generate Swing and SWT code, we'll need to develop two AndroMDA cartridges. Last time I looked at it, writing AndroMDA cartridges wasn't a simple task. With the other approach, if we opt for Jelly, we have a JellySwing and a JellySWT renderers, so this change will be a quick step. If we choose some XUL representation with an engine like SwixNG, there are a lot of XUL renderers, for Swing and for SWT, so it will be quick too. IMHO, we'll have a better ROI going through the XML-thing. Anyway, we can discuss about it, and hope that some more devs add their thoughts to the conversation. > It's just a quick idea, so if you prefer writing the XLST transformation and > a code generator for XML, just go ahead. > > Have fun! > Thomas > Thanks for the feedback!. [1] http://commons.apache.org/jelly/ [2] http://swixng.sourceforge.net -- Regards, Christian López Espínola
