You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by James Strachan <ja...@yahoo.co.uk> on 2002/03/06 16:24:31 UTC
[workflow] Jelly <-> Workflow maybe some crossover
I've been experimenting with (yet another) scripting language called Jelly.
Its kinda like JSP custom tags without the JSP, borrowing ideas from
Velocity and XDoclet and its really simple & lightweight & embeddable. I
plan on integrating BSF so that JavaScript et al could be embedded inside
tags with maybe Velocity as an expression language. Jelly could implement
the JSTL tags too if need be. There's some documentation in CVS if folks are
interested learning more.
The idea behind Jelly was that XML allows extensible tags (e.g. JSTL, Struts
etc) so I wanted a simple way to be able to script complex stuff like making
a SOAP call, doing XSLT, JMS messaging, HTTP malarkey along with working
with Java beans all in a simple XML language. Though I didn't want to base
it on JSP so it could be used anywhere (from Ant or whatever). One objective
a bit further down the line was to make a simple SOAP scripting engine that
based on a WSDL file or some jelly script to make a new tag to do useful
stuff. e.g.
<babelfish:translate from="en" to="fr">
using simple XML scripting with SOAP under the covers
</babelfish:translate>
Well I started looking again at Workflow today and it got me thinking - both
efforts are kinda similar though from completely different perspectives. All
the Steps are quite close, programatically to the Tags I'd started writing.
The major difference is the 'run' methods are execute(Context) and
run(Context, Writer) respectively. So Jelly allows scripts to output stuff
which Workflow does not right now, other than that, spookily similar. Also
both Jelly and Workflow have a Context which is similar to an abstraction of
JSP scopes and Activity & Block are similar to the Script stuff in Jelly.
Quite what all this means I'm not sure :-) but what could be really useful
is if we could have a single API for writing 'Steps' or 'Tags' then both
projects could share them.
e.g. I'm gonna write a bunch of 'tags' for doing HTTP (using httpclient),
JMS (using messenger), SOAP (probably using Axis), XSLT as well as the
existing XPath ones and JSTL-like core tags using a pluggable expression
languages (which right now is beanshell but will be BSF soon). Ultimately I
was gonna try plugin XDoclet tags too then we could mix and match scripting
languages, JSTL, various other tags and XDoclet all from one 'declarative
XML based script'.
It'd be nice to be able to share all this stuff across both Workflow and
Jelly. Maybe Jelly scripts could be part (or all) of an activity in Workflow
too but thats maybe more complex.
Thoughts?
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [workflow] Jelly <-> Workflow maybe some crossover
Posted by Paulo Gaspar <pa...@krankikom.de>.
> > Maybe we could rename the workflow project to be called 'sandwich' :-)
>
> PBNJ might be a little more subtle. ;-)
For some reason I always prefer the gastronomic solutions.
=;o)
Have fun,
Paulo
> -----Original Message-----
> From: Martin Cooper [mailto:martin.cooper@tumbleweed.com]
> Sent: Thursday, March 07, 2002 8:31 AM
> To: Jakarta Commons Developers List
> Subject: Re: [workflow] Jelly <-> Workflow maybe some crossover
>
>
>
> ----- Original Message -----
> From: "James Strachan" <ja...@yahoo.co.uk>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Wednesday, March 06, 2002 4:38 PM
> Subject: Re: [workflow] Jelly <-> Workflow maybe some crossover
>
>
> > From: "Geir Magnusson Jr." <ge...@optonline.net>
> > > On 3/6/02 4:28 PM, "James Strachan"
> <ja...@yahoo.co.uk> wrote:
> > >
> > > [SNIP]
> > >
> > > >
> > > > could be used to work with pnuts inside Jelly. I'll let you
> know when
> > > > there's some Jelly'd pnuts in CVS.
> > > >
> > >
> > > I can't wait for the inevitable jokes.
> > >
> > > All we need is some package named something like 'butter4J' to give us
> > > solutions based on pnuts, butter4J and Jelly.
> >
> > Maybe we could rename the workflow project to be called 'sandwich' :-)
>
> PBNJ might be a little more subtle. ;-)
>
> --
> Martin Cooper
>
>
> >
> > James
> >
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [workflow] Jelly <-> Workflow maybe some crossover
Posted by Martin Cooper <ma...@tumbleweed.com>.
----- Original Message -----
From: "James Strachan" <ja...@yahoo.co.uk>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, March 06, 2002 4:38 PM
Subject: Re: [workflow] Jelly <-> Workflow maybe some crossover
> From: "Geir Magnusson Jr." <ge...@optonline.net>
> > On 3/6/02 4:28 PM, "James Strachan" <ja...@yahoo.co.uk> wrote:
> >
> > [SNIP]
> >
> > >
> > > could be used to work with pnuts inside Jelly. I'll let you know when
> > > there's some Jelly'd pnuts in CVS.
> > >
> >
> > I can't wait for the inevitable jokes.
> >
> > All we need is some package named something like 'butter4J' to give us
> > solutions based on pnuts, butter4J and Jelly.
>
> Maybe we could rename the workflow project to be called 'sandwich' :-)
PBNJ might be a little more subtle. ;-)
--
Martin Cooper
>
> James
>
>
> --
> 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: [workflow] Jelly <-> Workflow maybe some crossover
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Geir Magnusson Jr." <ge...@optonline.net>
> On 3/6/02 4:28 PM, "James Strachan" <ja...@yahoo.co.uk> wrote:
>
> [SNIP]
>
> >
> > could be used to work with pnuts inside Jelly. I'll let you know when
> > there's some Jelly'd pnuts in CVS.
> >
>
> I can't wait for the inevitable jokes.
>
> All we need is some package named something like 'butter4J' to give us
> solutions based on pnuts, butter4J and Jelly.
Maybe we could rename the workflow project to be called 'sandwich' :-)
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [workflow] Jelly <-> Workflow maybe some crossover
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/6/02 4:28 PM, "James Strachan" <ja...@yahoo.co.uk> wrote:
[SNIP]
>
> could be used to work with pnuts inside Jelly. I'll let you know when
> there's some Jelly'd pnuts in CVS.
>
I can't wait for the inevitable jokes.
All we need is some package named something like 'butter4J' to give us
solutions based on pnuts, butter4J and Jelly.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The bytecodes are language independent. - Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [workflow] Jelly <-> Workflow maybe some crossover
Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Paulo
----- Original Message -----
From: "Paulo Gaspar" <pa...@krankikom.de>
> Hi James,
> answer inline:
>
> > -----Original Message-----
> > From: James Strachan [mailto:james_strachan@yahoo.co.uk]
> > Sent: Thursday, March 07, 2002 9:41 PM
> >
> > ----- Original Message -----
> > From: "Paulo Gaspar" <pa...@krankikom.de>
> > > Hi James,
> > >
> > >
> > > I think that pnuts is not so efficient when using it trough BSF,
> > > but I do not remeber the specifics so well anymore.
> >
> > Actually I've just done the BSF integration with Jelly and you're right.
I
> > think I'll add a tag library to go direct to pnuts shortly, certainly
> > getting access to pnuts compiling would be better for sure. BSF
> > just allows
> > you to get a CodeBuffer which contains the Java code in it, which you
have
> > to compile & classload yourself.
>
> In my experience it is worth the trouble. When compiled I notice no
> difference from Java code and compiling it the 1t time takes much
> less time than a similar JSP script (which is natural since the
> compilation is all done in memory).
>
> Keep in mind the class loader issues. Posting the fix to the pnuts
> list together with its reason is in my todo list for some time, I
> will try to do it this week so that it can benefit your work too.
>
> Basically, I remember that one of the problems is avoided if you
> always initialize the Context's class loader. The other problem
> also has to do with having a ClassLoader set to null.
>
> I only noticed these issues when running the code from a Servlet
> outside JBuilder. Inside JBuilder it runs fine.
Thanks for that.
> > I'd be interested in finding out more on how you integrate pnuts with
XML.
>
> Well, this thing is a bit like Cocoon with a much lower level of XML
> obsession.
> =;o)
>
> I read the xml configuration/structure via Avalon's configuration
> mechanism
> jakarta-avalon\src\java\org\apache\avalon\framework\configuration
>
> and I manage the components using something like Avalon's
> ComponentManager. Although mine is a VERY HEAVILY modified version, the
> ideas are basically the same.
>
> Then the trick is to expose some bits of the ComponentManager to the
> script as part of an "object model" that also includes request
> information and things like that (for a Servlet, but this could be used
> for any other kinds of software).
>
>
> Since I am not very original, there is even a "main" run somewhere,
> although I have no use for things like:
> <forEach>, <if>, <choose><when><otherwise>
Though the <choose-folder><when><otherwise> looks familier. So in Jelly you
could do this as follows...
<p:choose>
<p:when test='$uri="kino/film"'>
<p:script url="${film.pnut}"/>
</p:when>
<p:when test='uri="kino/address"'>
<p:script url="${film.address}"/>
</p:when>
<p:otherwise>
...
</p:otherwise>
</p:choose>
> The xml bit only controls "high level" flow, as in:
>
> <run name="main">
> <choose-folder>
> <when uri="kino/film">
> <run-pnuts direct-out="true" >
> <text-url url="${film.pnut}" />
> </run-pnuts>
> </when>
> <when uri="kino/adress">
> <run-pnuts direct-out="true" >
> <text-url url="${adress.pnut}" />
> </run-pnuts>
> </when>
> ...
> <otherwise>
> <match-uri wildcard="module/my-module/**">
> <run-module prefix="module/my-module/"
> module="my-module" />
> </match-uri>
> ...
> </otherwise>
> </choose-folder>
> </run>
>
> More detailed logic I leave for the scripting bits or I would end
> up inventing YAPL (Yet Another Programming Language).
> =;o)
Agreed. This is generally the tack I'm taking with Jelly - let it do the
high level declarative bits and use a real scripting language (Velocity,
pnuts, beanshell, JavaScript etc) for the lower level stuff.
> > Maybe Jelly could be a useful engine for you?
>
> Maybe I am messing around with something like Jelly. The problem
> is that we are not sure we want to Open Source its core.
>
> But there are many other bits that we want.
>
>
> Look, my problem is still spending the time to repackage those
> bits in order to make them available, but if you are interested
> I can post them just "half packed", which means that the source
> will be:
> - Not very well documented or not documented at all;
> - Some dependencies will be removed in a rough way, BUT I will
> document that.
>
> But I actually have interesting bits like the
> - PnutsModifiableScript;
> - StaticPnutsScript;
> or the
> - PnutsRunInstance.
>
> (This bits imply some other bits of code, of course).
I'll see how I get on integrating pnuts into Jelly and let you know. By all
means fire off some 'half-packed' stuff to me and I'll see what I can do.
> > Much of the above code should
> > be pretty easy to use in Jelly. Fairly soon there'll be JSTL-style
> > <forEach>, <if>, <choose><when><otherwise>, <expr> and <set> tags
> > that work
> > with JavaScript/BSF/JPython, Beanshell, Velocity and Pnuts. The
> > idea is that
> > we can bind any element name to a 'tag' to do anything, be it pnuts,
> > Velocity stuff, JavaScript, XSLT, XPath, SQL or whatnot.
>
> Your idea seems very similar to what I am doing. I hope you follow
> Avalon and Cocoon because that helps a lot even when you do not
> agree with everything they do or say (I sure don't).
I try to - though I should probably follow Avalon more than I do.
> Another interesting bit is Ant's Myrmidon proposal (by Peter Donald)
> from where I got the Converter and Configurator ideas. The
> Configurator is big step beyond Avalon's Configuration stuff.
Thanks I'll take a look at Myrmidon.
> And, BTW, it works. There are already several small things in
> production using this stuff and the development cycle was MUCH
> faster. And it really looks like the gain will be even larger for
> larger sites. Java + Velocity + XML-and-Pnuts-glue is a
> Very Good Thing (tm).
Agreed!
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [workflow] Jelly <-> Workflow maybe some crossover
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi James,
answer inline:
> -----Original Message-----
> From: James Strachan [mailto:james_strachan@yahoo.co.uk]
> Sent: Thursday, March 07, 2002 9:41 PM
>
> ----- Original Message -----
> From: "Paulo Gaspar" <pa...@krankikom.de>
> > Hi James,
> >
> >
> > I think that pnuts is not so efficient when using it trough BSF,
> > but I do not remeber the specifics so well anymore.
>
> Actually I've just done the BSF integration with Jelly and you're right. I
> think I'll add a tag library to go direct to pnuts shortly, certainly
> getting access to pnuts compiling would be better for sure. BSF
> just allows
> you to get a CodeBuffer which contains the Java code in it, which you have
> to compile & classload yourself.
In my experience it is worth the trouble. When compiled I notice no
difference from Java code and compiling it the 1t time takes much
less time than a similar JSP script (which is natural since the
compilation is all done in memory).
Keep in mind the class loader issues. Posting the fix to the pnuts
list together with its reason is in my todo list for some time, I
will try to do it this week so that it can benefit your work too.
Basically, I remember that one of the problems is avoided if you
always initialize the Context's class loader. The other problem
also has to do with having a ClassLoader set to null.
I only noticed these issues when running the code from a Servlet
outside JBuilder. Inside JBuilder it runs fine.
> ...
>
> This all looks great stuff Paulo.
Thanks!
=:o)
> I'd be interested in finding out more on how you integrate pnuts with XML.
Well, this thing is a bit like Cocoon with a much lower level of XML
obsession.
=;o)
I read the xml configuration/structure via Avalon's configuration
mechanism
jakarta-avalon\src\java\org\apache\avalon\framework\configuration
and I manage the components using something like Avalon's
ComponentManager. Although mine is a VERY HEAVILY modified version, the
ideas are basically the same.
Then the trick is to expose some bits of the ComponentManager to the
script as part of an "object model" that also includes request
information and things like that (for a Servlet, but this could be used
for any other kinds of software).
Since I am not very original, there is even a "main" run somewhere,
although I have no use for things like:
<forEach>, <if>, <choose><when><otherwise>
The xml bit only controls "high level" flow, as in:
<run name="main">
<choose-folder>
<when uri="kino/film">
<run-pnuts direct-out="true" >
<text-url url="${film.pnut}" />
</run-pnuts>
</when>
<when uri="kino/adress">
<run-pnuts direct-out="true" >
<text-url url="${adress.pnut}" />
</run-pnuts>
</when>
...
<otherwise>
<match-uri wildcard="module/my-module/**">
<run-module prefix="module/my-module/"
module="my-module" />
</match-uri>
...
</otherwise>
</choose-folder>
</run>
More detailed logic I leave for the scripting bits or I would end
up inventing YAPL (Yet Another Programming Language).
=;o)
> Maybe Jelly could be a useful engine for you?
Maybe I am messing around with something like Jelly. The problem
is that we are not sure we want to Open Source its core.
But there are many other bits that we want.
Look, my problem is still spending the time to repackage those
bits in order to make them available, but if you are interested
I can post them just "half packed", which means that the source
will be:
- Not very well documented or not documented at all;
- Some dependencies will be removed in a rough way, BUT I will
document that.
But I actually have interesting bits like the
- PnutsModifiableScript;
- StaticPnutsScript;
or the
- PnutsRunInstance.
(This bits imply some other bits of code, of course).
> Much of the above code should
> be pretty easy to use in Jelly. Fairly soon there'll be JSTL-style
> <forEach>, <if>, <choose><when><otherwise>, <expr> and <set> tags
> that work
> with JavaScript/BSF/JPython, Beanshell, Velocity and Pnuts. The
> idea is that
> we can bind any element name to a 'tag' to do anything, be it pnuts,
> Velocity stuff, JavaScript, XSLT, XPath, SQL or whatnot.
Your idea seems very similar to what I am doing. I hope you follow
Avalon and Cocoon because that helps a lot even when you do not
agree with everything they do or say (I sure don't).
Another interesting bit is Ant's Myrmidon proposal (by Peter Donald)
from where I got the Converter and Configurator ideas. The
Configurator is big step beyond Avalon's Configuration stuff.
And, BTW, it works. There are already several small things in
production using this stuff and the development cycle was MUCH
faster. And it really looks like the gain will be even larger for
larger sites. Java + Velocity + XML-and-Pnuts-glue is a
Very Good Thing (tm).
> James
Have fun,
Paulo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [workflow] Jelly <-> Workflow maybe some crossover
Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Paulo
----- Original Message -----
From: "Paulo Gaspar" <pa...@krankikom.de>
> Hi James,
>
>
> I think that pnuts is not so efficient when using it trough BSF,
> but I do not remeber the specifics so well anymore.
Actually I've just done the BSF integration with Jelly and you're right. I
think I'll add a tag library to go direct to pnuts shortly, certainly
getting access to pnuts compiling would be better for sure. BSF just allows
you to get a CodeBuffer which contains the Java code in it, which you have
to compile & classload yourself.
> Using some of its specifics one can really minimize parsing and
> compiling to the minimum (once per change) and use each compiled
> instance in a multi threader application.
Agreed.
> It is also nice to allow external scripts, like in this fragment
> that actually is working somewhere:
>
> <when uri="kino/film">
> <run-pnuts direct-out="true" >
> <text-url url="${film.folder}/film.pnut" />
> </run-pnuts>
> </when>
>
> The text bit is more verbose but is due to the fact that I have
> a common text loading mechanism also present here, as in this
> debug code bit:
>
> <match-uri wildcard="**/*">
> <run-pnuts direct-out="true">
> <text>
> println();
> println("wildcard=**/*");
> println("<h5>matches = " + matches +
> "</H5>");
> </text>
> </run-pnuts>
> </match-uri>
>
> ...but also present in non pnuts related bits, like with SQL
> statements. The text loading helps
>
>
> Actually I am NOT using the <text> mechanism for SQL anywhere
> because pnuts makes it so easy to write SQL by using those "`"
> quotes for multi-line strings, as in:
> sql =
> `SELECT
> addr_id,
> caption,
> phone,
> fax,
> zipcode,
> street,
> doornumber,
> city,
> cityzone,
> remarks
> FROM address
> WHERE ADDR_ID=` + id
>
> =:o)
>
> Pnuts documentation is not always easy to follow, but it is
> still much better than most open source projects. And although
> you might find some features/quirks weird, after some use all
> of it ends up making a lot of sense.
>
> For me Pnuts is one of those rare:
> "the more I use it the more I like it!"
>
> I even get to think that generating JSPs troug Pnuts would
> simplify a LOT the current issues by compiling them (faster)
> without writing to the disk.
This all looks great stuff Paulo.
I'd be interested in finding out more on how you integrate pnuts with XML.
Maybe Jelly could be a useful engine for you? Much of the above code should
be pretty easy to use in Jelly. Fairly soon there'll be JSTL-style
<forEach>, <if>, <choose><when><otherwise>, <expr> and <set> tags that work
with JavaScript/BSF/JPython, Beanshell, Velocity and Pnuts. The idea is that
we can bind any element name to a 'tag' to do anything, be it pnuts,
Velocity stuff, JavaScript, XSLT, XPath, SQL or whatnot.
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [workflow] Jelly <-> Workflow maybe some crossover
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi James,
I think that pnuts is not so efficient when using it trough BSF,
but I do not remeber the specifics so well anymore.
Using some of its specifics one can really minimize parsing and
compiling to the minimum (once per change) and use each compiled
instance in a multi threader application.
It is also nice to allow external scripts, like in this fragment
that actually is working somewhere:
<when uri="kino/film">
<run-pnuts direct-out="true" >
<text-url url="${film.folder}/film.pnut" />
</run-pnuts>
</when>
The text bit is more verbose but is due to the fact that I have
a common text loading mechanism also present here, as in this
debug code bit:
<match-uri wildcard="**/*">
<run-pnuts direct-out="true">
<text>
println();
println("wildcard=**/*");
println("<h5>matches = " + matches +
"</H5>");
</text>
</run-pnuts>
</match-uri>
...but also present in non pnuts related bits, like with SQL
statements. The text loading helps
Actually I am NOT using the <text> mechanism for SQL anywhere
because pnuts makes it so easy to write SQL by using those "`"
quotes for multi-line strings, as in:
sql =
`SELECT
addr_id,
caption,
phone,
fax,
zipcode,
street,
doornumber,
city,
cityzone,
remarks
FROM address
WHERE ADDR_ID=` + id
=:o)
Pnuts documentation is not always easy to follow, but it is
still much better than most open source projects. And although
you might find some features/quirks weird, after some use all
of it ends up making a lot of sense.
For me Pnuts is one of those rare:
"the more I use it the more I like it!"
I even get to think that generating JSPs troug Pnuts would
simplify a LOT the current issues by compiling them (faster)
without writing to the disk.
Have fun,
Paulo
> -----Original Message-----
> From: James Strachan [mailto:james_strachan@yahoo.co.uk]
> Sent: Wednesday, March 06, 2002 10:29 PM
> To: Jakarta Commons Developers List; paulo.gaspar@krankikom.de
> Subject: Re: [workflow] Jelly <-> Workflow maybe some crossover
>
>
> Hey Paulo
>
> From: "Paulo Gaspar" <pa...@krankikom.de>
> > I am using bits of pnuts embedded in XML in a similar way.
> > Since pnuts gets compiled in memory, it is damn fast too.
>
> Agreed. Actually many BSF related scripting languages do too.
>
>
> > I had, however, to fix a couple of classloader issues in
> > pnuts to use it in a servlet.
>
> Thanks for the link to pnuts, I'd not heard of it before - it looks pretty
> cool!
>
> It looks like pnuts implements the BSF API so that pnuts should
> work fine in
> Jelly (once I've BSF'd Jelly). I should have pnuts available as one of the
> defaults so that stuff like...
>
> <pnuts:if test="foo.isBar()">
> <pnuts:expr value="foo.getSomething("123")"/>
> </pnuts:if>
>
> <pnuts:script>
> a bunch of pnuts code ....
> </pnuts:script>
>
> could be used to work with pnuts inside Jelly. I'll let you know when
> there's some Jelly'd pnuts in CVS.
>
> James
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [workflow] Jelly <-> Workflow maybe some crossover
Posted by James Strachan <ja...@yahoo.co.uk>.
Hey Paulo
From: "Paulo Gaspar" <pa...@krankikom.de>
> I am using bits of pnuts embedded in XML in a similar way.
> Since pnuts gets compiled in memory, it is damn fast too.
Agreed. Actually many BSF related scripting languages do too.
> I had, however, to fix a couple of classloader issues in
> pnuts to use it in a servlet.
Thanks for the link to pnuts, I'd not heard of it before - it looks pretty
cool!
It looks like pnuts implements the BSF API so that pnuts should work fine in
Jelly (once I've BSF'd Jelly). I should have pnuts available as one of the
defaults so that stuff like...
<pnuts:if test="foo.isBar()">
<pnuts:expr value="foo.getSomething("123")"/>
</pnuts:if>
<pnuts:script>
a bunch of pnuts code ....
</pnuts:script>
could be used to work with pnuts inside Jelly. I'll let you know when
there's some Jelly'd pnuts in CVS.
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [workflow] Jelly <-> Workflow maybe some crossover
Posted by Paulo Gaspar <pa...@krankikom.de>.
I am using bits of pnuts embedded in XML in a similar way.
Since pnuts gets compiled in memory, it is damn fast too.
I had, however, to fix a couple of classloader issues in
pnuts to use it in a servlet.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: James Strachan [mailto:james_strachan@yahoo.co.uk]
> Sent: Wednesday, March 06, 2002 4:25 PM
> To: Jakarta Commons Developers
> Subject: [workflow] Jelly <-> Workflow maybe some crossover
>
>
> I've been experimenting with (yet another) scripting language
> called Jelly.
> Its kinda like JSP custom tags without the JSP, borrowing ideas from
> Velocity and XDoclet and its really simple & lightweight & embeddable. I
> plan on integrating BSF so that JavaScript et al could be embedded inside
> tags with maybe Velocity as an expression language. Jelly could implement
> the JSTL tags too if need be. There's some documentation in CVS
> if folks are
> interested learning more.
>
> The idea behind Jelly was that XML allows extensible tags (e.g.
> JSTL, Struts
> etc) so I wanted a simple way to be able to script complex stuff
> like making
> a SOAP call, doing XSLT, JMS messaging, HTTP malarkey along with working
> with Java beans all in a simple XML language. Though I didn't want to base
> it on JSP so it could be used anywhere (from Ant or whatever).
> One objective
> a bit further down the line was to make a simple SOAP scripting
> engine that
> based on a WSDL file or some jelly script to make a new tag to do useful
> stuff. e.g.
>
> <babelfish:translate from="en" to="fr">
> using simple XML scripting with SOAP under the covers
> </babelfish:translate>
>
> Well I started looking again at Workflow today and it got me
> thinking - both
> efforts are kinda similar though from completely different
> perspectives. All
> the Steps are quite close, programatically to the Tags I'd
> started writing.
> The major difference is the 'run' methods are execute(Context) and
> run(Context, Writer) respectively. So Jelly allows scripts to output stuff
> which Workflow does not right now, other than that, spookily similar. Also
> both Jelly and Workflow have a Context which is similar to an
> abstraction of
> JSP scopes and Activity & Block are similar to the Script stuff in Jelly.
>
> Quite what all this means I'm not sure :-) but what could be really useful
> is if we could have a single API for writing 'Steps' or 'Tags' then both
> projects could share them.
>
> e.g. I'm gonna write a bunch of 'tags' for doing HTTP (using httpclient),
> JMS (using messenger), SOAP (probably using Axis), XSLT as well as the
> existing XPath ones and JSTL-like core tags using a pluggable expression
> languages (which right now is beanshell but will be BSF soon).
> Ultimately I
> was gonna try plugin XDoclet tags too then we could mix and match
> scripting
> languages, JSTL, various other tags and XDoclet all from one 'declarative
> XML based script'.
>
> It'd be nice to be able to share all this stuff across both Workflow and
> Jelly. Maybe Jelly scripts could be part (or all) of an activity
> in Workflow
> too but thats maybe more complex.
>
> Thoughts?
>
> James
>
>
>
> --
> 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>