cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Speed of jx-macros compared to FormsTransformer
Date Wed, 18 May 2005 09:04:31 GMT
Sylvain Wallez wrote:

> 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.

+1

I would prefer requiring that marco import declared the name space of 
the imported macros in some way. I'm not to happy with that you must 
check all imported macro declaration files to see if a tag is a macro or 
not.

>> 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.
>
I know :/

Anyway, a Rhino EL plugin seem like a valuable adition, I will start 
implementing it as soon as we have finished the reals blocks ;) If 
anybody want it sooner Sylvain and I have given some pointers about how 
to get started.

/Daniel


Mime
View raw message