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 [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
