On 4/7/08, Jakub Podlesak <Jakub.Podlesak_at_sun.com> wrote:
>
>
> Hi Stephan,
>
>
> Besides serializing out (Java->JSON), do you also need to deserialize back
> (JSON->Java)?
> What is your approach there?
For REST POST calls I use encoded forms which is the easiest thing to do.
When I cache more business objects in the UI layer I will probably move to
JSON (read objects, manipulate them, PUT them).
But I'm thinking about a "reverse"-Builder
$("items", items) which would match the items node and put the content in
the items variable (Java would need holders for that). But not sure about
the best approach. Perhaps JAXB would be good for that.
Regards
-stephan
~Jakub
>
>
> > - Lean JSON as possible
> >
> > Bye
> > -stephan
> >
> > On Fri, Apr 4, 2008 at 5:11 PM, Jakub Podlesak <Jakub.Podlesak_at_sun.com>
> > wrote:
> >
> > >
> > > Hi Stephan,
> > >
> > > On Fri, Apr 04, 2008 at 01:01:44PM +0200, Stephan Schmidt wrote:
> > > > Hi,
> > > >
> > > > just my two cents, I don't like BadgerFish and generated JSON from
> > > objects,
> > > > because several requests might return different JSON
> representations,
> > > >
> > > >
> > >
> http://stephan.reposita.org/archives/2008/04/04/rest-lean-json-and-xml-from-the-same-code/
> > >
> > > With current Jersey version you can do the same (with default config)
> and
> > > as a benefit you would
> > > also have the ability to transform the JSON data back to java.
> > > You notice only Java to JSON binding in your post.
> > >
> > > Besides that you will IMHO have an easier way to populate your data
> into
> > > your java beans.
> > >
> > > You might want to try out the following:
> > >
> > > @Path("/list")
> > > public class ShoppingListResource {
> > >
> > > @XmlRootElement
> > > public static class Item {
> > > public String id;
> > > public int price;
> > > public String shop;
> > > public String description;
> > >
> > > public Item(String id, int price, String shop, String
> description)
> > > {
> > > this.id = id;
> > > this.price = price;
> > > this.shop = shop;
> > > this.description = description;
> > > }
> > >
> > > public Item() {}
> > > }
> > >
> > > @XmlRootElement
> > > public static class ShoppingList {
> > > public String id;
> > > public final List<Item> items = new LinkedList<Item>();
> > >
> > > public ShoppingList(String id) {
> > > this();
> > > this.id = id;
> > > }
> > >
> > > public ShoppingList() {
> > > }
> > >
> > > public void add(Item i) {
> > > this.items.add(i);
> > > }
> > > }
> > >
> > >
> > > @GET @ProduceMime({"application/xml", "application/json"})
> > > public ShoppingList getList() {
> > > ShoppingList list = new ShoppingList("123");
> > > list.add(new Item("234", 11, "", "Apple"));
> > > list.add(new Item("233", 22, "", "Banana"));
> > > return list;
> > > }
> > >
> > > Which will return:
> > >
> > >
> > >
> {"shoppingList":{"id":"123","items":[{"id":"234","price":"11","shop":"","description":"Apple"},{"id":"233","price":"22","shop":"","description":"Banana"}]}}
> > >
> > > or
> > >
> > > <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> > > <shoppingList>
> > > <id>123</id>
> > > <items>
> > > <id>234</id>
> > > <price>11</price>
> > > <shop/>
> > > <description>Apple</description>
> > > </items>
> > > <items>
> > > <id>233</id>
> > > <price>22</price>
> > > <shop/>
> > > <description>Banana</description>
> > > </items>
> > > </shoppingList>
> > >
> > >
> > > based on the mime type required.
> > >
> > > You could easily tweak the JSON "data type" for e.g. price, so that
> you
> > > do not have it represented as String in JSON, but it would require a
> > > custom
> > > JSONJAXBContext to be defined in your webapp:
> > >
> > > @Provider
> > > public static class JAXBContextResolver implements
> > > ContextResolver<JAXBContext> {
> > >
> > > private JAXBContext context;
> > > private Class[] types = {Item.class, ShoppingList.class};
> > >
> > > public JAXBContextResolver() throws Exception {
> > > Map<String, Object> props = new HashMap<String, Object>();
> > > props.put(JSONJAXBContext.JSON_NOTATION, "MAPPED");
> > > props.put(JSONJAXBContext.JSON_ROOT_UNWRAPPING,
> Boolean.TRUE);
> > > props.put(JSONJAXBContext.JSON_ROOT_UNWRAPPING,
> Boolean.TRUE);
> > > props.put(JSONJAXBContext.JSON_NON_STRINGS, "[\"price\"]");
> > > this.context = new JSONJAXBContext(types, props);
> > > }
> > >
> > > public JAXBContext getContext(Class<?> objectType) {
> > > return (types[0].equals(objectType)) ? context : null;
> > > }
> > > }
> > >
> > >
> > > I will probably need to post a new entry to my blog summarizing
> possible
> > > options for JSON/JAXB
> > > processing in (current) Jersey.
> > >
> > > Thanks,
> > >
> > > ~Jakub
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > >
> > >
> http://stephan.reposita.org/archives/2008/03/18/experiments-for-nicely-generating-json/
> > > >
> > > > Additionally I wrote a Message Body Writer which encapsulates the
> > > toJson()
> > > > call.
> > > >
> > > > BadgerFish and full object graph dumps in JSON seem to contradict
> the
> > > > purpose
> > > > of JSON, a lean, fast to parse and read data format.
> > > >
> > > > Regards
> > > > -stephan
> > > >
> > > >
> > > > On Fri, Apr 4, 2008 at 11:14 AM, Seamus Kerrigan (skerriga) <
> > > > skerriga_at_cisco.com> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I've been doing some work with Jersey for the past while but
> yesterday
> > > I
> > > > > got to try out Jersey 0.7 and it looks as though Badgerfish
> notation
> > > is
> > > > > now the default JSON format again? I found that early Jersey
> versions
> > > > > were using Badgerfish by default but 0.6 was using the Mapped
> notation
> > > > > as it's default as outlined in Jakub's blog
> > > > > http://blogs.sun.com/japod/entry/better_json_available_in_jersey.
> > > > >
> > > > > I just have a couple of questions on this JSON formatting:
> > > > > - Is Badgerfish likely to be the preferred JSON notation in
> future
> > > > > Jersey releases?
> > > > > - Will XmlAttributes be supported in the Mapped/Mapped-Jettison
> > > > > formats?
> > > > > - The blog outlines a method of changing between JSON formats by
> > > > > defining a ContextResolver. Is still this valid in 0.7? I gave
> this a
> > > > > very quick try yesterday but was unsuccessful.
> > > > >
> > > > > Many thanks,
> > > > > Seamus
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > > > > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Stephan Schmidt :: stephan_at_reposita.org
> > > > Reposita Open Source - Monitor your software development
> > > > http://www.reposita.org
> > > > Blog at http://stephan.reposita.org - No signal. No noise.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> > >
> > >
> >
> >
> > --
> > Stephan Schmidt :: stephan_at_reposita.org
> > Reposita Open Source - Monitor your software development
> > http://www.reposita.org
> > Blog at http://stephan.reposita.org - No signal. No noise.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
--
Stephan Schmidt :: stephan_at_reposita.org
Reposita Open Source - Monitor your software development
http://www.reposita.org
Blog at http://stephan.reposita.org - No signal. No noise.