cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: Woody template transformer using jx macros
Date Mon, 05 Jan 2004 17:51:40 GMT
Sylvain Wallez wrote:

> Vadim Gritsenko wrote:
>
>
<snip>

>> which actually worked for me, with JXTemplateGenerator. I'm now 
>> puzzled: how yours expression works?
>
>
>
> It doesn't work ;-)
> I wrote it by mimicing what's in Christopher's code without actually 
> testing it.
>
> Reading in more detail the JX implementation of <wt:form-template> and 
> <wt:repeater>, I found that the variable containing the current widget 
> is not "widget" but "ignored"!!
>
> Christopher, can you confirm this? I would be good to have the 
> "widget" or "currentWidget" variable available to crawl the widget 
> tree from any point in the template.
>
In that implementation I used an explicit stack to maintain the current 
widget. So you would have to use ${woodyStack.peek()} to access it.

This is a general issue with JXTemplate's: what should the rules about 
variable scoping be? Currently, any variables you set within a macro are 
visible within the body when it is evaluated (and hide variables with 
the same names defined by enclosing tag). I've attached an alternative 
implementation that uses the execution stack rather than an explicit 
stack. In this implementation the current widget is available as a 
variable ${woodyCurrent}. However this behavior is too permissive and 
can easily lead to accidental name clashes.

I need to think more about this but it should at least be possible to 
create variables that are private to the macro.

As regards performance, WoodyTemplateTransformer is faster. I did some 
informal testing using cocoon.processPipelineTo() without the xslt 
transformation steps using the following script:
   
    var count = 2000;
    var start = new Date();
    for (var i = 0; i < count; i++) {
      var strm = new java.io.ByteArrayOutputStream();
      cocoon.processPipelineTo(uri, bizData, strm);
    }
    var end = new Date();
    print("Elapsed = " + ((end - start)/1000));
    print("Per instance = " + (((end - start)/1000)/count));

For "form1_template.xml" I got the following results:

<generate type=jx src="..."/>  
<serialize/>

    Elapsed = 26.788
    Per instance = 0.013394

<generate src="...">
<transform type="woody">
<serialize/>
   
    Elapsed = 24.225
    Per instance = 0.0121125

For "form_model_gui_template.xml":

<generate type=jx src="..."/>  
<serialize/>
   
    Elapsed = 19.408
    Per instance = 0.09704
   
<generate src="...">
<transform type="woody">
<serialize/>
   
    Elapsed = 8.632
    Per instance = 0.04316
   

I'm not sure yet why the difference is more pronounced in the latter case.

Of course the performance of the whole pipeline is dominated by xslt 
processing. When I included the remainder of the pipeline I got the 
following results for "form1_template.xml":

<generate type=jx src="..."/>  
<...
    Elapsed = 174.19
    Per instance = 0.087095

<generate src="...">
<transform type="woody">
<...
    Elapsed = 163.234
    Per instance = 0.08161700000000001


Regards,

Chris

Mime
View raw message