cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: cocoon-template incompatible change
Date Sun, 26 Aug 2007 18:07:31 GMT
Grzegorz Kossakowski wrote:
>> this one is quite obvious:
>> markLocalContext() should be executed only if a context object is
>> explicitly set with <jx:import uri="sth" context="${contextObject}"/>
>> (or should not?)
> You are right, the problem is with local contexts. I remember that I didn't understand
what the
> context attribute is for. Could you explain what is expected behaviour of context presence
and lack
> of it?
to tell you the truth I have never used jx:import with context set, has 

> I thought that context attribute affects imported template (replaces it's context bean).
On the
> other hand, current handling of local contexts makes use of jx:set instruction limited
because there
> is no option to set value globally.
It works exactly as you've described. But when you import a template 
without context object the current one should be used.

> Actually, I was going to revise concept of local contexts and its use in template but
forgot about
> it in the end. Thanks to your discovery I guess it makes sense to think about it a little
> Before we fix anything I would like to see contracts of jx:set instruction clearly stated.
I think
> we should answer two questions:
> 1. What's the scope of variable introduced by jx:set?
you are probably asking the wrong question. jx:set always puts a 
variable in current context. The question should be: which 
elements/instructions should trigger a new local context.

I think new local context should never be introduced for plain xml 
elements (either local or imported, namespaced or not).

jx:if, jx:choose, jx:forEach, etc. should create a new local context.

jx:call (along with alternative <macroName/> invocation) should create a 
new context that DOES not inherit from parent context (only the 
parameters explicitly passed with <jx:call macro="macroName" 
param1="value" param2="value"/>) should be visible.

> 2. If it's somehow limited should we allow global sets (I'm really reluctant to that
not needed IMO

> Simply removing this instructions is not the best option because there would be a lot
of junk
> (namespace declarations) laying in Object Model when, in fact, we would be out of this

I have no experience in xml namespaces area.

Are these valid xml files?:

   <foo:foo xmlns:foo="">

   <!-- different namespace, same prefix -->
   <foo:foo xmlns:foo="">

   <foo:foo xmlns:foo="">

   <!-- namespaced element outside namespace declaration -->

If the second one is valid we have to keep all declared namespaces till 
the end of xml file (gets worse for xmls with jx:imports). Unnecessary 
namespaces are cleared anyway by a filter:

XMLConsumer consumer = new AttributeAwareXMLConsumerImpl(new 

>> 2.b. introduce new methods to ObjectModel which
>>     * register namespace local context
>>     * unregister namespace local context without removing variable
>> declarations
> One of my main goals was to have ObjectModel interface as small and clean as possible.
That's why I
> moved namespace handling out of Object Model and introduced new namespaces parameter
> Event#execute() method.
> I believe we could sort out current problems without polluting ObjectModel as soon as
we establish
> precise contracts for jx:set.

Once again: the contract of jx:set is clear. On the contrary we have 
inconsistent context creation contract for all other jx:* instructions.

Leszek Gawron               
CTO at MobileBox Ltd.

View raw message