I can see where, like in my case, you’d want to have separate encoders and decoders for client and server though.  Like in my case I’d probably want to use DateTimeFormat on the client side to parse/encode the string and SimpleDateFormat on the server to parse/encode the string.  It’s in cases where the APIs are not available on both that it would come in handy to have separate ones.

From: Mike Brock [mailto:cbrock@redhat.com]
Sent: Friday, February 05, 2010 8:50 PM
To: Kevin Jordan
Cc: errai-users@lists.jboss.org
Subject: Re: [errai-users] Adding Marshalling/Demarshalling handlers?

Yes, it's obviously to me looking at it today that 1 and 3 can basically use the same facility.  There's no reason why not.

And 2 and 4 can probably be combined somehow, possibly by using a wrapper-like system around MVEL's ConversionHandlers.  I also happen to be the author of MVEL, so I have some flexibility there. :)

I'll be poking around on this over the weekend.  This is an example of one of those things I prototyped really fast for the purpose of a demo on a tight deadline, and never went back and revisited.  But I will now.

Mike.

On 2010-02-05, at 5:18 PM, Kevin Jordan wrote:

So I need to:

1) Add a Marshaller via TypeMarshallers to encode the date on the client.

2) Add a TypeHandler via TypeHandlerFactory to decode the serialized date on the client.

3) Add a TyperHandler via JSONEncoder to encode the date on the server.

4) Add a ConversionHandler via org.mvel2.DataConversion.addConversionHandler to decode the serialized date on the server.

Does that about cover it?

From: Mike Brock [mailto:cbrock@redhat.com]
Sent: Friday, February 05, 2010 1:39 PM
To: Kevin Jordan
Cc: errai-users@lists.jboss.org
Subject: Re: [errai-users] Adding Marshalling/Demarshalling handlers?

Really the best way to handle it, is with TypeHandlerFactory, which exposes addHandler();

So if you wanted to do what you're dong, you would implement a TypeHandler, that would say, convert a Number to DatePicker.

public class NumberToDatePicker<Number, DatePicker> {

       public DatePicker getConverted(Number n) {

return new DatePicker(in.longValue());

       }

}

And you would then add that to TypeHandlerFactory like so: 

TypeHandlerFactory.addHandler(Number.class, DatePicker.class, new NumberToDatePicker());

This of course presumes that you have an TypeHandler on the server that converts DatePicker to a long, and you have an MVEL DataConverter on the server which converts back from long to DatePicker on the server -- yes, this is incongruent and requires some thought about how to unify this...

I have exposed a static method addEncodingHandler for JSONEncoder, so you can then add an encoding handler like so:

JSONEncoder.addEncodingHandler(DatePicker.class, new TypeHandler() {  public Long getConverted(DatePicker picker) { return picker.getTime(); } });

...

You get the idea.  You'll need to upgrade to trunk to get that working.

On 2010-02-05, at 11:49 AM, Kevin Jordan wrote:

Is there any easy way besides modifying JSONEncoder and TypeDemarshallHelper to add something to convert a type for sending/receiving over the wire?  I’m wanting to do a subclass of Date for a DatePicker and want to serialize it a String so TimeZone conversions don’t need to happen on it since it’ll default to midnight for whatever the server timezone is.  It seems as far as TypeDemarshallHelper, I can just do a static add to org.mvel2.DataConversion, but for JSONEncoder is doesn’t seem that easy since the handlers are added to a private Map.  I assume on the client side, it’s as easy as adding a CustomFieldSerializer (http://code.google.com/p/wogwt/wiki/CustomFieldSerializer)?

_______________________________________________
errai-users mailing list
errai-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-users