On Tue, Apr 14, 2009 at 12:03 PM, John Tamplin <j...@google.com> wrote:
> On Tue, Apr 14, 2009 at 10:26 AM, philip <philip14...@gmail.com> wrote: > >> So I like GWT and I like Google App Engine, all I want is a simple >> recipe for getting the two to work without hitting too many big >> problems. >> I'm willing to use DTO, I'm willing to suffer whatever I have to do - >> but I need to know what's the best current way to do it. >> > > GWT RPC does not preserve identity across the wire, and the GWT compiler > needs the source of the classes at compile time. Since JDO/JPA rewrite the > bytecode on the server, and may do so based on information not in the > source, there won't be any short-term workaround. Even if the enchancer > produced source code instead, trying to serialize Object[] (what the > enhancer adds) means every serializable type in the program has to have > deserializers present in the client, which would be a massive size increase > for programs of any significant size. > > The only way I see it working would be to add a flag requiring preserving > object identity across RPC, and the protocol would include an object ID with > each object if that flag is set. The server would then save/restore > additional hidden fields on its end for any persistent classes which were > rewritten, and use the object ID to know what values should be recreated for > these hidden fields when a persistent object comes back from the client. > > A few issues with this approach: > > - what happens for a persistent object created on the client that the > server has never seen before? > - how are field references handled? Since a class can be made > persistent without the GWT compiler's knowledge, it can't do anything about > this (and even if it could you wouldn't want to for client code-size > reasons). I assume this is only needed to know which fields are "dirty" > and > need to be updated -- maybe you can just assume anything coming from the > client needs to be replaced entirely. Since the GAE data store works that > way anyway that shouldn't be a big inefficiency, but could affect using > this > approach with non-GAE persistence engines. > - Since you don't have clone in JS, any copy of an object would have to > be treated as a new instance, which could be the wrong answer in some > situations. Is making it mostly work as expected acceptable, or will the > odd cases confuse developers more than just requiring them to do things > explicitly? > > This would require significant work in the GWT RPC subsystems and could > mean a significant cost in the wire-protocol size. > > IMHO, blindly transferring your stored data across the wire is convenient > but produces big, slow client code. That may be useful for development, and > it may be worth providing it for that reason and for intranet apps where the > client size is less important, but I think having to write your own DTOs so > you know exactly what is going over the wire and why forces you to think > about why you need it in the client and produce a more efficient app. It is > too easy to just send a Customer record to the client because that is what > you have, even when all you need is just the name/address portions for your > shipping form, etc. I think this is a false dichotomy. JDO has fetch-groups for just that kind of scenario. You send down a slice of an object graph that meets exactly your needs. You don't have to re-invent an entire DTO layer just to send a subset of your data. You can re-use the same domain objects in several different RPC calls with several different fetch-groups each tailored for the specific use case. I think we need to tread carefully here if we're to make progress and produce something everyone can be happy with. We need people who really understand this domain to get together and think this through offline, coming back with at least semi-baked proposals we can discuss, evaluate, and adjust. We'd end up with much more productive discussion instead of lots of idle speculation. -- > John A. Tamplin > Software Engineer (GWT), Google > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
