users@jersey.java.net

Re: [Jersey] Putting the RESTful "connectedness" around my existing Domain objects

From: Tatu Saloranta <tsaloranta_at_gmail.com>
Date: Fri, 10 Jul 2009 10:57:09 -0700

On Fri, Jul 10, 2009 at 12:59 AM, Martin Probst<mail_at_martin-probst.com> wrote:
>> I think I am asking for a templating language with Java EL
>> in addition to the existing JAXB approach.
>>
>> Thoughts?
>
> I think I would also need some sort of a view language for XML
> serialization. JAXB is in my opinion lacking a lot - it cannot

Or, perhaps moving from XML to JSON for data-oriented use cases (which
is what REST should be more about -- not users browsing web pages, but
systems accessing resources)?
A problem with XML is that it has high impedance to/from object (~=
struct) model, and that is big part of why there is no unambiguous
mapping between common things like java Maps and xml. This is not the
case for json (or yaml).
I am not saying json would be cure all, just that it is a better match
for data/object-oriented use cases; whereas XML is the right choice
for document-oriented use cases (with mixed content, looser, more
varied rich structure etc. etc).

...
> JAXB really is only a choice if you have very trivial Java Beans (not
> POJOs!) in your model. In my opinion, the whole Java -> XML|JSON
> mapping thing is far from being solved.

Just to make sure: beyond having issues with non-Bean(-like) objects
such as Maps, what do you see as fundamentally missing? Full Java
object serialization? (if so, XStream could solve this well -- JAXB is
not object serializer, but data binder/mapper)
Or is it just that for much of functionality, annotations are needed
to include non-bean methods?

Also: have you tried using natural json binding (direct use of
Jackson), or gson? What issues do you see there?

> That being said, beyond that I would suggest to "just" use XSLT on the
> resulting XML if you need a template language. It's a well thought out
> language and very powerful while being a really good match for the
> template use case. Things like Java EL make me shudder. Coming up with
> something that is actually significantly better than the existing
> template languages will be hard.

Although it is true that for XML->XML use case XSLT works, I am
wondering if this is just treating symptoms, not the problem. Does XML
have to be the representation to use?
If the goal is to transfer objects, transfer format is not the main
concern, but rather an implementation detail. If goal is to produce
XML, perhaps objects do need to accomodate. This is similar to the
dilemma ORM tools face: should they focus more on SQL, or Java
objects.

I agree in that there's probably no benefit for templating general XML
beyond what xsl can do: templating (X)HTML is a different story. For
that particular use case I think xslt is not a particularly good
match; a DSL (wrt xml->html with templating) can be created that is
more optimal.

-+ Tatu +-