on 6/6/01 10:40 PM, "Diethelm Guallar, Gonzalo" <[EMAIL PROTECTED]>
wrote:
> And, finally, he presented something that could be taken as a
> disadvantage of the templating model: he said JSP is a specification,
> not an implementation, and mentioned that with JSP you have the chance
> to change from one implementation to another if you find the
> particular implementation you are using does not meet your performance
> needs (he even gave Jasper as an example of a less than optimal
> implementation, in terms of performance). With templating languages
> (and he specifically mentioned Velocity as an example), if you find
> your performance needs are not satisfied, you are pretty much screwed,
> since there is no other alternative.
That is FUD that Craig is spreading. :-)
Velocity does indeed have a specification. It is documented on the website
quite clearly as the documentation for Velocity. Anyone is welcome to come
along and implement their own implementation of Velocity that follows the
documentation and language syntax.
Here are the most relevant links:
Appropriately titled:
<http://jakarta.apache.org/velocity/specification.html>
Documentation:
<http://jakarta.apache.org/velocity/vtl-reference-guide.html>
<http://jakarta.apache.org/velocity/user-guide.html>
<http://jakarta.apache.org/velocity/developer-guide.html>
Just because it isn't a Sun defined specification does not mean in any way
that what is on our website isn't a specification.
Let me place a counter argument to what Craig has stated though. Part of the
downfall to having multiple implementations of the JSP specification is that
each one has its own problems and bugs and issues. It is made into a further
mess through the fact that there is no compatibility test suite that vendors
must follow in order to say that they are compatible with the specification.
To add even more mess to the situation, the specification is unclear in
several points and is up for interpretation by each implementation.
Therefore, one company may implement something one way and another a
completely different way and still remain within the specification.
I have documented a response to this Specification FUD here:
<http://jakarta.apache.org/velocity/ymtd/ymtd-implementation.html>
As far as the FUD about implementations, part of the beauty of Velocity is
that it is Open Source...and unlike JSP, the specification for Velocity is
also Open Source. This gives the distinct advantage of the fact that you
have the ability to define how things work in the product without having to
join some JCP organization...just join a mailing list and start posting.
Let me also bring up the issue of cross implementation binary compatibility.
Say you want to create a product based on top of JSP and you do not want to
give out the original templates, only the compiled code. Right now, it is
impossible for you to give out the class files and expect them to work
across different containers because each implementation of JSP does things
differently. Now, I do need to disclose that Velocity does not have the
ability to compile templates (yet), but in the future, it will and the
compiled code will work across containers because there is currently only
one implementation of Velocity. Even if there is multiple implementations of
Velocity, your compiled templates can still work across containers because
Velocity is not tied to the container like JSP implementations are.
> Question: do we have any numbers comparing the performance of a JSP
> page vs a Velocity page? This is a very broad question, but Craig's
> argument could be completely irrelevant if, on the average, Velocity
> pages are an order of magnitude faster than JSPs... Does anybody have
> such numbers handy?
Unfortunately. No. However, I have prepared a testing suite that makes it
fairly easy to do this. Modification of it to test against JSP instead of
Webmacro should be fairly easy to do. Contributions to make this happen are
appreciated.
<http://jakarta.apache.org/builds/jakarta-velocity/speed/>
Regarding the rest of your performance concerns...I'm sure that Velocity
itself can saturate a pipe as it stands. I have yet to hear a single
performance complaint. However, we can always work to improve the
performance even further. This will be done through the use of templates
compiled directly to .class files. At that point, Velocity will at least
equal, if not exceed the speed of JSP. Let me also point out that in order
to increase the speed of Velocity, it will not require a complete rewrite of
the core code. In order to increase the speed of Jasper, a complete rewrite
is necessary because the code is so overly complex that no one can easily
modify it without breaking it. In fact, Costin (a Sun employee) recently
checked in the start of his proposal for a new Jasper code base.
As I have already hinted, Velocity is going to be proposed as a JSR as a
"Java Template Language". There is absolutely no mention of it as a
competitor to JSP, Java is lacking a "Java Template Language". Period. I
have written up the proposal and will be submitting it in the next few days.
If Velocity is accepted as a JSR, then all of Craig's FUD will become moot.
If Velocity is not accepted as a JSR, then I can point at the broken JCP
process and say that Sun plays favorites.
Lastly, for the each negative that someone fabricates about Velocity, I can
point out at least 10 negatives that JSP has. Why would anyone in their
right mind use a technology with so many fundamentally broken aspects to it?
You make the decision. �
-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>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
