9:47 a.m.
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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-users