cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: cocoon-template incompatible change
Date Sat, 25 Aug 2007 16:54:30 GMT
Grzegorz Kossakowski wrote:
> Leszek Gawron pisze:
>> Hello,
> Hello Leszek
>> previously (all my software bases on this behaviour) if a variable was 
>> declared at imported template it was available further on:
>>
>> <!-- macros.jx declares foo variable -->
>> <jx:import uri="view/macros.jx"/>
>> <tags>${foo}</tags>
>>
>> previous versions showed: <tags>bar</tags>
>> currently the scope changed and the template produces: <tags></tags>
>>
>> this produces the expected result:
>> <!-- lets declare foo ourselves -->
>> <jx:set var="foo" value="..."/>
>> <!-- macros.jx modifies the tags variable -->
>> <jx:import uri="view/macros.jx"/>
>> <!-- works as expected -->
>> <tags>${foo}</tags>
>>
>> was this intentional?
> 
> I guess it's due to my changes regarding switch to new Object Model and 
> it was not intentional. Even thought the bahaviour you are describing is 
> natural it seems that no code in Cocoon samples rely on it. What's more 
> important, it seems that it's not covered by test cases. If it was I 
> could spot the regression.
> 
> Leszek, I could help you with it but to avoid confusion I would need 
> complete test template with exactly expected result. However, I'm not 
> sure when I will be able because I have broken my openSUSE installation 
> (too much experiments with RAID). Nevertheless I suggest to create a new 
> issue.
> 
> If you want to debug it yourself let us know if you need advices on how 
> to debug Cocoon 2.2.

no worry, got that in control already. Problem lies both in Import.java 
instruction and StartPrefixMapping.java:

1. Import.java
> StartDocument doc;
> try {
>     doc = executionContext.getScriptManager().resolveTemplate(uri);
> } catch (ProcessingException exc) {
>     throw new SAXParseException(exc.getMessage(), getLocation(), exc);
> }
> objectModel.markLocalContext();
> if (this.select != null) {
>     try {
>         Object obj = this.select.getValue(objectModel);
>         objectModel.put(ObjectModel.CONTEXTBEAN, obj);
>         objectModel.fillContext();
>     } catch (Exception exc) {
>         throw new SAXParseException(exc.getMessage(), getLocation(), exc);
>     } catch (Error err) {
>         throw new SAXParseException(err.getMessage(), getLocation(),
>                                     new ErrorHolder(err));
>     }
> }
> try {
>     Invoker.execute(consumer, objectModel, executionContext,
>                     macroContext, namespaces, doc.getNext(), doc.getEndDocument());
> } catch (Exception exc) {
>     throw new SAXParseException(
>                                 "Exception occurred in imported template " + uri
>                                 + ": " + exc.getMessage(), getLocation(), exc);
> }
> 
> objectModel.cleanupLocalContext();

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?)

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.

2.b. introduce new methods to ObjectModel which
     * register namespace local context
     * unregister namespace local context without removing variable 
declarations

WDYT?

-- 
Leszek Gawron                         http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.


Mime
View raw message