Re: Speed of jx-macros compared to FormsTransformer

[Leszek Gawron]

Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
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.
When dropping "runtime imports" constraints we have several 
possibilities around.

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.
Runtime imports was an easy way to implement caching and macro 
registration in execution context. I have never used
<jx:import uri="${dynamicUri}"/> and I think noone ever did. +1 to kill it.

I am thinking about having an import that does not produce content - 
it's a little bit strange to have 2-3 pages of whitespace in your 
generated source.

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 

--
Leszek Gawron                                      [EMAIL PROTECTED]
IT Manager                                         MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65