You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2005/01/23 23:01:49 UTC
[status/roadmap] JXTG Refactoring
I have done some progress in refactoring JXTG and would like to
summarize the current state and direction for those interested. I'm not
repeating things that are actively discussed in other threads.
Goal
====
The goal with the refactoring is to factor out things that are useful in
other contexts from JXTG and to make the code easier to understand and
maintain.
More specifically:
* Factor out expression handling
* Factor out the object model
* Factor out "string template" handling, i.e. handling of strings in
attributes and elements that contain expressions
* Factor out instructions
* Factor out duplicated code
What is left after this is a reusable template engine and a number of
plugable components that can be used in it. I will be happy with the
state of the refactoring when an attribute template language
(http://wiki.apache.org/cocoon/Templates) can be implemented in terms of
the template engine and some of the components.
As suggested by the term "refactoring", JXTG is supposed to stay back
compatible. But as can be seen in some other threads there are some
"weird" behaviours in current JXTG that we should do something about in
one way or another.
State/Roadmap
=============
Expression Handling
-------------------
All Jexl and JXPath code is factored out to a pluggable expression
package o.a.c.components.expression.* and is described in
http://marc.theaimsgroup.com/?t=110595829700001&r=1&w=2. When it is
polished enough I hope it can be part of Cocoon core so that we can get
expression handling that behave in the same way everywhere in Cocoon.
The only class in JXTG that know anything about Expression is
o.a.c.template.jxtg.expression.JXTExpression. That embeds the
Expression, has factory methods for creating expressions and access
methods that do type conversion.
I think we can keep JXTExpression about as is for the time being. But we
should make the expression compilation more pluggable, now it just
follows JXTGs model. Also the convertions should preferably be done in
an own component, but that can wait.
Object Model
------------
The object model is factored out to
o.a.c.environment.FlowObjectModelHelper that is a copy of Carsten's
o.a.c.environment.TemplateObjectModelHelper from scratchpad, with some
small modifications. Especially there is a factory method that creates
an ExpressionContext with the object model as content. Also here I would
like to move this class to core when it is pollished enough. So that we
can reuse the object model in other places. One interesting application
a "generic" FOM expression module that could be used instead of all
other input modules and that would make Cocoon more coherent is
discussed in http://marc.theaimsgroup.com/?t=110633024300002&r=1&w=2.
From JXTG POV I think it is ok except for more extensive testing and
possible debugging.
String Template
---------------
The "string template" is mainly gathered in
o.a.c.template.jxtg.expression.Substitutions which contain a list of
Subst that either are JXTExpression or Literal. Here there is some work
left to do. I would like the string parsing to be plugable so that one
can use other schemes than the ${} and #{} from JXTG. Also some code in
the Invoker for evaluating a Substitution to a string could be moved to
Substitution.
Instructions
------------
The execution engine consists of
o.a.c.template.jxtg.script.ScriptManager that take care of compiling and
caching the script. o.a.c.template.jxtg.script.Parser that does the
compilation, o.a.c.template.jxtg.script.event.* that are used to store
SAX events and o.a.c.template.jxtg.instruction.* that are the actual
JXTG instructions.
The goal is that only instruction.* should be JXTG specific and that
everything under jxtg.script should be pluggable wrt instructions,
expressions and string parser and moved to o.a.c.template.script. We are
not there yet.
Construction
- - - - - -
Starting with the instructions they are supposed to be thread safe. This
is partly enforced by having all member variables final and use the
constructor for initializing everything that is known at compile time.
The current "interface" for the constructor is:
Start<Instruction>(StartElement raw, Attributes attrs, Stack stack)
throws SAXException;
Where the instructions extends StartInstruction and raw is the start
element for the instruction jx:if etc, this is used for taking care of
location etc. attrs is not suprisingly the attributes of the
instruction. Stack is a stack of the enclosing elements, this is used by
e.g. jx:when and jx:otherwise for installing themselves in the enclosing
jx:choose.
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.
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.
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.
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.
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.
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.
Error Handling
- - - - - - -
All the instructions contains nearly identical exception handling, could
we move it to the Invoker?
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?
Weird Instructions
- - - - - - - - -
Some of the instructions e.g. jx:set and jx:eval has somewhat
problematic behaviour. This is discussed in some other threads.
--- o0o ---
I have most certainly forgot lots of important stuff. But this should be
enough for now. Just ask about unclear things, or even better find a
good answer and write about it or implement it ;)
/Daniel
Re: [status/roadmap] JXTG Refactoring
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>
>>> 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.
>>
>> Hmm, can't we just throw away the ignorable whitespaces between the
>> start element and the jx:attribute?
>
> Wouldn't this break the functionality for those who serialize template
> output to text?
In the general case you are right, I just thought on the whitespaces
between an element and the jx:attribute that works on the element.
In such cases you probably don't want the spaces anyway.
Whitespaces between instructions are in most cases more about formatting
than something you want in your output.
I think current XSLT implementations shows that it is very hard to get
nice and intuitive whitespace handling :/
/Daniel
Re: [status/roadmap] JXTG Refactoring
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
>> 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.
>
>
> Hmm, can't we just throw away the ignorable whitespaces between the
> start element and the jx:attribute?
Wouldn't this break the functionality for those who serialize template
output to text?
--
Leszek Gawron lgawron@mobilebox.pl
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
Re: [status/roadmap] JXTG Refactoring
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>
>> No it doesn't the "instruction event" tag just contains the start and
>> end locations, maybe name and attribute and a referece to the
>> instruction object that contains the instruction data. So the data
>> will be splitted in two objects instead of one. The script will be a
>> little bit larger but script size is anyway not a particulary
>> important aspect. Caches and such things will contain most of the
>> runtime data anyway.
>>
>>> 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.
>>
>> We can create the "instruction event" tag at startup and the
>> instruction object at finish.
>
> I like that.
Good, then we go for that.
>>> 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>
>>>
<snip/>
>> I'm afraid that it is hard to implement. I see two possible solutions:
>
> Yeah .. right I did not have startElement method in my mind when saying
> this.
>
>> 1. Compile time analysis: For each element there is one list of
>> attribute generating instructions and one list of content generating
>> instructions. All instructions and events are classified as attribute
>> generating, content generating or unspecified (e.g. jx:if). An
>> unspecified gets its type from its childs (throgh bottom up
>> propagation). The complicated thing with this scheme is to type check
>> the macros, which means that all macros much be gathered during
>> compile time.
>>
>> 2. Run time handling: As you suggest above, the problem with this is
>> that it doesn't fit well with the SAX content handler. We need some
>> extended content handler that allows for attribute events as well, and
>> not sends a start element event until the next text element, start or
>> end element is recieved, so that it knows that all attributes are
>> consumed.
>
> The second one sounds simpler because it introduces a lot less
> dependencies.
Yes, I also prefer that, the first seem to complicated.
>>> I haven't checked the code but can you do jx:import
>>> uri="${bizData.somePage}"/> or not?
>>
>> That is allowed which rules out compile time import. I don't
>> understand the reason for that instruction, Chris Oliver seem to be
>> obsessed with efficency in most other cases.
>>
>> XSLT manage without dynamic URI parameters in xsl:include and
>> xsl:import, and I think we would as well. I sugest that we implement a
>> non dynamic jx:include that can be performed at compile time and start
>> a vote about deprecating jx:import when we have finished that.
>
> I've never used a dynamic import. It looks like the performance also
> could be improved with that step. Let's deprecate it then.
We must vote about deprication.
--- o0o ---
Ok seem like we have a plan. Then we just need some synchronization so
that we doesn't step on each others toes.
Write a short note on the list if you start working on something so do I
the same.
/Daniel
Re: [status/roadmap] JXTG Refactoring
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> No it doesn't the "instruction event" tag just contains the start and
> end locations, maybe name and attribute and a referece to the
> instruction object that contains the instruction data. So the data will
> be splitted in two objects instead of one. The script will be a little
> bit larger but script size is anyway not a particulary important aspect.
> Caches and such things will contain most of the runtime data anyway.
>
>
>> 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.
>
>
> We can create the "instruction event" tag at startup and the instruction
> object at finish.
I like that.
>> 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.
>
>
> Hmm, can't we just throw away the ignorable whitespaces between the
> start element and the jx:attribute?
>
>> <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 don't think we should allow that, it doesn't make sense as the
> attribute refers to the element and not the text.
>
>> I do not quite remember how it is handled by XSLT
>
>
> It is forbidden there, http://www.w3.org/TR/xslt#creating-attributes.
>
>> <foo>
>> <jx:if test="${doAttributize}">
>> <jx:attribute name="fooattr" value="barattr"/>
>> </jx:if>
>> </foo>
>>
>> Get's even better if you involve instructions.
>
>
> Ok, thats tricky indeed. I bet the XSLT designers had DOM tree building
> rather than SAX emitation when they designed that instruction :/
>
>> 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.
>
>
> Yes, thats my interpretation also.
>
>> This may not be that hard to implement
>
>
> I'm afraid that it is hard to implement. I see two possible solutions:
Yeah .. right I did not have startElement method in my mind when saying
this.
> 1. Compile time analysis: For each element there is one list of
> attribute generating instructions and one list of content generating
> instructions. All instructions and events are classified as attribute
> generating, content generating or unspecified (e.g. jx:if). An
> unspecified gets its type from its childs (throgh bottom up
> propagation). The complicated thing with this scheme is to type check
> the macros, which means that all macros much be gathered during compile
> time.
>
> 2. Run time handling: As you suggest above, the problem with this is
> that it doesn't fit well with the SAX content handler. We need some
> extended content handler that allows for attribute events as well, and
> not sends a start element event until the next text element, start or
> end element is recieved, so that it knows that all attributes are consumed.
The second one sounds simpler because it introduces a lot less
dependencies.
>> I haven't checked the code but can you do jx:import
>> uri="${bizData.somePage}"/> or not?
>
>
> That is allowed which rules out compile time import. I don't understand
> the reason for that instruction, Chris Oliver seem to be obsessed with
> efficency in most other cases.
>
> XSLT manage without dynamic URI parameters in xsl:include and
> xsl:import, and I think we would as well. I sugest that we implement a
> non dynamic jx:include that can be performed at compile time and start a
> vote about deprecating jx:import when we have finished that.
I've never used a dynamic import. It looks like the performance also
could be improved with that step. Let's deprecate it then.
--
Leszek Gawron lgawron@mobilebox.pl
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
Re: [status/roadmap] JXTG Refactoring
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> 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"
They could implement some ParametrizableInstruction interface that they
can install there seves through. Still I don't like it either. I
suggested it as it requires less changes of the current architecture.
>> 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.
No it doesn't the "instruction event" tag just contains the start and
end locations, maybe name and attribute and a referece to the
instruction object that contains the instruction data. So the data will
be splitted in two objects instead of one. The script will be a little
bit larger but script size is anyway not a particulary important aspect.
Caches and such things will contain most of the runtime data anyway.
> 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.
We can create the "instruction event" tag at startup and the instruction
object at finish.
>> 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.
Its maybe not that important. The gain is that if you have all
instruction member data final you don't risk to write code that changes
them by mistake which you wnat to avoid as they must be thread safe. It
is also possible that the compiler can make some use of that they are
final, I don't know.
Another reason that I want to separate the instruction event from the
instruction object is that it will be easier to reuse the instruction
object when we write an attribute template language, if they not are
connected to an element.
Anyway we go for some variant of solution 2.
>> 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.
Hmm, can't we just throw away the ignorable whitespaces between the
start element and the jx:attribute?
> <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 don't think we should allow that, it doesn't make sense as the
attribute refers to the element and not the text.
> I do not quite remember how it is handled by XSLT
It is forbidden there, http://www.w3.org/TR/xslt#creating-attributes.
> <foo>
> <jx:if test="${doAttributize}">
> <jx:attribute name="fooattr" value="barattr"/>
> </jx:if>
> </foo>
>
> Get's even better if you involve instructions.
Ok, thats tricky indeed. I bet the XSLT designers had DOM tree building
rather than SAX emitation when they designed that instruction :/
> 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.
Yes, thats my interpretation also.
> This may not be that hard to implement
I'm afraid that it is hard to implement. I see two possible solutions:
1. Compile time analysis: For each element there is one list of
attribute generating instructions and one list of content generating
instructions. All instructions and events are classified as attribute
generating, content generating or unspecified (e.g. jx:if). An
unspecified gets its type from its childs (throgh bottom up
propagation). The complicated thing with this scheme is to type check
the macros, which means that all macros much be gathered during compile
time.
2. Run time handling: As you suggest above, the problem with this is
that it doesn't fit well with the SAX content handler. We need some
extended content handler that allows for attribute events as well, and
not sends a start element event until the next text element, start or
end element is recieved, so that it knows that all attributes are consumed.
> but I'd rather go first with
> event code refactoring and just keep that feature in mind so the
> architecture allows for future implementation.
Yes.
>>
>> 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 :)
Actually it is non null in more cases, if you have a number of jx:if,
jx:forEach or jx:choose that encloses the jx:evalBody e.g. But this can
be handled with the macro stack parameter anyway.
>> 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?
Yes
> I like
> it much more that current JXTG design but it is in contradiction with
> your requirement that every Script event should be final.
Not necesarilly as described above.
>> 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?
That is allowed which rules out compile time import. I don't understand
the reason for that instruction, Chris Oliver seem to be obsessed with
efficency in most other cases.
XSLT manage without dynamic URI parameters in xsl:include and
xsl:import, and I think we would as well. I sugest that we implement a
non dynamic jx:include that can be performed at compile time and start a
vote about deprecating jx:import when we have finished that.
/Daniel
Re: [status/roadmap] JXTG Refactoring
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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:
<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.
>
> 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 lgawron@mobilebox.pl
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