You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Jeromy Evans <je...@blueskyminds.com.au> on 2007/11/10 03:54:03 UTC
serialize enum to JSON (jsonplugin issue 9)
What is "the correct" way to serialize an enum to JSON?
The struts2plugin can't handle enums quite right (Issue 9:
http://code.google.com/p/jsonplugin/issues/detail?id=9) and while trying
to finalize a patch I haven't found a consistent opinion.
There's two schools of thought:
- an enum should be serialized as a value. eg. { "prop":"name()" } or
{ "prop":ordinal() }
- an enum should be serialized an an object. eg. { "prop": {
"name":"name()" } }
The advantage of the latter case is that additional properties of the
enumeration can be included.
My quick survey of implementations are:
xstream with JsonHierarchicalStream and default converter : { "prop":
{"name"}}
xstream with jettisonMapper driver and default converter : {
"prop":"name" }
json-rpc-java: { "prop":{ "_name":"name", properties... }}
json.net: {"prop":ordinal}
I think json-rpc-java is strictly correct by serializing the enum as
bean with a special _name property, however I think the Jettison driver
by value approach is closer to what a javascript developer would
naturally expect. The JsonHierarchicalStream driver is unnatural
because it supports deserialization. Json.net doesn't have to contend
with additional properties in enums and the ordinal value is explicit.
Has anyone seen a convention used a lot that's worth borrowing? Or is
this worthy of a yet another option for the result?
regards,
Jeromy Eans
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: serialize enum to JSON (jsonplugin issue 9)
Posted by Musachy Barroso <mu...@gmail.com>.
+1 for the JSON-RPC approach. We could also have a flag in the result
to make just serialize the "name" of the enum value, instead of the
bean.
musachy
On Nov 10, 2007 12:51 AM, Ted Husted <hu...@apache.org> wrote:
> +1 for the JSON-RPC approach.
>
>
> On Nov 9, 2007 9:54 PM, Jeromy Evans <je...@blueskyminds.com.au> wrote:
> > What is "the correct" way to serialize an enum to JSON?
> >
> > The struts2plugin can't handle enums quite right (Issue 9:
> > http://code.google.com/p/jsonplugin/issues/detail?id=9) and while trying
> > to finalize a patch I haven't found a consistent opinion.
> >
> > There's two schools of thought:
> > - an enum should be serialized as a value. eg. { "prop":"name()" } or
> > { "prop":ordinal() }
> > - an enum should be serialized an an object. eg. { "prop": {
> > "name":"name()" } }
> > The advantage of the latter case is that additional properties of the
> > enumeration can be included.
> >
> > My quick survey of implementations are:
> > xstream with JsonHierarchicalStream and default converter : { "prop":
> > {"name"}}
> > xstream with jettisonMapper driver and default converter : {
> > "prop":"name" }
> > json-rpc-java: { "prop":{ "_name":"name", properties... }}
> > json.net: {"prop":ordinal}
> >
> > I think json-rpc-java is strictly correct by serializing the enum as
> > bean with a special _name property, however I think the Jettison driver
> > by value approach is closer to what a javascript developer would
> > naturally expect. The JsonHierarchicalStream driver is unnatural
> > because it supports deserialization. Json.net doesn't have to contend
> > with additional properties in enums and the ordinal value is explicit.
> >
> > Has anyone seen a convention used a lot that's worth borrowing? Or is
> > this worthy of a yet another option for the result?
> >
> > regards,
> > Jeromy Eans
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: serialize enum to JSON (jsonplugin issue 9)
Posted by Bob Tiernay <bt...@hotmail.com>.
FYI, DWR takes the name value approach:
http://getahead.org/dwr/server/dwrxml/converters/enum
> Date: Sat, 10 Nov 2007 00:51:55 -0500> From: husted@apache.org> To: dev@struts.apache.org> Subject: Re: serialize enum to JSON (jsonplugin issue 9)> > +1 for the JSON-RPC approach.> > On Nov 9, 2007 9:54 PM, Jeromy Evans <je...@blueskyminds.com.au> wrote:> > What is "the correct" way to serialize an enum to JSON?> >> > The struts2plugin can't handle enums quite right (Issue 9:> > http://code.google.com/p/jsonplugin/issues/detail?id=9) and while trying> > to finalize a patch I haven't found a consistent opinion.> >> > There's two schools of thought:> > - an enum should be serialized as a value. eg. { "prop":"name()" } or> > { "prop":ordinal() }> > - an enum should be serialized an an object. eg. { "prop": {> > "name":"name()" } }> > The advantage of the latter case is that additional properties of the> > enumeration can be included.> >> > My quick survey of implementations are:> > xstream with JsonHierarchicalStream and default converter : { "prop":> > {"name"}}> > xstream with jettisonMapper driver and default converter : {> > "prop":"name" }> > json-rpc-java: { "prop":{ "_name":"name", properties... }}> > json.net: {"prop":ordinal}> >> > I think json-rpc-java is strictly correct by serializing the enum as> > bean with a special _name property, however I think the Jettison driver> > by value approach is closer to what a javascript developer would> > naturally expect. The JsonHierarchicalStream driver is unnatural> > because it supports deserialization. Json.net doesn't have to contend> > with additional properties in enums and the ordinal value is explicit.> >> > Has anyone seen a convention used a lot that's worth borrowing? Or is> > this worthy of a yet another option for the result?> >> > regards,> > Jeromy Eans> > ---------------------------------------------------------------------> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org> For additional commands, e-mail: dev-help@struts.apache.org>
_________________________________________________________________
Are you ready for Windows Live Messenger Beta 8.5 ? Get the latest for free today!
http://entertainment.sympatico.msn.ca/WindowsLiveMessenger
Re: serialize enum to JSON (jsonplugin issue 9)
Posted by Ted Husted <hu...@apache.org>.
+1 for the JSON-RPC approach.
On Nov 9, 2007 9:54 PM, Jeromy Evans <je...@blueskyminds.com.au> wrote:
> What is "the correct" way to serialize an enum to JSON?
>
> The struts2plugin can't handle enums quite right (Issue 9:
> http://code.google.com/p/jsonplugin/issues/detail?id=9) and while trying
> to finalize a patch I haven't found a consistent opinion.
>
> There's two schools of thought:
> - an enum should be serialized as a value. eg. { "prop":"name()" } or
> { "prop":ordinal() }
> - an enum should be serialized an an object. eg. { "prop": {
> "name":"name()" } }
> The advantage of the latter case is that additional properties of the
> enumeration can be included.
>
> My quick survey of implementations are:
> xstream with JsonHierarchicalStream and default converter : { "prop":
> {"name"}}
> xstream with jettisonMapper driver and default converter : {
> "prop":"name" }
> json-rpc-java: { "prop":{ "_name":"name", properties... }}
> json.net: {"prop":ordinal}
>
> I think json-rpc-java is strictly correct by serializing the enum as
> bean with a special _name property, however I think the Jettison driver
> by value approach is closer to what a javascript developer would
> naturally expect. The JsonHierarchicalStream driver is unnatural
> because it supports deserialization. Json.net doesn't have to contend
> with additional properties in enums and the ordinal value is explicit.
>
> Has anyone seen a convention used a lot that's worth borrowing? Or is
> this worthy of a yet another option for the result?
>
> regards,
> Jeromy Eans
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org