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