Hi John, Thats fine your debating how best to do it for the longer term, and thats great for the longer term. How about now today? how best can I do it now?
For the shorter term I am sure there is a bunch of people who look at this and think, I've got GWT and Google App Engine, I want to put them together and make an nice app, then they come across these discussions. Alternatively, they try to serialize the JDO classes and find they have problems. Either way, they hit the ugly wall. They probably wonder why GWT and App Engine are not such good friends such it would make a great programming platform and boost GWT. This class of people who just came to these technologies for the first or second time, then find a serious problem between the two of them and drop the idea. Its just like the people who go to Ruby on rails to do their application development quickly, they don't care so much at first about the performance, or what is going down the wire. They care about getting the application done quickly at the start. The people who did adopt Ruby on Rails near the start didn't care about scalability or anything complex, just to get the app done and deal with those problems later. Ha, they wouldn't have choosen ROR if they cared about performance. Not only that, I don't really want to optimize my application early, I want to optimize the code later, so I don't care about the data transfer. All my customers have broadband. In my case I'm a programmer with 15 years experience and I've played with GWT for some time but want to write a more serious application, I want to know how best to send my data from App Engine to the GWT client, how best to send it back and update the record. For something like SEAM framework, there are best practices for this. These are fairly simple things, so I expected there would be a simple way to do it in GWT/GAE. I can write an application and try some of the methods discussed here such as Dozer, BeanLib, but it feels wrong. Seam framework has good solutions for bring the data to the page via JPA, maybe you could look at that for some ideas as well. I use that for a lot of work and it avoids the lazyloading exception and you don't need to pre-fetch all data. Although, its not really technically applicable for this problem, the general ideas inside it are good. Thanks, Philip On Apr 15, 12:03 am, 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. > > -- > John A. Tamplin > Software Engineer (GWT), Google --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
