cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: [status/roadmap] JXTG Refactoring
Date Mon, 24 Jan 2005 18:48:27 GMT
Daniel Fagerstrom wrote:
> The remaining problem for removing references to the JXTG instructions 
> from the Parser is that StartDefine have a finish method that is 
> executed when its end tag is reached during compilation. finish() take 
> care of installing the parameters within jx:definition.
> There are two possibilities for making StartDefine being compiled in the 
> same way as the other instructions.
> 1. Let the parameters install them selves in StartDefine as when and 
> otherwise do for choose.
I do not like it. Every tag that would require jx:parameter would have 
to implement two classes: one that handles the tag itself and the second 
one for the paramter:

jx:macro name="macroName"/jx:paramter name="foo" defaultValue="bar"

jx:call/jx:paramter name="foo" value="bar"

> 2. Refactor the instructions so that they are constructed at the end tag 
> instead of the start tag. This require more work as the instruction 
> extends the start tag and must be made an own object that is refered to 
> from the start tag instead. Also instead of that tags has access to the 
> stack of parents it would have access to its compiled children.
This one is better but still there are some cons. If every tag is to be 
meant final then there are 2 objects for each tag instead of one. The 
script size doubles.

I like Jonas' approach. Create the tag at startup but do the work at 
finish (on the same object). Still this does not allow for final objects.

> I would prefer 2. even if it requires more work as it among other things 
> means that all member variables can be final as everything is 
> constructed as once.
Why are you pushing for final variables in this case? I do not see much 
gain here.

> Once this is solved we can refactor the Parser so that it take a 
> exprssion factory, a string template parser and a set of instuctions as 
> arguments and remove all the references to specific instructions.
There is one big thing asked many times for: jx:attribute 
implementation. AFAIU the implementation is not that trivial at all:
   <jx:attribute name="fooattr" value="barattr"/>

This is the most simple case. Still you have to cache all ignorable 
whitespace awaiting possible jx:attribute. This may affect performance 
and raise memory allocation per script invocation.

   some content
   <jx:attribute name="fooattr" value="barattr"/>

Is it ok to generate some text content and request jx:attribute later 
on? I do not quite remember how it is handled by XSLT

   <jx:if test="${doAttributize}">
     <jx:attribute name="fooattr" value="barattr"/>

Get's even better if you involve instructions.

It looks like all content no SAX event may be generated until we are 
sure there can be no jx:attribute, which means another node is being 
started or the current one gets finished.

This may not be that hard to implement but I'd rather go first with 
event code refactoring and just keep that feature in mind so the 
architecture allows for future implementation.

> Execution
> - - - - -
> Each instruction has an execute method that is called in the Invoker:
> public Event execute(final XMLConsumer consumer,
>                      ExpressionContext expressionContext,
>                      ExecutionContext executionContext,
>                      StartElement macroCall,
>                      Event startEvent, Event endEvent)
>     throws SAXException;
> Here consumer, expressionContext and executionContext is rather obvious. 
>  Of the remaining arguments we have macroCall that is used to pass the 
> macro call body that can be executed whithin a  macro with jx:evalBody. 
> For getting things simpler I would suggest that parameter to be removed 
> and passed in the expressionContext instead, this is already done for an 
> ordinary macro call that puts the information in the variable macro. 
> This should be done for jx:eval as well.
Agreed. Out of over a dozen cases the macroCall is not null only once or 
twice. Awful :)

> One could refactor the events so that we get a more tree based design as 
> in Jonas proposal. it is easier to write code for that than the 
> startEvent, endEvent representation in JXTG. But I don't know if it is 
> worthwhile.
Do you mean that every event is represented only for one class which 
remembers the exact start and finish position in compiled script? I like 
it much more that current JXTG design but it is in contradiction with 
your requirement that every Script event should be final.

> We could simplify the invoker by puting the sax generating code in 
> execute methods in the events also, but thats mainly cosmetic.
> I would like to break out the macro execution code from the Invoker but 
> it needs further research to see if it is possible.
> Import
> - - -
> The import instruction performes the import in during execution I would 
> much prefer to do it during compile time. Is that possible without 
> breaking current functionality?
I haven't checked the code but can you do jx:import 
uri="${bizData.somePage}"/> or not?

Leszek Gawron                            
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message