It seems like you guys don't want the transient solution I proposed,
where you reuse the domain objects, but must implement special copying
logic on the server to merge changes from the client. It seems like
what you're really asking for is detached object support. This should
be possible to do. One possibility for example, is to override the
default RPC generator with one that generates RPC subs and subclasses
of serialized types that have detachment support.
For example, let's say you have
public interface CustomerService extends RemoteService {
Customer getCustomer(String name);
}
public interface CustomerServiceAsync {
void getCustomer(String name, AsyncCallback<Customer> callback);
}
The RPC generator could implement this in a way, such that the
received object from the RPC call is not a Customer, but a
DetachableCustomerImpl (which extends Customer). This would be a
client side 'enhanced' version which does dirty bit tracking, by
overriding all of the Persistent setter fields of the class, along
with the stipulation that mutation of persistent fields only occurs
through these setters. (Generators do not have AST access and thus
cannot enhance method bodies to track field mutations)
Meanwhile, on the server, create a JdoRemoteServiceServlet which
treats the serialization of Detachable objects in a special way, by
serializing the detached state fields in a way that is consistent with
the client side encoding of those fields. The logic for tracking class
type CRCs for verification would probably have to be override. The
object would be for the servlet to map a native JDO-encoding of
detached state into a GWT-friendly client-side encoding, and
vice-versa on the return trip.
According to the JDO 2.2 spec, here is what is tracked in enhanced classes:
The detached state is stored as a field in each instance of
Detachable. The field is serialized so
as to maintain the state of the instance while detached. While
detached, only the BitSet of mod-
ified fields will be modified. The structure is as follows.
Object[] jdoDetachedState;
jdoDetachedState[0]: the Object Id of the instance
jdoDetachedState[1]: the Version of the instance
jdoDetachedState[2]: a BitSet of loaded fields
jdoDetachedState[3]: a BitSet of modified fields
Only the BitSet of modified fields is potentially modified by the
client domain object, so the rest of the state could potentially be
encoded by the server as an opaque token to carry around on the client
object until it returns to the server over RPC.
The JDO spec has a lot of complexity, so I'm sure there's other
issues, and probably having the Datanucleus guys help would be
fruitful, but I think there are enough hooks available in RPC right
now to make it work. I was able to practically replace the entire RPC
machinery for my Google Gadget-RPC stuff by just overriding the RPC
generator in my module.
-Ray
On Wed, Apr 15, 2009 at 5:21 AM, Isaac Truett <itru...@gmail.com> wrote:
>
>> The rest, like knowing when to persist vs merge an incoming object
>> from the client, is my problem to figure out.
>>
>> Rob
>
> I'm definitely in agreement with Robert on this. I just started trying
> to write a simple app for GWT + GAEJ and over half my server code
> seems to be jumping through hoops for JDO and converting between my
> persistent data object and my GWT-serializable data object. I'd like
> to see that problem area addressed. Problems of identity and
> client-origin data? I've been dealing with those for years, and I'm
> okay with it.
>
> - Isaac
>
>
> On Tue, Apr 14, 2009 at 11:42 PM, Robert Hanson
> <iamroberthan...@gmail.com> wrote:
>>
>> [Continued - Mail got away from me]
>>
>> ...Besides fixing GWT-RPC with GAE, it also allows me to trim data
>> that I don't really need on the client side.
>>
>> The rest, like knowing when to persist vs merge an incoming object
>> from the client, is my problem to figure out.
>>
>> Rob
>>
>>
>> On Tue, Apr 14, 2009 at 11:39 PM, Robert Hanson
>> <iamroberthan...@gmail.com> wrote:
>>> I hope I am not being naive (or reiterating an existing post), but I
>>> am not concerned with identity, nor concerned with expecting my ORM
>>> solution to deal with entities created on the client.
>>>
>>> I think all I need is a way to use an entity as a DTO without needing
>>> a second set of model objects.
>>>
>>> What about something as simple as keeping the existing semantics in
>>> tact, with the ability to flag properties that are send-able to the
>>> client (as opposed to using transient to flag the reverse behavior).
>>>
>>> public class Data implements Serializable {
>>> �...@gwtdto
>>> private Long id;
>>> �...@gwtdto
>>> private String partA;
>>> private String partB;
>>> }
>>>
>>> In this case the GWT compiler would create a serializer for the client
>>> that only handled the id and partA properties, and ignore partB. The
>>> partB property would simply be null on the client side.
>>>
>>> On the server reflection would be used to only serialize the marked
>>> properties, ignoring the rest. Besides ignoring partB it would also
>>> ignore any fields added by enhancers.
>>>
>>> Besides fixing GWT-RPC with GAE, it also allows me to trim data that I
>>> don't really need o
>>
>> >
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
