cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Jelly as a possible template or business language (was [RT] SpitScript and [RT] Flowmaps)
Date Fri, 21 Jun 2002 12:45:40 GMT
From: "Nicola Ken Barozzi" <>
> > From:     Nicola Ken Barozzi <>
> ...
> >> 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
> > implement the flow / workflow language defined in the commons-workflow
> > component in Jakarta Commons sandbox, or any other declarative XML
> >
> > Lately I've been looking into using Jelly to implement declarative
> > 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
> > turn that into a running script. So its on my todo list to investigate
> > 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
> > 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...

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.


Do You Yahoo!?
Get your free address at

To unsubscribe, e-mail:
For additional commands, email:

View raw message