Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
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.
Yes. We have to distinguish this in the instruction names. A <jx:macros href="blah"/> could be used for macro imports, whereas <jx:include> would be for dynamic XML import.
- 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?
Rhino has been reported to be fairly speedy, and also has a compilation mode that produces classes (i.e. bytecodes) on the fly.
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.
I see your point. But a Rhino expression can only modify its context, which can be made read-only (see what I've done in flowscript to forbid automatic declaration of toplevel variables). Furthermore, this notion of "read-only" can't really be enforced when the expression language allows method calls.
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
