From: "Bryan Field-Elliot" <[EMAIL PROTECTED]> > 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.
:-) A Jelly script is a piece of XML that gets parsed in to a Script object that can be cached and reused across threads. When the script runs, it outputs SAX events. This XML can contain dynamic expressions (say XPath or Jexl or JavaScript or whatnot) as well as truly dynamic blocks of code (tags, beans, real scripting language blocks etc). The nice bit about this is the XML (or SAX events) get cached, so at runtime there's no need to parse the XML inside the Jelly script. Also each Jelly tag can process variables (beans, DOM fragments, text) or filter and pipeline XML events (SAX) so all kinds of processing models and pipelining mechanisms can be supported. So Jelly is great for generating dynamic XML, parsing, processing or filtering XML and pipelining into other processors (like SOAP servers, XSLT engines etc). http://jakarta.apache.org/commons/jelly/pipeline.html So its easy to mix and match working with SAX, DOM, XPath, XSLT, JARV, beans, SOAP etc. Plugging in JAXB where it makes sense would be pretty easy too. > 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. I think Jelly might help in the latter right now. e.g. there's tools for XSLT, XPath, parsing HTML and implementing SAX filters & SOAP calls. SOAP support is probably Jelly's weakest area right now. e.g. it might be cool to implement a JROM library for working with typesafe XML in an efficient generic structure. > 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? Its certainly got most of what you need. Probably the biggest missing part in your example is a SAX based 'pull a SOAP envelope apart and process with seperate business logic' piece. e.g. its been on the to do list for a while http://jakarta.apache.org/commons/jelly/todo.html to try add a STX library (thats like XSLT but works purely on SAX streams) while allowing Jelly tags to be invoked within the STX transformation - this could be good for splitting your SOAP message up into pieces. e.g. Joost is an STX implementation... http://joost.sourceforge.net/ Another approach could be just to use DOM, JROM or Castor/JAXB. The nice thing about having STX support (or your own custom SAX filter logic) would be that you could mix SOAP + SAX filters + any combination of (DOM / JROM / Castor / JAXB, beans etc) i.e. a single SOAP message could be split up into multiple parts, each part could be processed in a different way (e.g. one part use JAXB, one part use DOM, one part use SAX based XSLT, one using beans, one invoking an EJB etc). James ------- http://radio.weblogs.com/0112098/ __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
