I see that you answered all of my questions, so I'll answer yours: "why bother?" ;-)
GWT allows you to not just push a thin presentation layer to the browser but also share code between browser and server. In particular it allows you to have a Presentation Model<http://www.martinfowler.com/eaaDev/PresentationModel.html>(PM) on the browser. I want to avoid duplicating a model and business logic outside of Qi4J just to deploy it on the browser. For a previous project I created a web application that had a model somewhat similar to Qi4J in that the properties are represented by property objects instead of accessor pairs. In addition to get() and set() each property contained a status() method that could tell you whether the property is readable, writeable, relevant(not hidden) and valid. Having such "smart" properties makes it trivial to bind them to GUI elements. In my project's case an xml file was used to define pages, sections, labels and more presentation info. The actual binding and rendering was completely generic (representing the way all our web applications work). In general, creating a PM involves a lot of messy code: you have to forward all properties to the actual model, add status methods etc. In Qi4J otoh, a PM could be created by adding a mixin to an existing class which would only contain the GUI specific additions. In general this gives you a very nice architecture: a pure business model containing only business logic <==> a PM containing gui extensions <==> a GUI rendered generically with hints Of course there could be several GUIs differing in presentation technology or methodology. I noticed that many of the status info's even make sense in the business logic: when copying data it makes sense to leave out irrelevant data. It is always good to be able to validate data. Logic or security constraints make properties readonly etc. It is customary to express such conditions by throwing exceptions when client code tresspasses but why not also express it directly? Anyway, together this means that a browser could handle all user interaction completely by itself as long as no backend services like databases are needed. Together with a STM like jstm4gwt <http://www.xstm.net/> the border between browser and server can be nearly unnoticeable to the programmer. Writing a gui for the web would be just as simple as a local one. Of course this could be achieved using a web framework like wicket that essentially forwards all event to the server, renders on the server and then sends differential updates back to the browser. A GWT app is much more scalable by using the abundance of computing power available on the desktop though. cheers, Guus On Fri, Apr 24, 2009 at 2:39 PM, Niclas Hedhman <[email protected]> wrote: > On Fri, Apr 24, 2009 at 7:55 PM, Guus Bloemsma <[email protected]> wrote: > > > It would be really great if Qi4J could be used together with GWT. > > Right now, I have no particular opinion whether this is a good idea or not. > > > As far as > > I can see the big showstopper here is the use of CGLIB and dynamic > proxies. > > As for CGLIB I couldn't really find out where it is used (I just read > about > > it in another thread). > > CGLib is currently only used for a single case; When you only > implement an interface partially in Concern/SideEffect/Mixin, you do > so with; > > public abstract class SomeMixin > implements Some > { > public void doWhatEver() > { > } > } > > The JVM don't like partially implemented classes, and doesn't allow > you to instantiate an abstract class, although we can guarantee that > those other methods will never be called. Therefor, Qi4j Runtime will > create a subclass from such class, where the missing methods exist and > do nothing. > > > > For the dynamic proxies however I was thinking of the following: > > Run the application locally in hosted mode where dynamic proxies should > work > > without problems. Have some patch in place that records for which classes > > dynamic proxies are being created. > > Next generate source equivalent to those dynamic proxies (maybe in a GWT > > generator) to replace them. > > Sounds doable with clever instrumentation, or perhaps only running an > inspection of the Model and have the inspection tool generate the > classes. Also a different Qi4j Runtime would be needed which doesn't > use the dynamic proxies approach. > > > I don't have enough insight into Qi4J to say anything about the > feasibility > > of this. Any comments? > > It is not a trivial undertaking, but definitely within reach of a > dedicated community member or two. I don't think it makes sense to > spread the current resources even thinner on this at this point in > time. > > I am also interested to hear why you feel this is such a good idea, > compared to only providing simple integration of GWT apps to a Qi4j > backend. > > > Cheers > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/2qq9er > I work here; http://tinyurl.com/2ymelc > I relax here; http://tinyurl.com/2cgsug > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev >
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
