I have it "mostly" working, although the inability to replace a class (ala readResolve() or writeReplace()) pretty much means it's impossible for an object roundtrip through the RPC layer to work properly. A quick explanation:
* I have a Ref impl of type LiveRef which holds a reference to the live datastore so it can resolve the entity pointed at.
* With java serialization, a LiveRef writeReplace()s to a DeadRef which holds a reference to the actual entity.
My GWT client-only version of LiveRef is now implemented just like DeadRef, so clients can obtain a Ref from the server and work with it. But passing a LiveRef back to the server reconstitutes a real LiveRef which loses the entity part and "reattaches" to the datastore. So it's impossible to do a real roundtrip.
It sounds like I will have to live with this behavior for now.
One thing I want to say is that GWT custom serialization seems unbearably complicated and poorly documented. Here is why it is confusing:
* what runs on client vs what runs on server
* _CustomFieldSerializer vs _ServerCustomFieldSerializer??
* static methods vs instance methods
* instantiate vs deserialize (what's the difference?)
From the outside, this feels like something in desperate need of refactoring. Never mind backwards compatibility; as documented, this feature is basically unusable by anyone who isn't on the GWT team.
Jeff
On Sun, Apr 7, 2013 at 2:11 AM, Jeff Schnitzer <jeff@infohazard.org> wrote:
Ah hah! The magic secret ingredient that will save me is the ability
to have different custom serializers on client and server, probably
via super-source. I hadn't thought of that.
Re-creating my Ref type hierarchy in super-source on the client is
annoying, but as you point out it's not an intractable problem since
all but the root can just be stub subclasses.
Thanks,
Jeff
On Tue, Apr 2, 2013 at 4:56 AM, Thomas Broyer <t.broyer@gmail.com> wrote:
>
>
> On Sunday, March 31, 2013 11:14:28 PM UTC+2, Jeff Schnitzer wrote:
>>
>> As a second question, is there any document anywhere which describes
>> how custom serializers actually work?
>
>
> I don't think so; at least not outside Google.
> There's
> https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit
> about GWT-RPC serialization, but it's really light when it comes to custom
> serializers and simply defer to the DevGuide.
>
>>
>> The tiny section in
>> DevGuideServerCommunication is not helpful. Some basic questions:
>>
>> * Are custom serializers server-side only? Or do they get executed on
>> the client-side too?
>
>
> Custom serializers are used on both sides (isn't this clear from the doc?).
> If you need different implementations for the client and server, you can
> either have a Ref_ServerCustomFieldSerializer<Ref> or use super-sources
> (EnumMap and LinkedHashMap uses this, actually in addition to a
> ServerCustomFieldSerializer: the CustomFieldSerializer from "sources" is
> used in DevMode, the one from super-sources is annotated with @GwtScriptOnly
> and thus only used when compiled to JS, and the ServerCustomFieldSerializer
> is used on the server-side).
>
>> * What's the relationship between the static methods and the instance
>> methods? I presume we have both for some sort of historical reason,
>> but can we get rid of the static methods? (last time I tried it didn't
>> work)
>
>
> Actually, the static methods are used on client-side, while the instance
> methods are used on server-side (when they generally just defer to the
> static methods). Historically, custom serializers were only
> convention-based: must be named with the _CustomFieldSerializer suffix and
> have the serialize and deserialize static methods and optionally an
> instantiate static method. The CustomFieldSerializer interface was added in
> GWT 2.3, and the ServerCustomFieldSerializer added in GWT 2.5.0. The
> CustomFieldSerializer interface was added as an optimization, to avoid too
> much reflection at runtime on the server-side.
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment