Leszek Gawron wrote:
but you make the invoker look up element's name in macro map for EVERY template element started. Costly as hell. JX instructions are resolved the same way but during parsing. We cannot do the same for macros because we do not know the full macros list at parsing time.
What stops you from two-pass compiling? On first pass process all macros / instructions / etc, on second pass link'em up. This assumes that "runtime imports" are evicted.
This sucks!
Besides that does a lot of function calls through Jexl, that requires reflection an might be costly.
Generally a large part of the work is done at compile time, so it should at least in principle be efficient.
If we are to speed up things we need to drop the fine feature of automatic change detection in imported templates. Then:
1. Imports could be resolved at parse time/runtime depending on an attribute given. runtime imports generate content.
Is there a reason why imports should be resolved at runtime at all? Is there a need for two different import mechanisms? I'd suggest killing 'em.
4. Execution context is built up on template parsing. It contains a full list of expected macros.
5. <ft:widget id="something"> being a macro is being resolved at parse time, not runtime. A start element event is just a start element during runtime - never macro invocation.
With the above, it should be easy.
Now I know why XSLT guys made xsl:import the way it is.
Sooner or later we should start write a CTemplateGenerator where we remove stuff that we don't want from JXTG. It will share nearly all code with JXTG the main difference is that it has a different instruction configuration file. I don't know if it is time for it yet.
Considering the automatic change detection, the situation isn't as bad as you think.
IIRC, Sylvain implemented a clever caching mechanism for the TraxTransformer so that it detects changes in xsl:includes. I don't rememember the details but maybe Sylvain can give some pointers.
IIRC, this feature was implemented in 2.0.3, almost 3 years ago. Look for usages of "protected List includes" [1]. It has been improved since then, with current version in excalibur [2].
[OT] I wonder why it uses Map now for m_includesMap ...
Vadim
[1] http://cvs.apache.org/viewcvs.cgi/cocoon-2-historical/src/java/org/apache/cocoon/components/xslt/XSLTProcessorImpl.java?hideattic=0&rev=1.18.2.1&view=markup
[2] http://svn.apache.org/viewcvs.cgi/excalibur/trunk/components/xmlutil/src/java/org/apache/excalibur/xml/xslt/XSLTProcessorImpl.java?rev=22712&view=markup
