Is there a JavaScript API for XML binding - analog to JAXB for Java?
Asked Answered
A

4

18

In Java, we work a lot with JAXB2. Object<->XML mappings are defined as annotations in Java classes:

@XmlRootElement(name="usertask", namespace="urn:test")
public class UserTask
{
    @XmlElement(namespace="urn:test")
    public String getAssignee() { ... }

    public void setAssignee(String assignee) { ... }
}

JAXB runtime can read these annotations and create unmarshaller to parse XML into an object instance or marshall an object into XML.

JAXB ships a schema compiler (XJC) which can generate annotated classes out of XML Schemas, which is another great feature.


Lately we've been working a lot with client-side JavaScript. An we also need XML processing there. For example, we need to parse WPS documents like this one. These documents also comply to different XML schemas (here's the WPS 1.0.0 schema for the sample XML). It would be great to work with JavaScript objects instead of XML, this saves really huge amount of effort. In some cases we can use JSON-based solutions like DWR, but in many cases we do have to process XML on the client-side.

My question is:

Is there some analog of JAXB for JavaScript?

Some tool which would compile an XML Schema into some XML<->object mapping and provide a runtime to convert between XML and JavaScript objects?

I could easily imagine mappings generated in a form like:

UserTask = new JSXML.XmlRootElement({
  name: "usertask",
  namespace: "urn:test",
  properties: [
    {
      assignee: new JSXML.XmlElement({
        name: "assignee",
        namespace: "urn:test",
        type: new JSXML.XSD.String()
      })
    }
  ]
});

And this should be pretty enough to build unmarshaller or marshaller.

Alsatian answered 29/9, 2010 at 6:17 Comment(0)
R
0

How about JSON support for JAXB? Reuse your current JAXB annotated model classes but output JSON from your REST endpoints.

Current versions of Jersey support this (via the jersey-json module) with JSONJAXBContext.

You could also try Jackson's JAXB and JAX-RS support.

Reconstructive answered 29/1, 2011 at 21:46 Comment(1)
JSON support for JAXB is exactly what I need. But on the client-side, in pure JavaScript. Jersey and Co. can be used on the server side. Right now we have a DWR-based server side solution which works fine as well. But I need client-only solution (server-side proxy is still ok).Alsatian
A
29

To date, I have found nothing similar to what I need. Therefore I've deсided to implement it myself. Here's the project page:

http://confluence.highsource.org/display/MISC/Jsonix

The project is hosted on GitHub:

https://github.com/highsource/jsonix/

Alsatian answered 27/10, 2010 at 11:17 Comment(0)
T
3

I haven't tried this, so I'm not sure if it will work, but have you considered using GWT so that you can still use JAXB and write the whole app as a java app? I'm not sure if GWT supports JAXB (probably not), but there might be an alternative for xml parsing that it will support. If this works, you could automate the creation of your javascript models via gwt, and then include these into your app. Yes, it's a lot more cruft than you want, but beats having to write it from scratch.

Tori answered 28/10, 2010 at 20:32 Comment(0)
R
2

What you can do is add a generic stylesheet definition: XSLT to your XML to convert them in JSON. eg: http://code.google.com/p/xml2json-xslt/

Handling XML with Javascript is a pain compared to JSON, especially cross browser.
The stylesheet will add a small overhead to your request. Either on the server or client side, you can choose, but you have to compare this to the code complexity and speed to parse and read the XML with Javascript on different browsers.

Requital answered 29/9, 2010 at 7:14 Comment(4)
The XSLT solution is not suitable for a number of reasons. First, we need a client-side processing. Bringing an XSLT processor to convert from XML into JSON is way too heavy, unacceptably heavy. I think XSLT is not the best choice of technology here anyway: what can be done with a 7K XSLT can be done with 3K JavaScript - an you won't need an XSLT processor on the client side.Alsatian
Second, an XSLT like the one you posted the link to is not schema-specific. For instance, if you have an <item>foo</item> element, you'll actually don't know if this must be a single item: 'foo' or an array item: ['foo']. Having 2010 you don't know if it's a year or a number and so on. XML<->object mapping must be schema-derived here to provide appropriate structure and type information which an XML instance per se does not provide.Alsatian
Adding a header like <?xml-stylesheet type="text/xml" href="xml2json.xsl"?> in your XML's is understood by all browsers without adding anything, or you can make it server side(nginx is really good at that). Moving to JSON imply some tradeoffs, especially regarding schemas, types etc... But for me it is worth the loss.Requital
"...worth the loss" doesn't make sense. You're suggesting something that doesn't actually accomplish what OP wants to do.Catarinacatarrh
R
0

How about JSON support for JAXB? Reuse your current JAXB annotated model classes but output JSON from your REST endpoints.

Current versions of Jersey support this (via the jersey-json module) with JSONJAXBContext.

You could also try Jackson's JAXB and JAX-RS support.

Reconstructive answered 29/1, 2011 at 21:46 Comment(1)
JSON support for JAXB is exactly what I need. But on the client-side, in pure JavaScript. Jersey and Co. can be used on the server side. Right now we have a DWR-based server side solution which works fine as well. But I need client-only solution (server-side proxy is still ok).Alsatian

© 2022 - 2024 — McMap. All rights reserved.