Hi, Alright, that was a lot of information. I'll try to break down my reply as good as I can. First, a few words about our approach on bringing sculptor forward. We have throughout the development always worked in TDD-manner in that sense that we pinpoint a need, implement it, and when we see some abstractions, code duplications, improvements, etc, we refactor.
Well, yes, it is the 'http'-approach. It has the advantage of being very simple, and it was a nice start for us when deciding to do a CRUD GUI. I agree with you that it doesn't fulfills the needs of full fledge rich client. And for sure, we want to move in that direction. Not only swing/eclipse clients are rich these days, you have a hundreds of technologies emerging in the web client domain that makes them (almost) as rich as above. But, we aren't there yet, so we need to have a plan for how we want to do that, and in the same time maintain some sort of momentum in our release plan. As the plan is now we are going to release the 1.3 with a separate gui meta model, and there are still time to do changes to it. My suggestion is that you start a parallel track where you think of how we could model the gui in a way that would suite your needs. From your thoughts, we take those parts that we see easily could fit in the gui meta model that we are working on now. By that we will have two gui meta models (and that might actually be the right way to go in the future) for some time, but later it will be easier to merge them to a common form. And you can go forward with your rich client generation. Ok, that was all for now (I think)... .../Andreas darabi wrote: > > 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 > > -- View this message in context: http://www.nabble.com/How-to-add-gui-generation-tp14695768s17564p14807050.html Sent from the Fornax-Platform mailing list archive at Nabble.com. ------------------------------------------------------------------------- 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
