Daniel Fagerstrom wrote:

Sylvain Wallez wrote:

Daniel Fagerstrom wrote:


<snip/>

Sylvain refactored the environment handling in flow to simplify it, but it also lead to some back incompatibilities that we had long heated discussions about this in the begining of this year, check the archive. The varoious changes in the TemplateObjectModelHelper was to keep it in synch with the changes in FOM_Cocoon.


For the record, the back incompatible changes were removed :-)


I know that you removed them. But $cocoon/request/property doesn't work for JXPath, you need $cocoon/request/getProperty() instead, IIUC. I think this has to do with the functionality of FOM_Cocoon.AttributeHolderJavaObject and that it is an effect of the refactoring, but maybe it didn't work before either.

<snip/>

But again, IMO we should start to use the accessors instead and focus our environment refactoring on them and remove the TemplateObjectModelHelper. I got stucked in the devlopment of them because I couldn't find any (non ugly) ways to make the sitemap parameters accessible as "cocoon.parameters", as accessors are components and only have access to the service manager and the context. If we separated the sitemap parameters from the rest of the environment handling we would get rid of this problem, but that would introduce a rather severe back incompability.

Any ideas?


Update TreeProcessor so that it stores the parameter stack in the object model?


Sound like a good solution!


After further thinking, it's not that easy: although this will be ok for sitemap control structures (match, select, act, call) that are executed immediately, this won't work for pipeline components which are collected in the pipeline for later execution. This would require a change in the Pipeline interface to pass the parameter stack in setGenerator(), addTransformer(), etc. We can do it of course, but it's not as innocent as it seemed at first.

Now I realize that "cocoon.parameters" may not be the sitemap variable stack but <map:parameters>. So... what are we talking about? :-/

Sylvain

--
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director



Reply via email to