Sharing classes on both the server and client has advantages and disadvantages. Some of the advantages are that you don't have to write special transport or serialization code to translate from server to client objects. Another is that you can then write code that works on both the client and server. As you point out though, one disadvantage is that the client and server are usually architecturally different and sharing data or model objects doesn't always work.
The solution we developed to handle this last point is that our data objects share an interface, but not the implementation. We'll have an interface to represent one of our business objects and then there will be a client and server implementation. Then we get special behavior on both sides, but we can still share code (that's written against the interface). When a page is first loaded, all the client objects are actually created on the server and then serialized using GWT RPC to send to the client. This saves us from having to write special JSON code or the like to get the objects from the server to the client. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
