[gwt-contrib] Re: Comment on RequestFactoryPlusPaths in google-web-toolkit

2011-09-15 Thread codesite-noreply
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:

[gwt-contrib] Re: Comment on RequestFactoryPlusPaths in google-web-toolkit

2010-09-25 Thread codesite-noreply
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

[gwt-contrib] Re: Comment on RequestFactoryPlusPaths in google-web-toolkit

2010-04-10 Thread codesite-noreply
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

[gwt-contrib] Re: Comment on RequestFactoryPlusPaths in google-web-toolkit

2010-03-03 Thread codesite-noreply
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

[gwt-contrib] Re: Comment on RequestFactoryPlusPaths in google-web-toolkit

2010-03-03 Thread codesite-noreply
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