Hi Lars,
> As far as I can tell, the only way to get rid of step #2 is to modify
> Jasper. I've looked at the source code, and I think I see a way to do
> this with the sources on the MAIN branch. (BTW, is that the latest and
> greatest version of Jasper?) The current approach with a tree of
> generators makes this difficult, and the resulting Java code will be
> ugly, but it can be done. When Jasper is rewritten to use visitors
> this can be done much prettier.
We started a major refactoring of jasper in jakarta-tomcat-jasper
directory. I'm working on it - probably next week I'll do another commit
with the first part of the migration to SAX-based, which is the first step
to add JSP1.2 features and cleans up even more.
We had many discussion on this, the visitor pattern is on the TODO list,
as well as improving the modularity. There are some issues we don't agree
on ( i.e. the use of XSLT to generate code, cocoon-style ), so I'll do
this later and in a separate module ( that will not be required for normal
operation ).
Probably in 2-3 weeks things will start to move much faster there, after
3.3 is released I'll have more time, and things start to look pretty
clean.
> - is anyone else working on this already? is there some way to
> achieve this already?
Yes, No.
> - which version of the Jasper sources should I be working on?
> the MAIN branch?
I would sugest jakarta-tomcat-jasper, the MAIN branch is frozen, it's very
unlikely we'll do anything else in 3.3 jasper.
Jasper34 will be a module you can use to 'upgrade' jasper in 3.3.
> - what do people think of my proposed solution? I know it is not
> very nice, but as long as the code has to be generated from within
> the current generators, which are called the way they are, I don't
> see any better alternative.
It seems some other people are working on that, I've got a sugestion to
set all the constant fields when the tag is created ( including parent,
etc) - that implies caching the whole tag set per page.
It makes sense - but it needs few more changes.
> - if I do make this change, what are the chances that it will be
> accepted into the Jasper sources?
For 3.3 - I don't think so.
For j-t-j/jasper34 - certainly.
> [1] I've noticed that the Jasper sources seem to use 1.1 collections,
> instead of the 1.2 collections. Is that on purpose?
For the main branch ( 3.2 and 3.3 ) - yes, it has to be backward
compatible with 1.1.
For j-t-c/jasper34: there is no such requirement for the compiler. I would
like to keep the runtime 1.1 compatible - but if someone doesn't like that it's
fine, we already added support for 'plugable' runtime.
Costin
