The latter. The first time the class is encountered, GWT would search for setters (field '<T> theField' would cause a search for a setter 'void setTheField(<T> arg)') and create a map from field names to setters. If there's no setter for a given field, the field would be set directly. Dan
On Mon, Jul 20, 2009 at 2:18 PM, Isaac Truett <[email protected]> wrote: > > > 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 (דניאל > רייס)<[email protected]> 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 -~----------~----~----~----~------~----~------~--~---
