With recent talk of flow scripts and declarative business languages I thought I'd briefly introduce Jelly to the list. I'm really interested in hearing anyones thoughts on the applicability of Jelly to the flow / template / business language discussions. OK here goes...
Jelly is a simple, lightweight, modular Java and XML processing engine Its a little hard to describe what Jelly is briefly, but here's my attempt... http://jakarta.apache.org/commons/sandbox/jelly/ <detail> Jelly is conceptually like JSP custom tags, where a fully qualified element name is mapped to a 'Tag' (a Java bean) and the attributes of the element usually map onto the tags bean properties. Though Jelly does not use JSP nor has any dependency on Servlets per se so it can easily be embedded in an XML pipeline, web service, called from Ant or bound to a Servlet etc. Jelly supports a variety of plugin expression languages (and scripting languages) such as Jexl (which is very like Velocity and is also a superset of the expression language in JSTL and JSP 2.0) as well as XPath, beanshell, JavaScript, Jython etc. So in some ways Jelly is like Velocity, but using XML notation for directives rather than Velocity's # notation (more on this later). Jelly implements a subset of JSTL (the JSP Standard Tag Library) so has tags for working with beans, XML, XPath and SQL. Like Velocity, JSTL and JSP, Jelly can work with different variable scopes (page, request, session, applicaiton, parameter, system properties etc) which also allows different languages to interact together inside a Jelly script. e.g. you can work with beans via Jexl and XML via XPath mixing and matching inside one script. <!-- navigate bean properties --> <j:set var="myZip" value=${customer.address.zipCode}"/> <!-- do XPath using the same variable scopes --> <x:forEach select="//foo[zip = $myZip]"> ... </x:forEach> Also Jelly can script Ant tasks while making use of decent expression languages for expressions, boolean logic, looping etc. For example the Maven project in CVS HEAD is currently using Jelly as an alternative XML engine to Ant for scripting its Ant tasks and providing a more powerful and flexible callback mechanism as well as tag macros to avoid verbose typing. One major difference with Jelly over JSP and Velocity is that it uses an XML pipeline (rather than text) for its output. So a single Jelly tag can consume, emit, filter or transform XML events (SAX). In many ways a Jelly tag is like a step in an XML pipeline. So a tag can evaluate its body (as many times as it wishes) and consume the SAX events its body produces and output SAX events to its parent tag. This allows quite complex XML pipelines to be created, particularly when considering things like web services where XML is created, piped, transformed, filtered, validated and so forth. e.g. <x:transform xslt="foo.xsl"> <babelfish:translate from="en" to="fr"> Hello there ${user.name} we currently have <x:valueOf select="count($someDoc/order/items)"/> items outstanding </babelfish:transate> </x:transform> The above example is using a SOAP macro tag <babelsifh:translate> that expands when the script is parsed into making a full web service call, sending its body (after the SOAP envelope is added), parsing the result and outputting SAX events, maybe after filtering out the response envelope. Jelly tags can be defined in Java code, or via Jelly script (there's a tag library for creating new tags and tag libraries dynamically in Jelly scripts). </detail> OK if you're still reading this - thank you! :-). I do find it a bit hard to describe what Jelly is and what its good for. It often takes folks a little while before the penny drops and sometimes there's some glazed eyes along the way :) So to summarize the above, Jelly could be an alternative template language in Cocoon as an alternative to JSP, XSP or Velocity. Now onto business logic and flowmap discussions... From: Nicola Ken Barozzi <[EMAIL PROTECTED]> Subject: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps > Ok, let's start this really /proactive/ (I love this word, it just fills > one's mouth ;-) RT about a business logic definition system that has > these goals: > > 1. has a quick write-test-correct cycle, ie not to be compiled > 2. is easy to write and understand > 3. is modular > 4. will make flowscript a solution to a problem, not a problem itself Certainly I think Jelly solves all the above goals. One of the things I wanted Jelly to do is to take existing declarative langauges for workflow, rules, business logic, testing, building and so forth and turn them into running code easily. So Jelly could, for example, implement the flow / workflow language defined in the commons-workflow component in Jakarta Commons sandbox, or any other declarative XML language. Lately I've been looking into using Jelly to implement declarative workflow style XML languages. There's a bunch of them out there like BPML, XLang, WfMC, WSFL etc. What I'd like is for us to design the most appropriate declarative XML language for the problem at hand, then try to use Jelly to turn that into a running script. So its on my todo list to investigate using Jelly with projects like OSWorkflow to implement the declarative part of business logic, make tag libraries for rules engines like drools or for state transition modules etc. I hope some of this has made some sense to some of you ;-). I'd appreciate any comments you might have. James _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
