commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert" <>
Subject RE: [Jelly]
Date Wed, 02 Oct 2002 16:15:32 GMT
Sorry for the slow response! Thanks a bunch for your comments. I've
started looking at jelly in more depth the last couple of days and I'm
really liking it. It is what I wish I had time to do myself :-) Since
jelly is so far ahead of our own effort, I'm sure we will switch soon.

Again, thanks for the feedback.


-----Original Message-----
From: James Strachan [] 
Sent: Friday, September 27, 2002 8:16 AM
To: Jakarta Commons Developers List
Subject: Re: [Jelly]

Hi Robert

Sorry for the very slow reponse. I've finally sorted out my mail filters
I found a few Jelly mails that I'd missed in all the commons-dev

From: "Robert" <>
> I've been going through the Jelly documentation with great interest
> lately as the company I work for has built an XML-based script engine
> for our product and we are thinking of the possibility of swapping
> out for Jelly in the future. My question then is one of design. It
> appears that Jelly is focused on a template style approach, i.e. JSP,
> Velocity, etc. I make that statement based on the use of the XMLOutput
> class for outputting the results of the script. What I need though is
> not a template mechanism but a purely declarative invocation
> Meaning I want to invoke a script which in turn invokes some methods
> objects and get a response back to the caller of the script; a
> request/response as opposed to a fire-and-forget model.

Sounds cool.

Jelly can be used for many different things from templating to
markups to procedural scripting.
There's libraries for SQL, HTTP, JMS (and hopefully soon SOAP/WSDL) that
do declarative invocation mechanism which can be invoked as scripts.

There's all kinds of uses of Jelly such as JellySwing for creating
declarative rich user interfaces

or defining dynamic rule bases

or process models and workflows


> Our current script engine has a request object that gets populated
> parameters/data (similar to how Velocity populates it's context), the
> script is executed by name (all scripts are loaded and 'compiled' at
> startup), the script populates the response object, and the response
> object is given as a return value to the caller when the script is
> executing.
> Having looked further into Jelly, I can guess that I could model this
> behavior by supplying my input parameters in the JellyContext, and
> my script populate the JellyContext with output parameters which my
> caller can then pull out as needed. Would this be a fair assumption?
> so then that would be great!

Definitely - this is exactly how Jelly works. It sounds like a good


Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

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

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message