I don't have a boilerplate pattern available as I'm still experimenting myself. There seems to be two schools of thought:
1/ Try and reuse classes on both server and client sides which means exporting server logic to clients and vice versa 2/ Separating client and server logic and evolving the two separately At first I tried to do the former but I didn't like it: it's just not clean IMHO. What I'm trying to do now is focus on the service interface offered by the server to the client. Using Google App Engine helps this discipline. I define the service interface in terms of actions: 'Create new user', 'Transfer X from account x to account y', 'Get Employee details'. I'm at the frustrating phase that there's a lot of similar objects on both sides of the fence. But, over time, I'm seeing these diverge and evolve differently solving their own use cases without the restraint of trying to maintain a one-size-fits-all approach. In many of my core server-side and persistent objects: Employee, Account, etc., I have/had a method: EmployeeVo Employee.toVo(): i.e. to value object (as opposed to toString()). But, as my use cases become more refined I find that things evolve to having a Person object with toUserVo(), toEmployee() and toCustomerVo() methods that create client side objects that are shipped out to log in, update employee details or have a customer select a shipping address. I love these types of problems - that's what makes programming so much fun. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
