on 5/16/01 1:11 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> The code generation stage is not significant - compared with the javac
> compilation. Some people are even using XSLT at runtime ( not that this is
> a good idea ) - so I doubt it'll have such a significant impact on
> development mode ( if it's ok for a runtime page, it should be ok for a
> developer ).
>
> In addition, for "pure" jsp ( if no java fragment is used ) it would be
> possible to use the same technique as XSLTC ( now part of xalan ) - and
> generate the bytecode directly ( since most of the generated code is
> "glue" ) - and avoid the javac.
>
> Of course, the big goal is to allow some taglib optimzations ( create
> alternate implementations for common-used tags, with same behavior but
> generating code directly ) - and that's why XSLT is need.
>
> The good news about JSP is that it is a specification. People can use
> a different implementation if they are not happy with one, or use one for
> development and one for deployment.
>
> ( I have a feeling Cocoon2 and Resin are both using XSLT in developing the
> pages - so I guess we will be safe, both are doing OK )
>
> Costin
Costin,
Once again, you impress me with your inability to understand a word of what
I'm talking about. So, let me close this discussion with this:
If the speed of generating a .java file (or directly to a .class file) from
JSP ends up taking more resources (ie: memory) and more time after the
conversion to using XSLT as the transformation step, I will forward your
comments above to you again and tell you "I told you so." I welcome the same
response from you.
As for your comments about Cocoon2, well, if you actually look at it, it is
dog slow and *extremely* resource intensive. The only reason why there is
*any* performance out of it is because there is a shit load of caching and
compiled XSLT that goes on. This is something that I fear the development of
JSP pages will not be able to take advantage of in the same way and as a
result, development performance will suffer compared with what it is at
today.
I find it funny that I seem to be the only one who cares about this issue.
:-)
p.s. Over in Turbine land, we have a lot of experience with the dynamic
generation of Java code and have found that using Texen has been a most
favorable experience. It would be most humorous to me to see Velocity used
to generate .java files from .jsp input. :-)
<http://jakarta.apache.org/velocity/texen.html>
-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>
