> Now, people are suggesting using something like XSLT to transform the .jsp
> XML/XHTML file into a .java file. Because you are introducing the
> XSLT layer
> into things, that will have a negative impact on the transformation
> performance (I'm not certain how much, but I am pretty much
> certain it will
> be more than the current system.). Given that this only happens
> when you are
> in development mode, I think that people developing JSP pages
> might not like
> the performance hit.
I used XSLT in the past as a template mechanism and I think that Jon is
right. XSLT is quite demanding on CPU and memory.
(Yes, I am the TemplateMan: I already used XSLT, Freemarker, WebMacro
and Velocity)
MOREOVER, XSLT always adds a lot of baggage to the equation since the
engines are usually quite big and demand for something more than a basic
XML parser.
And do not forget that, bad practice or not, a lot of people like to
have compile-on-change JSPs even in production. So, what ever weight you
add, it will be there all the time for a lot of people.
And then, XSLT syntax is a pain in the ass, which pays even less when
you are not trying to generate well formed XML. It is just too much
trouble. I have been changing stuff from using XSLT to using Velocity
and it is always a big relief.
I do not believe that the code generation for JSPs will demand a very
feature full template mechanism. OTOH, sometimes I often come across java
products that have their own minimal template mechanism... which means
it probably is not hard.
So, I believe that Jasper needs a minimal template mechanism, and not a
maximal one like XSLT.
IF I was messing with Jasper, I would try to find out exactly what is
the absolute minimum of templating features that Jasper would need to
make the code generation easier. I would try to paths:
1) A very simple XML based template mechanism (with <IF>s, <LOOPS>s,
<VALUE>s and so around/controlling-the-flow of the java templated
text. No namespaces and no other complex XSLT sh*t;
2) A cut down version of the Webmacro/Velocity syntax.
Since an XML parser is already used, 1) would not need much extra weight.
If I would not be happy after playing with the 1) concept, I would go
for a (very) cut down version of Velocity. My wild guess is that such
cut down version could have less than 150 kB, which is much less that
what you would have with a XSLT parser and it would be less memory and
CPU intensive too. (Yes, Velocity as a load of baggage that can be thrown
away for such simple mechanism, like resource management, app tools, part
of the syntax features and so on.)
For prototyping purposes...
for 1) It might be possible to find some XML based mechanism in some
OpenSource project somewhere. I bet that something like that
exists;
for 2) You have Velocity, of course.
Well, it is just a suggestion. At the moment that is not my itch.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 16, 2001 7:19 AM
>
>
> on 5/15/01 8:32 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> >>> +1 for the generator.
> >>
> >> Considerations on the generator:
> >>
> >> This will slow development down even further doing the
> transformation step.
> >
> > What ? Using JDK1.2 instead of JDK1.1 ?
> >
> > I doubt it, but thanks for worrying about this :-)
> >
> > Costin
>
> Sorry, let me quote the emails a bit better so that you can
> understand what
> I am trying to suggest. See above.
>
> Currently Jasper output's Java code from within Java code. This
> is about as
> fast as you are going to get because there is no intermediate
> transformation
> step going on, just conditional output of String data entirely
> within Java.
> While this is very fast, it also means that modifications to
> Jasper are damn
> near impossible without reading the source code in a fair amount of detail
> and doing quite a lot of testing.
>
> Now, people are suggesting using something like XSLT to transform the .jsp
> XML/XHTML file into a .java file. Because you are introducing the
> XSLT layer
> into things, that will have a negative impact on the transformation
> performance (I'm not certain how much, but I am pretty much
> certain it will
> be more than the current system.). Given that this only happens
> when you are
> in development mode, I think that people developing JSP pages
> might not like
> the performance hit.
>
> Just a word of consideration.
>
> -jon
>
> --
> If you come from a Perl or PHP background, JSP is a way to take
> your pain to new levels. --Anonymous
> <http://jakarta.apache.org/velocity/ymtd/ymtd.html>
>
