Sylvain Wallez wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
<snip/>
-o0 Imports 0o-
Imports are used mainly for separating macro definitions from template itself. Issues:
1. Template URI is resolved at runtime. We could skip this although this does not bring much overhead.
2. Parsed template is looked up for every run. This way we are aware of the fact that imported parts are invalidated and should be reparsed. If we store the reference to the template instead of looking it up we've got xsl:import case: you would have to touch main template in order to have imported template changes reparsed.
We have an important performance penality here because the import URI isn't static and therefore can only be resolved a runtime and can potentially point to a different template at each run.
Two solutions to overcome this:
- remove evaluation of the import uri and consider it as a pure static string. I for one wasn't aware of this feature and find it more FS than really useful. XSLT's href in xsl:include and xsl:import are static and everybody lives happily with this.
Agree that we should get rid of dynamic template import. Dynamic XML import might still be non FS, though. So we should probably differ between template and XML import as Leszek propose.
- distinguish at compile time between static uri that can be resolved right away and therefore can be speedier, and uris needing evaluation that have to pay the performance price of flexibility.
3. Imported file is executed for every template run. That is why you have a lot of whitespace in the output where you import external file.
4. Macro definitions are parsed at parse time but are REGISTERED in execution context during runtime (o.a.c.template.instruction.Define.execute inserts itself into the macro map in execution context). This is strictly connected with 2.: Changes in imported template have to be reflected somehow in execution context. Right now execution context is built from scratch every time.
5. I think that evaluating lot's of jexl/jxpath expressions is awfully costly. I was debugging jxpath with FOM_Request problem and it gave me shivers. There's not much really we can do about it.
What about using Rhino as the bean expression language in replacement of JEXL? That way, expressions would be consistent with what's written in flowscript.
It should be fairly easy to do, there is a pluggable Rhino implementation in JEX: http://svn.apache.org/viewcvs.cgi/jakarta/commons/sandbox/jex/trunk/src/java/org/apache/commons/jex/javascript/. The plugable expressions in template are quite close to JEX, so it shouldn't be that difficult to adapt the JEX implementation for our needs.
But do you think it would affect performance? Furthermore, I agree that using the same EL everywhere would be good for consistence, OTH I would prefer having a read only EL in template instead of having an even more powerfull.
/Daniel
