Hi Paulo
----- Original Message -----
From: "Paulo Gaspar" <[EMAIL PROTECTED]>
> Hi James,
> answer inline:
>
> > -----Original Message-----
> > From: James Strachan [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, March 07, 2002 9:41 PM
> >
> > ----- Original Message -----
> > From: "Paulo Gaspar" <[EMAIL PROTECTED]>
> > > 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
