[gwt-contrib] Re: Comment on RequestFactoryPlusPaths in google-web-toolkit
Comment by pclog...@gmail.com: The best poker blog http://poker-blogs-see.blogspot.com Best PokerStars blog http://pokerstars-blogs.blogspot.com Sexy, hot girls imagehttp://china-sexy-girl-images.blogspot.com/ For more information: http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryPlusPaths -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on RequestFactoryPlusPaths in google-web-toolkit
Comment by nick.red...@gmail.com: I've made a somewhat-similar project (same goals, in a way, much different route) - which is here: http://code.google.com/p/alcina/ My comparison of the two (alcina to the gwt2.1/mvc framework) -http://code.google.com/p/alcina/wiki/ComparisonWithGwt2_1Sync - is based on gwt2.1 as it was in late June 2010, but still seems mostly valid. The Alcina project is a lot closer to Google Wave (but with transforms of a domain (JPA) object graph, not a wave) in many senses - and deals with a few things that don't seem to be targetted by gwt2.1mvc, but perhaps would be good if they were: - non-blocking (optimistic UI) client changes to the JPA graph - out-of-order requests arriving at the server (only necessary if you're non-blocking, sure) - dealing with the client JPA graph being a sub-graph of that of the server (essentially, dealing with EntityManager.merge() being basically broken) Sorry this is so late - I tried emailing some of the GWT team in June but got no response...best of luck, Nick For more information: http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryPlusPaths -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on RequestFactoryPlusPaths in google-web-toolkit
Comment by jgr...@google.com: I think there will be a use for client-side consumption as well. It would be useful to attach a ValueChangeHandler (or similar) to a part of an object graph using this mechanism -- the semantic would mean call me when you have fetched *all* of this part of the graph. How that part of the graph is fetched from a remote system would be an entirely separate issue. Also, it would be best if you could avoid a string approach. OGNL is great (so is XPath), but a builder pattern could ensure some degree of correctness at compile time. For more information: http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryPlusPaths -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe, reply using remove me as the subject.
[gwt-contrib] Re: Comment on RequestFactoryPlusPaths in google-web-toolkit
Comment by rj...@google.com: These sound like questions I would ask you. OGNL is kind of heavy, I think. It wants to be able to execute methods with arguments and all kinds of things. But yeah, moving this away from runtime and to compile time sounds great. But my brain is full. For more information: http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryPlusPaths -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on RequestFactoryPlusPaths in google-web-toolkit
Comment by rj...@google.com:
Hmmm. On the other hand, so far paths seem to be entirely for server side
consumption. Client side you subscribe to the entity field at the last hop
on the path, I hope.
So you declare me.boss.displayName on the client. That goes to the server
and comes back as, effectively, Employee{id: bossId, version: bossVersion}.
The subscriber is tied to bossId+DISPLAY_NAME, not me.boss.displayName.
Later when someone else in the app updates the employee with id=bossId,
I'll hear about it because that's the key to my subscription. I *think*
that could still work with the ognl-on-the-server approach?
The usual complaint about OGNL is that it throws type safety out the
window, but that needn't be true for us, presuming the code generator has
access to server types. If we're willing to fail on polymorphism.
Or, perhaps value store subscriptions *are* keyed by path. But then I think
we'll wind up with redundant values. How can I tell that
findAllEmployees()[25] is the same as Employee{id: bossId}? I'm counting on
being able to use the ValueStore as a cache, and avoid emitting redundant
rpc calls. Can that work in this more webwork-like world we're describing?
For more information:
http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryPlusPaths
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
