Hello, > I have created a http://fornax-platform.org/cp/x/tgc Sandbox page where we > can put any ideas that would help in development of Sculptor. Do you need > permissions to edit in the wiki you can contact > http://fornax-platform.org/cp/display/fornax/How+to+participate Thorsten by > email.
many thanks. I think after the discussion when we know which path to take, I will update the page to reflect what we have agreed upon. > I have described a few things about the gui metamodel in the sandbox page. I > hope it answers some of your questions. Let us know if we should describe > anything more. Yes, it helps a lot. Especially the description of a Flow. When thinking about a classical Web GUI, it is natural to think of Flows, which are necessary to gather different pieces of information in form of sequences of web pages (possibly one single page) and confirmation pages to give feedback to the user. This kind of GUI is mainly driven by the nature of http, being a stateless protocol and the possibilities of stock html/xhtml and forms. In my opinion, this is 'degenerate' kind of GUI, as in rich clients, there are much more immediate ways of gathering the needed user input and giving feedback to reassure the user that the desired action has taken place. Just think of incremental update of a 'normal' UI, status bar messages, pop up message boxes etc. However, there must be a (meta-) model of the principles which stand behind a certain technological incarnation of a GUI which would make it possible to describe the UI independent of the technology which is used. While searching the web for some ideas on this issue, I found the works of a group at the Univ of Dresden who use MDSD to create a CRUD GUI for DB apps: http://dbs.informatik.uni-halle.de/GvD2006/gvd06_habich.pdf Lars Bilger has written an AndroMDA cartridge by conceptually going down the same route as Sculptor: he has a domain model which is enriched by some additional information which is used for code generation. The title of his work is "Modellgetriebene Generierung von Eclipse RCP Oberflächen zur Stammdatenverwaltung". I don't have a link at hand. Another group at the University of Karlsruhe have a very detailed view of the mechanisms of a UI and how to apply MDSD to it: http://www.cm-tm.uka.de/CM-Web/07.Publikationen/%5BLS+08%5D_Focusing_Graphical_User_Interfaces_in_Model-Driven_Software_Development.pdf http://www.cm-tm.uka.de/CM-Web/07.Publikationen/%5BLS+07%5D_Modellgetriebene_Entwicklung_von_grafischen_Benutzerschnittstellen.pdf What I like here, is the generality of the approach, they have - a GuiActivityProfile which describes a UI interaction from a very abstract perspective as an activity diagram with some special stereotypes: a) GuiInputPin represents necessary input from user but neither in terms of language level types, nor as elements of the concrete GUI library, but as abstract UI level types (e.g. they distinguish 'Text' and 'Secret' which could map to a PasswordField) b) UserAction has to be performed by the user (enter a value) c) SystemAction is performed by the system (a controller/service call, a calculation based upon the values entered by the user, some validation etc.) - a GuiProfile which describes user interface elements commonly found in UI toolkits or libraries Given these 'simple' ingredients, it is possible to describe even complex UIs which are more complex than a simple CRUD GUI in an abstract manner (at the level of an activity diagram). That model is then transformed to the still platform independent model described with the GuiProfile by mapping the GuiInputPins to UI elements and the actions to appropriate method calls. At the next step, the model is transformed to a platform specific model of e.g. Swing UI elements. And the last step consists of code generation. The ideas presented are very sound and I think they are easily implementable given the oAW/Sculptor tool chain. I don't think that we will get there immediately; and I don't think that it is necessary to have all degrees of freedom right from the beginning. I just have the impression that it'd be very good to honour prior art where it exists and conceive the metamodel in a way which leaves the way open for such extensions which we might introduce in future. So, my conclusion would be that we need not only one metamodel but - one metamodel and DSL which would cover the activity part of the UI interaction which would have a very simple structure and basically translate the GuiActivityProfile into a simple DSL - one metamodel and DSL which contains UI elements with abstract vocabulary - for each view technology, we would have a 'sub-cartridge' which would translate the GUI PIM to the PSM of that view technology and then into code > However, you are welcome to develop your stuff inside the Sculptor project > and commit to our subversion tree. I think that would simplify our joint > effort and we can help you easier. Rich client support is definitely > interesting. I have a lot of experience of it (Swing though). Many thanks for the invitation :-). I will start working on this tomorrow. In the meantime, could you please read the uka.de papers I cited above and give some feedback on what you think. Thanks Kambiz ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Fornax-developer mailing list Fornax-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fornax-developer
