Re: [Jelly]

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

Hi Robert

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

From: "Robert" <rm...@bull-enterprises.com>
> 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 that
> 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 mechanism.
> Meaning I want to invoke a script which in turn invokes some methods on
> 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 declarative
markups to procedural scripting.
There's libraries for SQL, HTTP, JMS (and hopefully soon SOAP/WSDL) that can
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

http://jakarta.apache.org/commons/sandbox/jelly/jellyswing.html

or defining dynamic rule bases

http://drools.org/examples.html

or process models and workflows

http://blissed.werken.com/jelly.html

etc.


> Our current script engine has a request object that gets populated with
> 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 done
> executing.
>
> Having looked further into Jelly, I can guess that I could model this
> behavior by supplying my input parameters in the JellyContext, and have
> my script populate the JellyContext with output parameters which my
> caller can then pull out as needed. Would this be a fair assumption? If
> so then that would be great!

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

James
-------
http://radio.weblogs.com/0112098/

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [Jelly]

[Robert <rm...@bull-enterprises.com>]

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.

Robert

-----Original Message-----
From: James Strachan [mailto:james_strachan@yahoo.co.uk] 
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
so
I found a few Jelly mails that I'd missed in all the commons-dev
traffic.

From: "Robert" <rm...@bull-enterprises.com>
> 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
that
> 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
mechanism.
> Meaning I want to invoke a script which in turn invokes some methods
on
> 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
declarative
markups to procedural scripting.
There's libraries for SQL, HTTP, JMS (and hopefully soon SOAP/WSDL) that
can
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

http://jakarta.apache.org/commons/sandbox/jelly/jellyswing.html

or defining dynamic rule bases

http://drools.org/examples.html

or process models and workflows

http://blissed.werken.com/jelly.html

etc.


> Our current script engine has a request object that gets populated
with
> 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
done
> executing.
>
> Having looked further into Jelly, I can guess that I could model this
> behavior by supplying my input parameters in the JellyContext, and
have
> my script populate the JellyContext with output parameters which my
> caller can then pull out as needed. Would this be a fair assumption?
If
> so then that would be great!

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

James
-------
http://radio.weblogs.com/0112098/

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>