5:49 p.m.
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)?
7:40 p.m.
It should be simple enough to expose an API to do this on the client side. I will start
looking at this immediately. I'm sure I can whip something together by Monday.
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
8:39 p.m.
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
11:18 p.m.
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
11:44 p.m.
Also, while I haven't had to do this yet, but probably will in the future,
is there a way to grab the MessageBus outside a service? It would be in the
same application context, but I have a Mule ESB which will communicate with
other external services (and possibly a good deal of business logic there
since I can chain services there fairly easily to become a business flow)
and I might want to broadcast something from it to Errai subscribers. It's
not as simple as adding an @Inject (since I figure the calling servlet is
likely doing that) or an ErraiBus.get() like on the client side, is it?
From: errai-users-bounces(a)lists.jboss.org
[mailto:errai-users-bounces@lists.jboss.org] On Behalf Of Kevin Jordan
Sent: Friday, February 05, 2010 4:18 PM
To: 'Mike Brock'
Cc: errai-users(a)lists.jboss.org
Subject: Re: [errai-users] Adding Marshalling/Demarshalling handlers?
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
3:52 a.m.
The best way to do this is to use an Errai extension. Extensions get called a bootstrap
time, and have access to the context. You could then, in theory, map the Bus into JNDI or
whatever mechanism suits you. You simply just declare a class with the
ErraiConfigExtension and annotate it @ExtensionComponent, and the component will be
discovered and called when Errai bootstraps.
/**
* Create a config extension class so we can do things like setup the default tables
* when the application is deployed, etc.
*/
@ExtensionComponent
public class AppConfigurator implements ErraiConfigExtension {
private MessageBus bus;
@Inject
public AppConfigurator(MessageBus bus) {
this.bus = bus;
}
public void configure(Map<Class, Provider> bindings, Map<String, Provider>
resourceProviders) {
// provide extension points here
}
}
On 2010-02-05, at 5:44 PM, Kevin Jordan wrote:
Also, while I haven’t had to do this yet, but probably will in the
future, is there a way to grab the MessageBus outside a service? It would be in the same
application context, but I have a Mule ESB which will communicate with other external
services (and possibly a good deal of business logic there since I can chain services
there fairly easily to become a business flow) and I might want to broadcast something
from it to Errai subscribers. It’s not as simple as adding an @Inject (since I figure
the calling servlet is likely doing that) or an ErraiBus.get() like on the client side, is
it?
From: errai-users-bounces(a)lists.jboss.org [mailto:errai-users-bounces@lists.jboss.org] On
Behalf Of Kevin Jordan
Sent: Friday, February 05, 2010 4:18 PM
To: 'Mike Brock'
Cc: errai-users(a)lists.jboss.org
Subject: Re: [errai-users] Adding Marshalling/Demarshalling handlers?
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
3:50 a.m.
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
4:47 p.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
5213
days inactive
5216
days old
7 comments
2 participants
participants (2)
-
Kevin Jordan -
Mike Brock