Hi Robert,
For information, Gilead provides the @ServerOnly annotation to prevent
sending sensible fields over the wire.
Regards
Bruno
On 15 avr, 05:39, 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
>
> On Tue, Apr 14, 2009 at 2:18 PM, John Tamplin <j...@google.com> wrote:
> > On Tue, Apr 14, 2009 at 1:28 PM, Ray Cromwell <cromwell...@gmail.com> wrote:
>
> >> On Tue, Apr 14, 2009 at 9:03 AM, John Tamplin <j...@google.com> wrote:
> >> > The only way I see it working would be to add a flag requiring
> >> > preserving
> >> > object identity across RPC, and the protocol would include an object ID
> >> > with
> >> > each object if that flag is set.
>
> >> Actually, JDO has a concept called application identity where object
> >> identity is handled by the application. This typically boils down to
> >> the PrimaryKey being used as object identity.
>
> > Is there an equivalent for JPA?
>
> >> > what happens for a persistent object created on the client that the
> >> > server
> >> > has never seen before?
>
> >> Calling persist() on it would insert it rather than merge it.
>
> > Well, what I was getting at was more what does the server-side RPC code
> > populate the hidden fields with if it gets a new object of that type from
> > the client?
>
> > If the hidden fields can be null and the @PrimaryKey field will be used to
> > determine if it is a new object or a replacement of an existing one, then it
> > seems pretty easy -- the server-side RPC code simply strips out the effect
> > of the bytecode rewriting for serialization. I don't know enough about what
> > rewriting happens to know how to detect/reverse it, but it seems like it
> > should be doable.
>
> > --
> > John A. Tamplin
> > Software Engineer (GWT), Google
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
