cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: [status/roadmap] JXTG Refactoring
Date Mon, 24 Jan 2005 22:28:18 GMT
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

Mime
View raw message