cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject Jelly as a possible template or business language (was [RT] SpitScript and [RT] Flowmaps)
Date Fri, 21 Jun 2002 10:50:39 GMT
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 <nicolaken@apache.org>
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message