commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert" <rmcint...@bull-enterprises.com>
Subject RE: [Jelly]
Date Thu, 29 Aug 2002 17:59:52 GMT
Well that answers it then. Thanks a bunch for the insight. While I
haven't looked into how they use Jelly, I did notice that a lot of
projects use it internally. Maven was the one that actually led me to
Jelly in the first place.

Again, thanks for the insight.

Robert

-----Original Message-----
From: bob mcwhirter [mailto:bob@werken.com] 
Sent: Thursday, August 29, 2002 12:30 PM
To: Jakarta Commons Developers List
Subject: Re: [Jelly]

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

Look at maven.  While maven does do some output, it's mostly the firing
of methods that it finds important.  Also, blissed
(http://blissed.werken.com/)
and drools (http://drools.org/) have tag libraries that are not
targetting towards template output.

As far as request/response...  You can pass things to parent tags.

When <child> fires, it does some work (invoking its subtree, maybe),
and then calls some method on <parent>.  Tags can also put things
into the JellyContext under well-known-names for returning responses
to the calling java process.

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

Yah, that'd work.

> 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!

Ayup.

Jelly rocks.

	-bob


--
To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message