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