You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Robert <rm...@bull-enterprises.com> on 2002/08/29 18:53:34 UTC
[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.
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!
Thoughts?
Thanks,
Robert McIntosh
RE: [Jelly]
Posted by 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>
Re: [Jelly]
Posted by 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]
Posted by Robert <rm...@bull-enterprises.com>.
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:
<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>
Re: [Jelly][Submit]A Jelly Servlet
Posted by Vinay Chandran <sa...@yahoo.com>.
Hi,
I agree that we need NOT have a "compiled script"
mechanism in case of serving
jelly scripts through servlets, we can do well with a
in-RAM cache.
BTW, I ran into a silly problem with jsl taglibs (code
snippet attached)
I am running the Script obj that one obtains in a
loop.
The output appears as expected the 1st time ,
but then onwards the stylesheets doesn't seem to work
on the XML document.
(Hope that I aint doing anything wrong here)
Regards,
Vinay
/*** Snippet Begins ***/
import java.io.BufferedReader;
import java.io.ByteArrayOutputStream;
import java.io.InputStreamReader;
import org.apache.commons.jelly.Jelly;
import org.apache.commons.jelly.JellyContext;
import org.apache.commons.jelly.Script;
import org.apache.commons.jelly.XMLOutput;
/**
* testing repeated executing of Script
*
* @author <a href="mailto:vinayc@apache.org">Vinay
Chandran</a>
*/
public class TestJSL
{
public static void main(String[] args) throws
Exception
{
Jelly jelly = new Jelly();
jelly.setScript("src/test/org/apache/commons/jelly/jsl/example.jelly");
Script script = jelly.compileScript();
JellyContext context=new JellyContext();
for (int i = 0; i < 3; i++)
{
ByteArrayOutputStream baos = new
ByteArrayOutputStream();
XMLOutput out =
XMLOutput.createXMLOutput(baos);
script.run(context, out);
out.flush();
System.out.println(i + ":" +
baos.toString());
}
}
}
/*** Snippet Ends***/
--- James Strachan <ja...@yahoo.co.uk> wrote:
> From: "James Elson" <ja...@xini.com>
> > Quoting Vinay Chandran <sa...@yahoo.com>:
> >
> > > Once we can somehow manage to externalize the
> state
> > > of the Script obj into a file(store) we can
> > > very well have a scenario whereby we can
> distribute
> > > compiled-scripts too.(thoughts?)
> >
> > Is it really that necessary? I agree that you
> wouldn't want to
> parse/compile the
> > Jelly script each time you request a page, but it
> seems like a bit of
> overhead
> > to compile them and keep them stored on disk.
> Wouldn't it be better to
> keep a
> > cache of compiled Script objects in memory (maybe
> with a limit of the
> number,
> > throwing away the least recently used). Suppose it
> depends on the
> complexity and
> > size of the scripts.
>
> Agreed. I think serializing them is a bit over the
> top, they are fairly
> lightweight to parse anyways.
>
>
> > I'd like to use Jelly scripts rather like JSP in
> that an update to the
> .jelly
> > file on disk would still be picked up immediately
> (without any of the
> nasty JSP
> > classloader issues!). A simple cache that checks
> the timestamp of the file
> > against a cached version before re-parsing should
> do.
>
> Agreed. I guess much of all this has been done in
> Velocity, it might be
> possible to share code somehow, or at least avoid
> reinventing the wheel.
>
>
> > What's the performance diffence between parsing a
> Jelly script from disk
> and
> > deserializing a Script object?
> >
> > Not sure why you'd want to distrubute compiled
> scripts rather than the XML
> > source though.
>
> Agreed. I think just having a RAM cache is all we
> need for now.
>
>
> 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>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly][Submit]A Jelly Servlet
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "James Elson" <ja...@xini.com>
> Quoting Vinay Chandran <sa...@yahoo.com>:
>
> > Once we can somehow manage to externalize the state
> > of the Script obj into a file(store) we can
> > very well have a scenario whereby we can distribute
> > compiled-scripts too.(thoughts?)
>
> Is it really that necessary? I agree that you wouldn't want to
parse/compile the
> Jelly script each time you request a page, but it seems like a bit of
overhead
> to compile them and keep them stored on disk. Wouldn't it be better to
keep a
> cache of compiled Script objects in memory (maybe with a limit of the
number,
> throwing away the least recently used). Suppose it depends on the
complexity and
> size of the scripts.
Agreed. I think serializing them is a bit over the top, they are fairly
lightweight to parse anyways.
> I'd like to use Jelly scripts rather like JSP in that an update to the
.jelly
> file on disk would still be picked up immediately (without any of the
nasty JSP
> classloader issues!). A simple cache that checks the timestamp of the file
> against a cached version before re-parsing should do.
Agreed. I guess much of all this has been done in Velocity, it might be
possible to share code somehow, or at least avoid reinventing the wheel.
> What's the performance diffence between parsing a Jelly script from disk
and
> deserializing a Script object?
>
> Not sure why you'd want to distrubute compiled scripts rather than the XML
> source though.
Agreed. I think just having a RAM cache is all we need for now.
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][Submit]A Jelly Servlet
Posted by James Elson <ja...@xini.com>.
Quoting Vinay Chandran <sa...@yahoo.com>:
> Once we can somehow manage to externalize the state
> of the Script obj into a file(store) we can
> very well have a scenario whereby we can distribute
> compiled-scripts too.(thoughts?)
Is it really that necessary? I agree that you wouldn't want to parse/compile the
Jelly script each time you request a page, but it seems like a bit of overhead
to compile them and keep them stored on disk. Wouldn't it be better to keep a
cache of compiled Script objects in memory (maybe with a limit of the number,
throwing away the least recently used). Suppose it depends on the complexity and
size of the scripts.
I'd like to use Jelly scripts rather like JSP in that an update to the .jelly
file on disk would still be picked up immediately (without any of the nasty JSP
classloader issues!). A simple cache that checks the timestamp of the file
against a cached version before re-parsing should do.
What's the performance diffence between parsing a Jelly script from disk and
deserializing a Script object?
Not sure why you'd want to distrubute compiled scripts rather than the XML
source though.
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly][Submit]A Jelly Servlet
Posted by Vinay Chandran <sa...@yahoo.com>.
James,
--- James Strachan <ja...@yahoo.co.uk> wrote:
> This looks a great first cut Vinay. Do you have the
> JellyCompiler and
> JellyScriptRunner that are referenced in your code?
>
Sorry, those imports went in accidently.
You can safely remove them.
Actually I started by developing the Servlet
implementation after I wrote the JellyCompiler
and JellyScriptRunner classes that would
store the Script obj(Serialized version of Script
class) and run the Script obj respectively.
Little did I realize that there were some
Non-serializable members within a few
classes , so I finally
went about removing the references of both of them
(Compiler and Runner).(But forgot to remove the
ref's from the JellyServlet classes)
> I do think we need to refactor the
> compiler/runner/embedded stuff abit into
> a cleaner design, but we're fairly close to having
> something useful.
>
Yes , I guess we can.
Once we can somehow manage to externalize the state
of the Script obj into a file(store) we can
very well have a scenario whereby we can distribute
compiled-scripts too.(thoughts?)
I am attaching the JellyCompiler and the
JellyScriptRunner.
Note:
These would NOT work since None of our classes are
serializable
(One can run the Hello_world.jelly
through the compiler and then through the runner
if you make the Script serializable and change the
TagScript class as per the temp-jelly.patch)
Regards,
Vinay
> James
> -------
> http://radio.weblogs.com/0112098/
> ----- Original Message -----
> From: "Vinay Chandran" <sa...@yahoo.com>
> To: "Jakarta Commons Developers List"
> <co...@jakarta.apache.org>
> Sent: Friday, August 30, 2002 5:35 AM
> Subject: [Jelly][Submit]A Jelly Servlet
>
>
> > Hi,
> > Attached here is a rudimentary JellyServlet
> capable of
> > serving URI's of the form *.jelly.
> > (configured through web.xml)
> > Right now it does nothing more than running the
> > mentioned script and sending the
> > output back to the client.
> >
> > Would it be NOT neat if one could have means to
> > serialize the o.a.c.jelly.Script obj
> > and then it read back and execute it,essentially
> > removing the step
> > of using the XML parser when executing the Script
> obj
> > again and again,after its
> > deserialized .
> > So essentially with this feature one can realize a
> > JellyCompiler, which can
> > compile( or shld I say convert) the Jelly XML
> scripts
> > into Script obj's which
> > can then be serialized and a JellyScriptRunner
> capable
> > of executing these
> > compiled jelly scripts the same way as an Jelly
> Engine
> > does right now .
> > Thoughts?
> >
> > Regards,
> > Vinay Chandrasekharan
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Finance - Get real-time stock quotes
> > http://finance.yahoo.com
>
>
>
----------------------------------------------------------------------------
> ----
>
>
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
> __________________________________________________
> 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>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
Re: [Jelly][Submit]A Jelly Servlet
Posted by James Strachan <ja...@yahoo.co.uk>.
This looks a great first cut Vinay. Do you have the JellyCompiler and
JellyScriptRunner that are referenced in your code?
I do think we need to refactor the compiler/runner/embedded stuff abit into
a cleaner design, but we're fairly close to having something useful.
James
-------
http://radio.weblogs.com/0112098/
----- Original Message -----
From: "Vinay Chandran" <sa...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Friday, August 30, 2002 5:35 AM
Subject: [Jelly][Submit]A Jelly Servlet
> Hi,
> Attached here is a rudimentary JellyServlet capable of
> serving URI's of the form *.jelly.
> (configured through web.xml)
> Right now it does nothing more than running the
> mentioned script and sending the
> output back to the client.
>
> Would it be NOT neat if one could have means to
> serialize the o.a.c.jelly.Script obj
> and then it read back and execute it,essentially
> removing the step
> of using the XML parser when executing the Script obj
> again and again,after its
> deserialized .
> So essentially with this feature one can realize a
> JellyCompiler, which can
> compile( or shld I say convert) the Jelly XML scripts
> into Script obj's which
> can then be serialized and a JellyScriptRunner capable
> of executing these
> compiled jelly scripts the same way as an Jelly Engine
> does right now .
> Thoughts?
>
> Regards,
> Vinay Chandrasekharan
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Finance - Get real-time stock quotes
> http://finance.yahoo.com
----------------------------------------------------------------------------
----
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
__________________________________________________
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>
[Jelly][Submit]A Jelly Servlet
Posted by Vinay Chandran <sa...@yahoo.com>.
Hi,
Attached here is a rudimentary JellyServlet capable of
serving URI's of the form *.jelly.
(configured through web.xml)
Right now it does nothing more than running the
mentioned script and sending the
output back to the client.
Would it be NOT neat if one could have means to
serialize the o.a.c.jelly.Script obj
and then it read back and execute it,essentially
removing the step
of using the XML parser when executing the Script obj
again and again,after its
deserialized .
So essentially with this feature one can realize a
JellyCompiler, which can
compile( or shld I say convert) the Jelly XML scripts
into Script obj's which
can then be serialized and a JellyScriptRunner capable
of executing these
compiled jelly scripts the same way as an Jelly Engine
does right now .
Thoughts?
Regards,
Vinay Chandrasekharan
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
Re: [Jelly]
Posted by bob mcwhirter <bo...@werken.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.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>