Jelly as a possible template or business language (was [RT] SpitScript and [RT] Flowmaps)

[James Strachan <ja...@yahoo.co.uk>]

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 <ni...@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

Re: Jelly as a possible template or business language (was [RT] SpitScript and [RT] Flowmaps)

[James Strachan <ja...@yahoo.co.uk>]

From: "Nicola Ken Barozzi" <ni...@apache.org>
> > From:     Nicola Ken Barozzi <ni...@apache.org>
> ...
> >> 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
> >
>
>
> James Strachan wrote:
> > 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.
>
> If we want to make a business logic system that is based on tasks, I have
> little doubt that we could find something better than Jelly :-)

Bless you ;-)

Though also making a business logic system based on other 'languages' could
be done with Jelly too. e.g. I'm pondering about making some tags for
working with drools' declarative rule language...

http://drools.org

So Jelly becomes like a glue to tie different languages, features, tasks and
mechanisms together.


> Not only can one reuse tags, but can use tag libraries that have been
> incompatible before to be used together.
>
> The question is: what *is* business logic?

To be business logic or not to be business logic that is the question ;-)


> If we make a Jelly business logic system, a Jelly Generator, a Jelly
> Transformer and a Jelly flow control system, what would prevent the
> developer from getting mixed up and not understand what to code where?

Totally agree.

How these different things are segregated and connected is a tricky
decision. Once its been decided, its easy to enforce with schema validation
and so forth. For example, imagine we have a number of modular mini-XML
languages to implement the parts, business logic, flow control, FSM or state
transition stuff and so forth, we end up with different schemas. We can, if
we wish, enforce that they are kept seperate or used together in a
controlled manner, enforcing what can or can't be used together etc. In many
ways this is nothing to do with Jelly per se - its about designing the XML
languages for these things (which may include other languages, XPath,
scheme, JavaScript etc) and how these 'languages' interact.

Its a tricky problem indeed and its gonna be fun solving it ;-). I really
was just mentioning Jelly to see if it could be useful at the implementation
stage; it really should not in any way affect the design of how things fit
together, since we're probably considering mostly declarative XML for much
of this I think. I think its also worth keeping an eye on the workflow
projects out there as well as they are trying to tackle similar issues using
declarative (usually XML) languages.

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

RE: Jelly as a possible template or business language (was [RT] SpitScript and [RT] Flowmaps)

[Vadim Gritsenko <va...@verizon.net>]

> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> 
> > From:     Nicola Ken Barozzi <ni...@apache.org>
> ...
> >> 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
> >
> 
> 
> James Strachan wrote:
> > 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.
> 
> If we want to make a business logic system that is based on tasks, I
have
> little doubt that we could find something better than Jelly :-)
> 
> Not only can one reuse tags, but can use tag libraries that have been
> incompatible before to be used together.
> 
> The question is: what *is* business logic?

Not going into discussion of what is business logic (in our part of
universe the answer is - EJB ;) ...

I think it does make sense to have JellyGenerator on same rights as
there is VelocityGenerator, because:

> James Strachan wrote:
> So in some ways Jelly is like Velocity, but using
> XML notation for directives rather than Velocity's # notation (more on
> this later).


Vadim


> If we make a Jelly business logic system, a Jelly Generator, a Jelly
> Transformer and a Jelly flow control system, what would prevent the
> developer from getting mixed up and not understand what to code where?
> 
> --
> Nicola Ken Barozzi                   nicolaken@apache.org
>              - verba volant, scripta manent -
>     (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Jelly as a possible template or business language (was [RT] SpitScript and [RT] Flowmaps)

[Nicola Ken Barozzi <ni...@apache.org>]

> From:     Nicola Ken Barozzi <ni...@apache.org>
...
>> 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
>


James Strachan wrote:
> 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.

If we want to make a business logic system that is based on tasks, I have
little doubt that we could find something better than Jelly :-)

Not only can one reuse tags, but can use tag libraries that have been 
incompatible before to be used together.

The question is: what *is* business logic?

If we make a Jelly business logic system, a Jelly Generator, a Jelly 
Transformer and a Jelly flow control system, what would prevent the 
developer from getting mixed up and not understand what to code where?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org