commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Field-Elliot <bryan_li...@netmeme.org>
Subject Re: Jelly and X++
Date Sat, 08 Feb 2003 18:39:55 GMT
On Sat, 2003-02-08 at 10:00, Paul Libbrecht wrote:

    You forgot one essential thing in there: Jelly can contain explicit
    XML 
    content making it more than appropriate for elementary
    XML-file-based 
    data processing.
    Such elementary thing as merging before handing to a stylesheet and 
    still processing its output with  a bit more scripting is something 
    that I have only seen at other places in ten times more verbose
    ways.
    

I imagine this is the kind of statement which would take me a month of
working with Jelly to fully appreciate.

My interest in these tools is not so much in "a language which can be
fully expressed in XML", but rather, "a language which gives me great
XML parsing, transforming, and business logic delegation capabilities",
something which I am dissatisfied with given the current crop of
Java/XML data binding tools.

What I need is to receive XML docs (usually via SOAP), tear them apart,
delegate business logic, and assemble responses (also XML docs), to send
back out over the wire again.

What dissatisfies me with the current crop of Java/XML data binding
tools (including Castor and JAXB), is the awkwardness with which you
have to deal with type extensions (<xsi:type>), where the original code
might know very well the base type, but not the extended type it's being
thrown at runtime. In this scenario, I'd like as lightweight-way as
possible to add business logic, without having to rebuild the whole
project from source, to deal with new types on an ongoing basis.

Castor/JAXB, etc take the approach that, "if you don't know the Schema
at compile time, then we can't deal with it, so go back to DOM". (Not to
disparage Castor, it's great in a whole of other ways).

Sounds like Jelly may be what I need?

Bryan


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message