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.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:
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.
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:
<foo>
<jx:attribute name="fooattr" value="barattr"/>
</foo>
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.
<foo> some content <jx:attribute name="fooattr" value="barattr"/> </foo>
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
<foo>
<jx:if test="${doAttributize}">
<jx:attribute name="fooattr" value="barattr"/>
</jx:if>
</foo>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.
Agreed. Out of over a dozen cases the macroCall is not null only once or twice. Awful :)
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.
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 haven't checked the code but can you do jx:import uri="${bizData.somePage}"/> or not?
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?
-- Leszek Gawron [EMAIL PROTECTED] Project Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
