> 5) When the object is sent back to the server, the normal RPC mechanism is > altered as follows > a) the encoded server data is decoded and deserialized into the new object > instance > b) the client data is populated using setXXX() method invocations rather > than by directly setting field values
Is this introducing a requirement that all serializable fields have setters? Or will direct field access be used where a setter can't be found? On Mon, Jul 20, 2009 at 2:06 PM, Daniel Rice (דניאל רייס)<r...@google.com> wrote: > Hi all - > I've been working on a patch to improve support for RPC of > persistence-enhanced objects that would replace the one I recently submitted > as trunk revision 5672. I'd like to give those of you who are interested in > the interaction between RPC and persistence a chance to help me validate the > design before moving forward. > The idea is to be able to deal with different persistence mechanisms in a > way that does not depend too much on the details of their implementations. > We assume that the persistence mechanism provides a way for instances to be > detached from the object store, serialized, deserialized, and reattached in > a well-defined way. Our strategy leverages this capability as follows: > 1) User code on the server detaches the object and places it into a state > such that serialization is valid > 2) GWT detects whether any instance fields are present on the object that > were not known to client code > 3) GWT performs hybrid serialization: > a) GWT uses its regular RPC mechanism for the client-visible fields > b) GWT uses Java serialization for any additional server-only instance > fields > c) GWT encodes the results of step (b) as a String > d) GWT prepends the encoded String to the regular RPC data and transmits > to the client > 4) Client code treats the object in the normal way and does not interact > with the data from step (3b) > 5) When the object is sent back to the server, the normal RPC mechanism is > altered as follows > a) the encoded server data is decoded and deserialized into the new object > instance > b) the client data is populated using setXXX() method invocations rather > than by directly setting field values > All this is done only for classes that can be send bidirectionally, and > which are determined to be (potentially) enhanced. > The potential for enhancement is signaled in one of three ways: > o The user adds the fully-qualified class name to a 'gwt.enhancedClasses' > configuration property > o The class is determined to have the JDO @PersistenceCapable annotation > with detachable=true > o The class is determined to have the JPA @Entity annotation > If a class is determined to be potentially enhanced, the list of fields > known to the client is added to the '.gwt.rpc' file that contains the RPC > whitelist. This list is used by step 2 of the RPC process which compares > the set of client- and server-visible fields. > Step (5b) is necessary to accommodate mechanisms like that of JDO, where > the setter methods are enhanced to provide object state tracking (dirty > bits). If we were to set the fields directly, the object detached state > would not be updated properly. > My hope is that this mechanism would be general enough to support a > variety of persistence mechanisms without the need to add a lot of > special-case code. I'm looking forward to any comments that you have as to > whether this will work with your favorite persistence API, or any other > thoughts that you have. Thanks, > Dan > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
