* [EMAIL PROTECTED]
|
| Parsing JSP syntax ( org.apache.jasper34.parser ) will behave as a SAX
| parser, and generate SAX events to generator ( almost identical with what
| XML syntax will generate - the big difference is that we'll generate the
| static content as CDATA, instead of parsing it as XML ).
What do you mean by that last sentence? SAX doesn't represent CDATA
marked sections directly, so I'm not sure how to interpret this.
| Tree representation is still one big issue - I don't know what's the
| best for that, so I'll keep the current model ( tree of Generators )
| until I ( or someone else ) have a better idea. ( well, I have some
| idea, but I'm not ready to fight for it)
This sounds very strange to me. Surely the best approach is to create
an object model that represents the data, and leave actions
(generation etc) out of the tree representation? That is, something
like an abstract syntax tree. Surely keeping the generators is
incompatible with using a visitor approach?
I don't mean to restart old debates here, but I would like to know
what the reasoning behind this is. To me it seems that having a tree
of generators is the opposite of modular, since it means that the JSP
page tree is entirely opaque.
* Lars Marius Garshol
|
| So the MAIN branch in
| jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/ is where
| Jasper development is done right now?
* [EMAIL PROTECTED]
|
| That's where most of the optimizations and refactoring is done. In
| jakarta-tomcat we have only major bug fixes right now.
In that case there is a bug on line 186 of ServletWriter.java:
this.println("response.setContentType(\"" +
pageInfo.servletContentType +
";charset=8859_1\");");
8859_1 is not one of the IANA-registered names for ISO 8859-1 so it
can't be used in HTTP headers. It should be replaced by 'iso-8859-1',
which is the preferred name.
| What is in jakarta-tomcat/src/share/org/apache/jasper goes into
| tomcat3.3, and it is what we consider 'stable' ( and frozen ).
|
| What is in jakarat-tomcat-jasper/jasper34 is a development version,
| with quite a few improvements and some bug fixes that couldn't go
| into the 'stable' branch ( because we didn't want to destabilize it
| ).
Thanks! This was very helpful.
| About 'interface-compatible' - I don't think so, first of all there
| is no 'interface' in 3.3, and the main goal is to actually
| reorganize the code so it could be 'interfaced'. jasper34.core will
| contain a set of base classes that could be used to extend and plug
| the generator into different containers.
You wrote that 3.4 could be used to upgrade the Jasper in 3.3. What
did you mean by that, then? I interpreted you to mean that you could
take Jasper 3.4 and drop it into Tomcat 3.3 and have that work, but
apparently that was wrong.
| [...]
| End of september ( and anything after 3.3 is out ) will be much
| better, but Oct 1 is far too tight.
Again, thanks very much for this overview. It was most useful.
| So it shouldn't matter - you could play it safe, and hack 3.3 (
| knowing the code will not get into the main branch ! ) for your
| needs, and port the changes to jasper34. There are other
| optimizations going on in 3.4 that might help you as well.
This seems to me like it will be the most likely route for us. It
would be best if we could avoid it, but if your release deadlines do
not match ours (and they don't seem to), then it may be necessary.
I'll do my best to make sure any changes I may make will be easy to
integrate into future versions, though.
--Lars M.
