Leszek Gawron pisze:
>
> no worry, got that in control already. Problem lies both in Import.java
> instruction and StartPrefixMapping.java:
>
> 1. Import.java
<snip/>
>
> 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?
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.
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 more.
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. StartPrefixMapping.java:
>
> There is exactly the same problem here:
>
>> <root xmlns:jx="http://apache.org/cocoon/templates/jx/1.0";>
>> <foo xmlns="http://foor.org/bar/1.0";>
>> <jx:set var="foo" value="bar"/>
>> <inner>${foo}</inner>
>> </foo>
>> <outer>${foo}</outer>
>> </root>
>
> as you expect the output currently is:
> <root xmlns:jx="http://apache.org/cocoon/templates/jx/1.0";>
> <foo xmlns="http://foor.org/bar/1.0";>
> <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
http://reflectingonthevicissitudes.wordpress.com/
