cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: cocoon-template incompatible change
Date Sat, 25 Aug 2007 17:55:50 GMT
Leszek Gawron pisze:
> no worry, got that in control already. Problem lies both in
> instruction and
> 1.


> 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
context attribute is for. Could you explain what is expected behaviour of context presence
and lack
of it?

I thought that context attribute affects imported template (replaces it's context bean). On
other hand, current handling of local contexts makes use of jx:set instruction limited because
is no option to set value globally.

Actually, I was going to revise concept of local contexts and its use in template but forgot
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?
2. If it's somehow limited should we allow global sets (I'm really reluctant to that option)?

I think we should pattern ourselves on XSLT design.

> 2.
> There is exactly the same problem here:
>> <root xmlns:jx="">
>>     <foo xmlns="">
>>         <jx:set var="foo" value="bar"/>
>>         <inner>${foo}</inner>
>>     </foo>
>>     <outer>${foo}</outer>
>> </root>
> as you expect the output currently is:
> <root xmlns:jx="">
>     <foo xmlns="">
>         <inner>bar</inner>
>     </foo>
>     <outer/>
> </root>
> With this one I'm not that sure what to do:
> 2.a. remove markLocalContext() in StartPrefixMapping and
> cleanupLocalContext() in EndPrefixMapping. This clearly has side effect
> I am not able to analyze. I am not even sure this will work properly as
> some properties of object model will probably get overriden. Please
> comment.

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 namespaces.

> 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 in
Event#execute() method.

I believe we could sort out current problems without polluting ObjectModel as soon as we establish
precise contracts for jx:set.

Grzegorz Kossakowski

View raw message