On Thu, Apr 30, 2009 at 10:24 AM, Niclas Hedhman <[email protected]> wrote:
> On Thu, Apr 30, 2009 at 4:07 PM, Guus Bloemsma <[email protected]> wrote: > > > Obviously there is no point in running all of Qi4J on the browser. Low > level > > layers like persistency would be possible by proxying but that could > involve > > lots of roundtrips which is exactly what you want to avoid to get a > smooth > > GUI. > > FYI, there are not "a lot of round-trips" in the "persistence" layer... Not in the persistence layer itself. If the client would load all entities it needed by itself it would do a roundtrip for each entity or set of entities. It is more performant if the server preloads everything that will be needed and sends it off at once. Unfortunately this requires some knowledge of what the client might do with those entities. > > > > The user can then work in that GUI and manipulate the entities. The > > underlying Property objects keep track of get()s and set()s to record a > UoW > > which is sent back to the server when something is committed. > > ... and this is effectively 'everything' regardless of whether you run > a 'local' JDBM instance or the remote Rest system. > > So, I am not sure what will not end up on the client, except some of > the extensions. I proposed before to not use assemblers on the client side because GWT doesn't support reflection and therefore no dynamic proxies. If it would, it couldn't do the aggressive dead code elimination. Instead I would like to run the assemblers once in hosted mode (meaning that java is replacing javascript in a specially patched browser) and introspect the resulting dynamic proxies and generate equivalent java source code. So instead of the current runtime those generated classes would be compiled plus everything they pull in (which might actually contain parts of the current runtime). It's just that compiling the current runtime will not give much of an indication of what the eventual compiled size will be. And don't get us wrong; I would love to see Qi4j on GWT and other > platforms, but I and Rickard need to prioritize the limited time on > other things. If you want to gang up with someone and make it happen, > please do so, and we will try to explain the internal bits you need to > know. > Don't worry, I don't expect anyone to do my coding for me ;-) I just really enjoy these discussions and I'm trying to determine the feasibility of GWT hosted Qi4J. If it actually works some day it would be great if you accepted some patches though... I see that you put a lot emphasis on building a very clean domain model to allow other aspects like persistence, remoting etc to be plugged in. In the project I talked about I did the same thing from another angle in a different way: a clean domain model that allows to plug in a GUI 'aspect'. This was influenced by ideas from NakedObjects <http://www.nakedobjects.org> . One thing that was similar to Qi4J was using full objects for Properties instead of an accessor naming convention; that's what drew my attention in the first place. I used public final fields (containing properties) instead of an interface because that makes it easy to write specific inner classes when a property has non-default behaviour. I think your approach is better because it allows different implementations of Properties for different purposes. One thing that was completely different is that I wrote nearly all my domain logic by overriding the get() and status() methods (instead of set()), essentially using a functional coding style. In this case I could afford simply recalculating every time when a property changes because you only have to do that for whatever is visible on the screen. I'm trying to make this work for the more general case by writing a library for reactive programming. Here again properties as objects are very useful because it allows you to make properties that notify you when their value changes. It also allows you to make properties that automatically update their value in response to such notifications and then notify others of that change. cheers, Guus
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
