cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [status/roadmap] JXTG Refactoring
Date Mon, 24 Jan 2005 22:41:43 GMT
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>
>> 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.


View raw message