You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Brad Cox <bc...@virtualschool.edu> on 2002/01/27 16:39:20 UTC
DVSL Question
Geir, the DVSL guide explains how to use dvsl in standalone mode
but not how to use it from java code as a Velocity enhancement.
Here's my starting code, which uses xsl to build the input
stream for velocity. Works fine except that I want to eliminate
the need to maintain part of the chain in xslt and do it all in
dvsl:
String velPath = "xml/file.xml";
String xslPath = "xsl/file.xsl";
VelocityContext context = new VelocityContext();
context.put("stuff", stuff);
StringWriter sw = new StringWriter();
TransformerFactory tFactory = TransformerFactory.newInstance();
Transformer transformer =
tFactory.newTransformer(new StreamSource(xslPath));
transformer.setParameter("page", (index+1)+"");
transformer.transform(
new StreamSource(velPath),
new StreamResult(sw)
);
Velocity.evaluate(context, ctx.getWriter(), "vc", sw.toString());
I want to convert to something like this, which assumes that the
velocity that comes with dvsl is automatically capable of
processing dvsl commands.
String velPath = "xml/file.xml";
String dvslPath = "dvsl/file. dvsl";
VelocityContext context = new VelocityContext();
context.put("stuff", stuff);
Template template = Velocity.getTemplate(velPath);
template.merge( context, ctx.getWriter());
But I don't see how to get the dvslPath into play. Can you help
with how to do this, and whether this change would be advisable
in a mainstream servlet application (re: performance, etc),
since this has to run each time a page is served by the web
server.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by Christoph Reck <Ch...@dlr.de>.
I solved the sealing violation in catalina some months ago by removing
the xerces jar from WEB-INF/lib, copied the jaxp compatible crimson.jar
from tomcat/server into tomcat/lib directory, and configured the JDOM
to use the crimson saxbuilder:
SAXBuilder builder = new SAXBuilder("org.apache.crimson.parser.XMLReaderImpl");
Document doc = builder.build(in);
I'm sure there are other solutions, but this seemed quite straightforward
(did not require unsealing any jars). It just makes the crimson/JAXP
library available to all webapps. Note that with xerces 1.4.? there
was an incompatibility coexisting with crimson, I believe having read
somewhere that this has been solved.
Brad Cox wrote:
>
> On Tuesday, January 29, 2002, at 05:14 AM, Geir Magnusson Jr. wrote:
>
> > On 1/28/02 9:54 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
> >> Another problem: this release put me back into sealing violation
> >> hell.
> >
> > I wonder how... Nothing changed other than literally 6 lines
> > of code. No
> > new jars were added...
> >
> > The last update to /lib was updating dom4j to 1.1.1 and junit.
> >
> > Are you sure nothing else changed?
>
> The cause was copying in your jars, replacing my unsealed
> versions with your sealed ones.
>
> >> After a long struggle, I dug my way out by unsealing
> >> every jar in sight. Would you mind fixing this at the source or
> >> at least add a mention in the FAQ? This is a particularly nasty
> >> problem because you get no information whatsoever, just "sealing
> >> violation" without a clue as to where. Cost me days to figure
> >> this out.
> >
> > I still don't know what the problem is. I assume this is in a web
> > container? Which one? What jars are in your WEB-INF/lib?
>
> I'm using jetty, but the problem has been reported with all
> containers that use xml for configuration including Tomcat and
> Resin. Search for "sealing violation" in google. The workaround
> is to unseal all jars, crimson in particular. Its yet another
> classloader conflict but nobody knew the right solution then.
> Craig said he'd look.
>[snip]
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by Brad Cox <bc...@virtualschool.edu>.
On Tuesday, January 29, 2002, at 09:14 AM, Geir Magnusson Jr. wrote:
> Which jars?
>
> The only one that required a change was the dvsl jar...
I copied all of yours.
>> I'm using jetty, but the problem has been reported with all
>> containers that use xml for configuration including Tomcat and
>> Resin. Search for "sealing violation" in google. The workaround
>> is to unseal all jars, crimson in particular. Its yet another
>> classloader conflict but nobody knew the right solution then.
>> Craig said he'd look.
>
> Huh? I thought craig solved this a while ago...
I'm using Jetty, not Tomcat.
>> Here's WEB-INF/lib jcms.jar, jwaa.jar, jwaaDemo.jar, and
>> mybank.jar are my stuff. Everything else has been manually
>> unsealed. Sorry, the velocity.log with the stack traces have
>> been overwritten by now. From memory, the sealing violation
>> happens when dvsl tries to access my DOM, not when I'm building
>> it.
>
> Right - I thought that is because you have something that
> Tomcat also has in
> your webapp. Right? That's why I thought this happened -
> because you are
> going outside of your webapp classloader for something...
Exactly except that its dvsl that's going out of the classloader
while calling dom4j which jetty doesn't use. The velocity.jar
has been overwritten by now but this was quite clear in the
stacktrace.
> The problem should be different for servlet spec 2.2 vs spec 2.3, if I
> understand the problem, as the classloader delegation is different.
Sorry, I don't understand. I think Jetty uses the latest spec
but haven't checked.
> So you have crimson and jaxp. Can you eliminate them and just
> use what's in
> tomcats system classloader?
I use Jetty not Tomcat, from http://jetty.mortbay.com. Here's
its lib directory; e.g. my app needs these to launch.
-rw-r--r-- 1 bcox wheel 74049 Dec 31 00:07
javax.servlet.jar
-rw-r--r-- 1 bcox wheel 28327 Jan 19 11:36
javax.xml.jaxp.jar
-rw-r--r-- 1 bcox wheel 186887 Jan 19 11:38
org.apache.crimson.jar
-rw-r--r-- 1 bcox wheel 432163 Dec 31 00:07
org.mortbay.jetty.jar
Not that dom4j isn't here. Based on the stack trace it was clear
that dom4j references something that's being resolved in some
other jar, probably crimson. Unsealing everything works for me
so I've not dug deeper. But everything that distributes xml
libraries will definitely need to address this, if only by
describing my "unseal everything" workaround in the faq, or
better, by settling on a compatible xml/xslt combination.
>>>> Also something seems to have changed re: properties handling.
>>>> Had to edit all paths to make them absolute (e.g.
>>>> /jcms/vel/vel.dvsl) to get on the air.
>>>
>>> What did you change? The changes to dvsl last night were so
>>> minimal, it
>>> really was just 6 lines of code...
>>
>> This is apparently due to using DVSL instead of Velocity. My
>> servlet init
>> calls Velocity.init(propertiesPath) both then and now, just in
>> case because I don't undeerstand the relationship between
>> velocity and dvsl. DVSL doesn't provide such an init. Apparently
>> velocity.init doesn't "take" when I'm using DVSL, or something.
>>
>
> DVSL uses the non-singleton VelocityEngine to avoid banging
> against anyone
> using the Singleton pattern (the original way). The VelocityServlet is
> singleton based for Velocity engine use, so unless something is
> horribly
> broken, the DVSL velocity use should be completely separate
> from that of
> your servlet.
>
> Now, this may not be what you want - you may want to have one shared
> Velocity engine across your app (the servlet) and the DVSL
> transformer...
>
> It would be easy to do in theory and in practice. However,
> there may be
> other approaches we might want to explore, such as more control over
> configuration in DVSL...
I'm too new at both dvsl and velocity to claim what I want. Was
just reporting the ambiguity.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/29/02 8:53 AM, "Brad Cox" <bc...@virtualschool.edu> wrote:
> On Tuesday, January 29, 2002, at 05:14 AM, Geir Magnusson Jr. wrote:
>
>> On 1/28/02 9:54 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
>>> Another problem: this release put me back into sealing violation
>>> hell.
>>
>> I wonder how... Nothing changed other than literally 6 lines
>> of code. No
>> new jars were added...
>>
>> The last update to /lib was updating dom4j to 1.1.1 and junit.
>>
>> Are you sure nothing else changed?
>
> The cause was copying in your jars, replacing my unsealed
> versions with your sealed ones.
Which jars?
The only one that required a change was the dvsl jar...
>
>>> After a long struggle, I dug my way out by unsealing
>>> every jar in sight. Would you mind fixing this at the source or
>>> at least add a mention in the FAQ? This is a particularly nasty
>>> problem because you get no information whatsoever, just "sealing
>>> violation" without a clue as to where. Cost me days to figure
>>> this out.
>>
>> I still don't know what the problem is. I assume this is in a web
>> container? Which one? What jars are in your WEB-INF/lib?
>
> I'm using jetty, but the problem has been reported with all
> containers that use xml for configuration including Tomcat and
> Resin. Search for "sealing violation" in google. The workaround
> is to unseal all jars, crimson in particular. Its yet another
> classloader conflict but nobody knew the right solution then.
> Craig said he'd look.
Huh? I thought craig solved this a while ago...
> Here's WEB-INF/lib jcms.jar, jwaa.jar, jwaaDemo.jar, and
> mybank.jar are my stuff. Everything else has been manually
> unsealed. Sorry, the velocity.log with the stack traces have
> been overwritten by now. From memory, the sealing violation
> happens when dvsl tries to access my DOM, not when I'm building
> it.
Right - I thought that is because you have something that Tomcat also has in
your webapp. Right? That's why I thought this happened - because you are
going outside of your webapp classloader for something...
The problem should be different for servlet spec 2.2 vs spec 2.3, if I
understand the problem, as the classloader delegation is different.
Note that I am no expert on this - I thought I had a good mental model of
the problem, but I may be wrong...
> -rw-r--r-- 1 bcox wheel 45386 Jan 26 15:41 activation.jar
> -rwxr-xr-x 1 bcox wheel 186887 Jan 28 21:10 crimson.jar
> -rw-r--r-- 1 bcox wheel 23153 Jan 26 15:41 gnu-
> regexp-1.0.8.jar
> -rwxr-xr-x 1 bcox wheel 28327 Jan 28 21:11 jaxp.jar
> -rw-r--r-- 1 bcox wheel 319244 Jan 28 21:43 jcms.jar
> -rw-r--r-- 1 bcox wheel 431949 Jan 28 21:20 jetty.jar
> -rw-r--r-- 1 bcox wheel 74049 Jan 26 15:41
> jetty.servlet.jar
> -rwxr-xr-x 1 bcox wheel 117522 Jan 28 20:53 junit-3.7.jar
> -rw-r--r-- 1 bcox wheel 84164 Jan 26 15:41 jwaa.jar
> -rw-r--r-- 1 bcox wheel 41325 Jan 26 15:41 jwaaDemo.jar
> -rw-r--r-- 1 bcox wheel 280984 Jan 26 15:41 mail.jar
> -rw-r--r-- 1 bcox wheel 112241 Jan 26 15:41
> mm.mysql-2.0.8-bin.jar
> -rw-r--r-- 1 bcox wheel 699881 Jan 26 15:41 mybank.jar
> -rw-r--r-- 1 bcox wheel 505034 Jan 28 20:53 velocity-
> dep-1.3-dev.jar
> -rw-r--r-- 1 bcox wheel 19117 Jan 28 21:14 velocity-
> dvsl-0.32.jar
> -rw-r--r-- 1 bcox wheel 4618 Jan 28 21:26 velocity.log
> -rw-r--r-- 1 bcox wheel 801597 Jan 28 21:16 xalan.jar
> drwxr-xr-x 2 bcox wheel 1024 Jan 28 21:25 z
So you have crimson and jaxp. Can you eliminate them and just use what's in
tomcats system classloader?
>>> Also something seems to have changed re: properties handling.
>>> Had to edit all paths to make them absolute (e.g.
>>> /jcms/vel/vel.dvsl) to get on the air.
>>
>> What did you change? The changes to dvsl last night were so
>> minimal, it
>> really was just 6 lines of code...
>
> This is apparently due to using DVSL instead of Velocity. My
> servlet init
> calls Velocity.init(propertiesPath) both then and now, just in
> case because I don't undeerstand the relationship between
> velocity and dvsl. DVSL doesn't provide such an init. Apparently
> velocity.init doesn't "take" when I'm using DVSL, or something.
>
DVSL uses the non-singleton VelocityEngine to avoid banging against anyone
using the Singleton pattern (the original way). The VelocityServlet is
singleton based for Velocity engine use, so unless something is horribly
broken, the DVSL velocity use should be completely separate from that of
your servlet.
Now, this may not be what you want - you may want to have one shared
Velocity engine across your app (the servlet) and the DVSL transformer...
It would be easy to do in theory and in practice. However, there may be
other approaches we might want to explore, such as more control over
configuration in DVSL...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Java : the speed of Smalltalk with the simple elegance of C++...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by Brad Cox <bc...@virtualschool.edu>.
On Tuesday, January 29, 2002, at 05:14 AM, Geir Magnusson Jr. wrote:
> On 1/28/02 9:54 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
>> Another problem: this release put me back into sealing violation
>> hell.
>
> I wonder how... Nothing changed other than literally 6 lines
> of code. No
> new jars were added...
>
> The last update to /lib was updating dom4j to 1.1.1 and junit.
>
> Are you sure nothing else changed?
The cause was copying in your jars, replacing my unsealed
versions with your sealed ones.
>> After a long struggle, I dug my way out by unsealing
>> every jar in sight. Would you mind fixing this at the source or
>> at least add a mention in the FAQ? This is a particularly nasty
>> problem because you get no information whatsoever, just "sealing
>> violation" without a clue as to where. Cost me days to figure
>> this out.
>
> I still don't know what the problem is. I assume this is in a web
> container? Which one? What jars are in your WEB-INF/lib?
I'm using jetty, but the problem has been reported with all
containers that use xml for configuration including Tomcat and
Resin. Search for "sealing violation" in google. The workaround
is to unseal all jars, crimson in particular. Its yet another
classloader conflict but nobody knew the right solution then.
Craig said he'd look.
Here's WEB-INF/lib jcms.jar, jwaa.jar, jwaaDemo.jar, and
mybank.jar are my stuff. Everything else has been manually
unsealed. Sorry, the velocity.log with the stack traces have
been overwritten by now. From memory, the sealing violation
happens when dvsl tries to access my DOM, not when I'm building
it.
-rw-r--r-- 1 bcox wheel 45386 Jan 26 15:41 activation.jar
-rwxr-xr-x 1 bcox wheel 186887 Jan 28 21:10 crimson.jar
-rw-r--r-- 1 bcox wheel 23153 Jan 26 15:41 gnu-
regexp-1.0.8.jar
-rwxr-xr-x 1 bcox wheel 28327 Jan 28 21:11 jaxp.jar
-rw-r--r-- 1 bcox wheel 319244 Jan 28 21:43 jcms.jar
-rw-r--r-- 1 bcox wheel 431949 Jan 28 21:20 jetty.jar
-rw-r--r-- 1 bcox wheel 74049 Jan 26 15:41
jetty.servlet.jar
-rwxr-xr-x 1 bcox wheel 117522 Jan 28 20:53 junit-3.7.jar
-rw-r--r-- 1 bcox wheel 84164 Jan 26 15:41 jwaa.jar
-rw-r--r-- 1 bcox wheel 41325 Jan 26 15:41 jwaaDemo.jar
-rw-r--r-- 1 bcox wheel 280984 Jan 26 15:41 mail.jar
-rw-r--r-- 1 bcox wheel 112241 Jan 26 15:41
mm.mysql-2.0.8-bin.jar
-rw-r--r-- 1 bcox wheel 699881 Jan 26 15:41 mybank.jar
-rw-r--r-- 1 bcox wheel 505034 Jan 28 20:53 velocity-
dep-1.3-dev.jar
-rw-r--r-- 1 bcox wheel 19117 Jan 28 21:14 velocity-
dvsl-0.32.jar
-rw-r--r-- 1 bcox wheel 4618 Jan 28 21:26 velocity.log
-rw-r--r-- 1 bcox wheel 801597 Jan 28 21:16 xalan.jar
drwxr-xr-x 2 bcox wheel 1024 Jan 28 21:25 z
>> Also something seems to have changed re: properties handling.
>> Had to edit all paths to make them absolute (e.g.
>> /jcms/vel/vel.dvsl) to get on the air.
>
> What did you change? The changes to dvsl last night were so
> minimal, it
> really was just 6 lines of code...
This is apparently due to using DVSL instead of Velocity. My
servlet init
calls Velocity.init(propertiesPath) both then and now, just in
case because I don't undeerstand the relationship between
velocity and dvsl. DVSL doesn't provide such an init. Apparently
velocity.init doesn't "take" when I'm using DVSL, or something.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/28/02 9:54 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
> Thanks. ValueOf's working fine with one caveat...its returning
> String, not Integer, so comparisons fail. Working on a
> workaround now.
It's returning whatever the implementation is. I am surprised that is a
string.
You can make a little tool to drop into the context or toolbox...
>
> Another problem: this release put me back into sealing violation
> hell.
I wonder how... Nothing changed other than literally 6 lines of code. No
new jars were added...
The last update to /lib was updating dom4j to 1.1.1 and junit.
Are you sure nothing else changed?
> After a long struggle, I dug my way out by unsealing
> every jar in sight. Would you mind fixing this at the source or
> at least add a mention in the FAQ? This is a particularly nasty
> problem because you get no information whatsoever, just "sealing
> violation" without a clue as to where. Cost me days to figure
> this out.
I still don't know what the problem is. I assume this is in a web
container? Which one? What jars are in your WEB-INF/lib?
>
> Also something seems to have changed re: properties handling.
> Had to edit all paths to make them absolute (e.g.
> /jcms/vel/vel.dvsl) to get on the air.
What did you change? The changes to dvsl last night were so minimal, it
really was just 6 lines of code...
> That said, thanks for the timely fix. I really appreciate it.
We'll solve the rest too... Let us know...
geir
> On Monday, January 28, 2002, at 08:42 PM, Geir Magnusson Jr. wrote:
>
>> On 1/28/02 8:40 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
>>
>>> Thanks. Its downloading now. BTW did you know there's no dvsl
>>> link from the jakarta cvs page? Took a bit of guesswork to get
>>> the right cvs name.
>>>
>>
>> Couldn't have been that hard :)
>>
>> Thanks. I'll fix.
>>
>>> On Monday, January 28, 2002, at 07:35 PM, Geir Magnusson Jr. wrote:
>>>
>>>> Ok. Done. I even tested it <whoa!>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Java : the speed of Smalltalk with the simple elegance of C++...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by Christoph Reck <Ch...@dlr.de>.
Brad Cox wrote:
>
> On Monday, January 28, 2002, at 09:54 PM, Brad Cox wrote:
>
> > Thanks. ValueOf's working fine with one caveat...its returning
> > String, not Integer, so comparisons fail. Working on a
> > workaround now.
>
> Workaround's not as simple as I thought. How to call
> Integer.valueOf($count) in a template file?
#set( $int = 0 )
$int.valueOf($count)
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by Brad Cox <bc...@virtualschool.edu>.
On Monday, January 28, 2002, at 09:54 PM, Brad Cox wrote:
> Thanks. ValueOf's working fine with one caveat...its returning
> String, not Integer, so comparisons fail. Working on a
> workaround now.
Workaround's not as simple as I thought. How to call
Integer.valueOf($count) in a template file?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by Brad Cox <bc...@virtualschool.edu>.
Thanks. ValueOf's working fine with one caveat...its returning
String, not Integer, so comparisons fail. Working on a
workaround now.
Another problem: this release put me back into sealing violation
hell. After a long struggle, I dug my way out by unsealing
every jar in sight. Would you mind fixing this at the source or
at least add a mention in the FAQ? This is a particularly nasty
problem because you get no information whatsoever, just "sealing
violation" without a clue as to where. Cost me days to figure
this out.
Also something seems to have changed re: properties handling.
Had to edit all paths to make them absolute (e.g.
/jcms/vel/vel.dvsl) to get on the air.
That said, thanks for the timely fix. I really appreciate it.
On Monday, January 28, 2002, at 08:42 PM, Geir Magnusson Jr. wrote:
> On 1/28/02 8:40 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
>
>> Thanks. Its downloading now. BTW did you know there's no dvsl
>> link from the jakarta cvs page? Took a bit of guesswork to get
>> the right cvs name.
>>
>
> Couldn't have been that hard :)
>
> Thanks. I'll fix.
>
>> On Monday, January 28, 2002, at 07:35 PM, Geir Magnusson Jr. wrote:
>>
>>> Ok. Done. I even tested it <whoa!>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/28/02 8:40 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
> Thanks. Its downloading now. BTW did you know there's no dvsl
> link from the jakarta cvs page? Took a bit of guesswork to get
> the right cvs name.
>
Couldn't have been that hard :)
Thanks. I'll fix.
> On Monday, January 28, 2002, at 07:35 PM, Geir Magnusson Jr. wrote:
>
>> Ok. Done. I even tested it <whoa!>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by Brad Cox <bc...@virtualschool.edu>.
Thanks. Its downloading now. BTW did you know there's no dvsl
link from the jakarta cvs page? Took a bit of guesswork to get
the right cvs name.
On Monday, January 28, 2002, at 07:35 PM, Geir Magnusson Jr. wrote:
> Ok. Done. I even tested it <whoa!>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/28/02 5:56 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
> On Monday, January 28, 2002, at 05:29 PM, Geir Magnusson Jr. wrote:
>
>> On 1/28/02 5:13 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
>>
>>> I'd already tried that. Doesn't work. Velocity doesn't recognize
>>> it as valid command. Given
>>>
>>> $node.valueOf("count(/task/page)") as input
>>>
>>> it just echoes the command to output.
>>>
>>
>> I wasn't suggesting you try it - I was asking if that was a
>> solution that
>> would work.
>>
>> If so, I would bang it out, and *then* you could try it.
>
> Oh. Sure it would help. But why not implement the rest of the
> Node interface? You've got most of it already.
>
Ok. Done. I even tested it <whoa!>
Just refresh your DVSL tree. Also, the version of the jar is updated to
help track these changes.
I put it in the Node, but I don't really like it there - we might move to
the TransformTool to lighten the requirments for Node implementations....
We'll see how it goes, I guess.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/28/02 8:51 PM, "Bill Burton" <bi...@progress.com> wrote:
> Hello Geir,
>
> "Geir Magnusson Jr." wrote:
>>> Oh. Sure it would help. But why not implement the rest of the
>>> Node interface? You've got most of it already.
>>>
>>
>> Because I didn't want to implement any one specific node interface (dom4j,
>> JDOM, w3c, ..)
>>
>> Just wanted to implement the stuff that is right for us... Less kruft.
>
> Is there some reason for not using the jaxen API which isn't specifc to
> dom4j, JDOM or DOM? It's actually included with dom4j.
>
Like what?
Right now - we don't use Jaxen directly - we are using dom4j. We can
augment the dom4j with Jaxen directly when the release (paging Dr. Bob...)
I want to err on the side of caution at first - only adding what people ask
for, rather than guessing...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by Bill Burton <bi...@progress.com>.
Hello Geir,
"Geir Magnusson Jr." wrote:
> > Oh. Sure it would help. But why not implement the rest of the
> > Node interface? You've got most of it already.
> >
>
> Because I didn't want to implement any one specific node interface (dom4j,
> JDOM, w3c, ..)
>
> Just wanted to implement the stuff that is right for us... Less kruft.
Is there some reason for not using the jaxen API which isn't specifc to
dom4j, JDOM or DOM? It's actually included with dom4j.
-Bill
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/28/02 5:56 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
> On Monday, January 28, 2002, at 05:29 PM, Geir Magnusson Jr. wrote:
>
>> On 1/28/02 5:13 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
>>
>>> I'd already tried that. Doesn't work. Velocity doesn't recognize
>>> it as valid command. Given
>>>
>>> $node.valueOf("count(/task/page)") as input
>>>
>>> it just echoes the command to output.
>>>
>>
>> I wasn't suggesting you try it - I was asking if that was a
>> solution that
>> would work.
>>
>> If so, I would bang it out, and *then* you could try it.
>
> Oh. Sure it would help. But why not implement the rest of the
> Node interface? You've got most of it already.
>
Because I didn't want to implement any one specific node interface (dom4j,
JDOM, w3c, ..)
Just wanted to implement the stuff that is right for us... Less kruft.
Actually, you can dig out the underlying implementation node from the Node
but
1) the valueOf() is good to add generally and
2) digging out is kinda yecchy :)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by Brad Cox <bc...@virtualschool.edu>.
On Monday, January 28, 2002, at 05:29 PM, Geir Magnusson Jr. wrote:
> On 1/28/02 5:13 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
>
>> I'd already tried that. Doesn't work. Velocity doesn't recognize
>> it as valid command. Given
>>
>> $node.valueOf("count(/task/page)") as input
>>
>> it just echoes the command to output.
>>
>
> I wasn't suggesting you try it - I was asking if that was a
> solution that
> would work.
>
> If so, I would bang it out, and *then* you could try it.
Oh. Sure it would help. But why not implement the rest of the
Node interface? You've got most of it already.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/28/02 5:13 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
> I'd already tried that. Doesn't work. Velocity doesn't recognize
> it as valid command. Given
>
> $node.valueOf("count(/task/page)") as input
>
> it just echoes the command to output.
>
I wasn't suggesting you try it - I was asking if that was a solution that
would work.
If so, I would bang it out, and *then* you could try it.
> I REALLY don't understand dvsl. Seems very arbitrary and cranky.
It's brand new and evolving...
>
> On Monday, January 28, 2002, at 04:28 PM, Geir Magnusson Jr. wrote:
>
>> On 1/28/02 12:49 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
>>
>>> Geir, what should I use to compute xsl statements like this in dvsl?
>>>
>>> <xsl:value-of select="count(/task/page)"/>
>>>
>>> Tried $node.get("count(/task/page)") but that wants a Node, not
>>> an Integer.
>>>
>>
>> Heh. Good one.
>>
>> Yes, we need to figure that one out.
>>
>> One solution :
>>
>>
>> $node.valueOf( XPATH )
>>
>>
>> How about that?
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Now what do we do?"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by Brad Cox <bc...@virtualschool.edu>.
I'd already tried that. Doesn't work. Velocity doesn't recognize
it as valid command. Given
$node.valueOf("count(/task/page)") as input
it just echoes the command to output.
I REALLY don't understand dvsl. Seems very arbitrary and cranky.
On Monday, January 28, 2002, at 04:28 PM, Geir Magnusson Jr. wrote:
> On 1/28/02 12:49 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
>
>> Geir, what should I use to compute xsl statements like this in dvsl?
>>
>> <xsl:value-of select="count(/task/page)"/>
>>
>> Tried $node.get("count(/task/page)") but that wants a Node, not
>> an Integer.
>>
>
> Heh. Good one.
>
> Yes, we need to figure that one out.
>
> One solution :
>
>
> $node.valueOf( XPATH )
>
>
> How about that?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/28/02 12:49 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
> Geir, what should I use to compute xsl statements like this in dvsl?
>
> <xsl:value-of select="count(/task/page)"/>
>
> Tried $node.get("count(/task/page)") but that wants a Node, not
> an Integer.
>
Heh. Good one.
Yes, we need to figure that one out.
One solution :
$node.valueOf( XPATH )
How about that?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by Brad Cox <bc...@virtualschool.edu>.
Geir, what should I use to compute xsl statements like this in dvsl?
<xsl:value-of select="count(/task/page)"/>
Tried $node.get("count(/task/page)") but that wants a Node, not
an Integer.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Why DVSL matters.
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/28/02 5:25 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
> On Monday, January 28, 2002, at 09:08 AM, Geir Magnusson Jr. wrote:
>> The intent from the beginning was to support multiple object
>> models like
>> jaxen does, but didn't get around to it for the first cut.
>> Maybe your need
>> will motivate that work.
>
> Perhaps this background will help increase the priority of
> improved support for velocity-based handling of XML documents.
>
> I've got a collection of dynamic web pages, expressed as xml
> files, representing assignments for a course chunked into
> page-sized chunks. The task structure is simply
>
> <task>
> <page>...
> <page>...
> </task>
>
> where ... represents plain ol xhtml. When the student clicks
> next to move to the next page, the servlet needs to extract the
> current page from the xml and pass that through velocity to
> format the page, fill in form values from the database, and
> present next/prev buttons for moving through the task.
>
> Without dvsl, this required a pipeline: xml -> xslt -> serial to
> get xhtml that can be processed with velocity. I'm hoping dvsl
> will let me do the same thing within a single language. This
> isn't only because its more efficient to avoid serializing back
> to text, but because it eliminates the nead to
> learn/teach/maintain a separate language (xslt).
I am thrilled that you find a real use for this.
However, remember that its new, and the first implementation was kept
minimal to look for community feedback for features that are really
important and necessary.
So if there something not there, and it's general enough, we'll get it in
there.
The need for
$node.valueOf( XPATH )
Is certainlyu an example of something needed.
Geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Why DVSL matters.
Posted by Brad Cox <bc...@virtualschool.edu>.
On Monday, January 28, 2002, at 09:08 AM, Geir Magnusson Jr. wrote:
> The intent from the beginning was to support multiple object
> models like
> jaxen does, but didn't get around to it for the first cut.
> Maybe your need
> will motivate that work.
Perhaps this background will help increase the priority of
improved support for velocity-based handling of XML documents.
I've got a collection of dynamic web pages, expressed as xml
files, representing assignments for a course chunked into
page-sized chunks. The task structure is simply
<task>
<page>...
<page>...
</task>
where ... represents plain ol xhtml. When the student clicks
next to move to the next page, the servlet needs to extract the
current page from the xml and pass that through velocity to
format the page, fill in form values from the database, and
present next/prev buttons for moving through the task.
Without dvsl, this required a pipeline: xml -> xslt -> serial to
get xhtml that can be processed with velocity. I'm hoping dvsl
will let me do the same thing within a single language. This
isn't only because its more efficient to avoid serializing back
to text, but because it eliminates the nead to
learn/teach/maintain a separate language (xslt).
That's a concrete example of a very general pattern. A "page"
(above) presents a arbitrary collection of html text, images,
and forms to a user (student). The form boxes are initially
empty, but once filled in, must reappear filled in when the page
is revisited later (from the underlying database).
All this is working now. The final step is to provide some kind
of markup language in the xml files so that the author (teacher)
can write code, for example requiring boxes to be filled in
before advancing to the next page, building dhtml on the fly to
show other student answers (from the database), etc. I've not
started on this step yet.
By the way, this is all a java reimplementation of the
perl-based system at http://virtualschool.edu/98c.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/27/02 9:42 PM, "Brad Cox" <bc...@virtualschool.edu> wrote:
>>
>> /*
>> * make a new DVSL 'engine'
>> */
>> DVSL dvsl = new DVSL();
>>
>> /*
>> * give it a style sheet
>> * and a toolbox (Properties)
>> */
>> dvsl.setStylesheet( style );
>> dvsl.setToolbox( properties );
>
> Which triggers a latent question? What is a "toolbox" for? The
> help file wasn't much help here.
Ah - the toolbox notion is a way that you can define 'tools', java classes
that can be used from within the template... The point is that for things
like ant and commandline, you don't have your own code from which to add
things to the context, so toolbox is a way to do that..
If you look at the vel docs example, there is an HTML encoding tool defined
in the toolbox.props and used in the site.dvsl.
>> You can do the above in an init(), with the caveat that it's
>> not threadsafe.
>> Then, for each request
>>
>> /*
>> * fill your context with stuff and set that
>> */
>>
>> VelocityContext context = new VelocityContext();
>> context.put("foo", "bar");
>> dvsl.setUserContext( context )
>>
>> /*
>> * now transform from the input Reader
>> * to the output Writer
>> */
>> dvsl.transform( in, out );
>
> My current snag is right here. Your stuff uses
> org.dom4j.Document. Everything I have (xalan) builds
> org.w3c.dom.Document. I've decompiled the class files in order
> to figure out how to build it your way, but I'm hoping you can
> shortcut this considerably.
Right - if you really need to use the org.w3c.dom model, then this will take
a little work.
If you just use it because that's what you use, then switching to dom4j
should be trivial.
The intent from the beginning was to support multiple object models like
jaxen does, but didn't get around to it for the first cut. Maybe your need
will motivate that work.
> What is the difference between xalan and dom4j? Which should I
> bet on? I thought xalan was going to be the standard.
Yes, I think that org.w3c.dom is a standard. However, it, like other
standards such as JSP :) appears to be quite lacking, given the number of
alternatives, such as JDOM and dom4j. JDOM is a JSR, so that will be a
'standard' too at some point, and I personally found the Xpath support in
dom4j to be very useful.
I suppose that once Jaxen is released, the Xpath support in dom4j will not
be so critical.
>> There are a few optimizations, and a few problems. An
>> optimization would be
>> to take your XML input documents, parse into dom4j Documents,
>> and pass that
>> to .transform( document, out ) and cache the log4j Documents
>> for reuse on
>> later requests. (simple with a HashMap..)
>>
>> That would make things snappier for the user, as the XML
>> parsing is slow.
>
> Yeah, I've done that.
>
And how fast is it?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by Brad Cox <bc...@virtualschool.edu>.
> I think I understand what you are looking for : that you want
> to use DVSL as
> the rendering engine, invoked from your servlet, rather than
> the canonical
> Velocity "merge template via engine" rendering pattern. Is that it?
yes.
> So, to use DVSL as a rendering engine, I would do something like :
>
> /*
> * make a new DVSL 'engine'
> */
> DVSL dvsl = new DVSL();
>
> /*
> * give it a style sheet
> * and a toolbox (Properties)
> */
> dvsl.setStylesheet( style );
> dvsl.setToolbox( properties );
Which triggers a latent question? What is a "toolbox" for? The
help file wasn't much help here.
> You can do the above in an init(), with the caveat that it's
> not threadsafe.
> Then, for each request
>
> /*
> * fill your context with stuff and set that
> */
>
> VelocityContext context = new VelocityContext();
> context.put("foo", "bar");
> dvsl.setUserContext( context )
>
> /*
> * now transform from the input Reader
> * to the output Writer
> */
> dvsl.transform( in, out );
My current snag is right here. Your stuff uses
org.dom4j.Document. Everything I have (xalan) builds
org.w3c.dom.Document. I've decompiled the class files in order
to figure out how to build it your way, but I'm hoping you can
shortcut this considerably.
What is the difference between xalan and dom4j? Which should I
bet on? I thought xalan was going to be the standard.
> There are a few optimizations, and a few problems. An
> optimization would be
> to take your XML input documents, parse into dom4j Documents,
> and pass that
> to .transform( document, out ) and cache the log4j Documents
> for reuse on
> later requests. (simple with a HashMap..)
>
> That would make things snappier for the user, as the XML
> parsing is slow.
Yeah, I've done that.
Brad Cox, Ph.D.; bcox@virtualschool.edu 703 361 4751
For industrial age goods there were checks and credit cards.
For everything else there is http://virtualschool.edu/mybank
Java Web Application Architecture: http://virtualschool.edu/jwaa
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DVSL Question
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/27/02 10:39 AM, "Brad Cox" <bc...@virtualschool.edu> wrote:
> Geir, the DVSL guide explains how to use dvsl in standalone mode
> but not how to use it from java code as a Velocity enhancement.
>
> Here's my starting code, which uses xsl to build the input
> stream for velocity. Works fine except that I want to eliminate
> the need to maintain part of the chain in xslt and do it all in
> dvsl:
>
> String velPath = "xml/file.xml";
> String xslPath = "xsl/file.xsl";
> VelocityContext context = new VelocityContext();
> context.put("stuff", stuff);
> StringWriter sw = new StringWriter();
> TransformerFactory tFactory = TransformerFactory.newInstance();
> Transformer transformer =
> tFactory.newTransformer(new StreamSource(xslPath));
> transformer.setParameter("page", (index+1)+"");
> transformer.transform(
> new StreamSource(velPath),
> new StreamResult(sw)
> );
> Velocity.evaluate(context, ctx.getWriter(), "vc", sw.toString());
>
> I want to convert to something like this, which assumes that the
> velocity that comes with dvsl is automatically capable of
> processing dvsl commands.
>
> String velPath = "xml/file.xml";
> String dvslPath = "dvsl/file. dvsl";
> VelocityContext context = new VelocityContext();
> context.put("stuff", stuff);
> Template template = Velocity.getTemplate(velPath);
> template.merge( context, ctx.getWriter());
>
> But I don't see how to get the dvslPath into play. Can you help
> with how to do this, and whether this change would be advisable
> in a mainstream servlet application (re: performance, etc),
> since this has to run each time a page is served by the web
> server.
>
>
I think I understand what you are looking for : that you want to use DVSL as
the rendering engine, invoked from your servlet, rather than the canonical
Velocity "merge template via engine" rendering pattern. Is that it?
The DVSL core was written to be used from within apps, with support for a
'user context' of values. That the first two instances of use are the
command line and Ant is just that the first was easy to see if things were
working, and the second is the most obvious for general use around here.
So, to use DVSL as a rendering engine, I would do something like :
/*
* make a new DVSL 'engine'
*/
DVSL dvsl = new DVSL();
/*
* give it a style sheet
* and a toolbox (Properties)
*/
dvsl.setStylesheet( style );
dvsl.setToolbox( properties );
You can do the above in an init(), with the caveat that it's not threadsafe.
Then, for each request
/*
* fill your context with stuff and set that
*/
VelocityContext context = new VelocityContext();
context.put("foo", "bar");
dvsl.setUserContext( context )
/*
* now transform from the input Reader
* to the output Writer
*/
dvsl.transform( in, out );
That's about it.
There are a few optimizations, and a few problems. An optimization would be
to take your XML input documents, parse into dom4j Documents, and pass that
to .transform( document, out ) and cache the log4j Documents for reuse on
later requests. (simple with a HashMap..)
That would make things snappier for the user, as the XML parsing is slow.
Also, IIRC, DVSL isn't threadsafe, so you might want to pool a bunch of
DVSL's and use them, like we pool the VelocityWriters in the
VelocityServlet.
Making it threadsafe is an interesting thing - I'll certainly look into it -
it would make life a bit easier all around for this kind of thing in a
servlet....
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>