Leszek Gawron wrote:
Leszek Gawron wrote:
Vadim Gritsenko wrote:
<snip/>
The flow independence we talked about was to make JXTG work without needing to call flow before JXTG in the pipeline, not about making it independent from the flow code. As discussed before in various threads, we should factor out environment handling code from flow, jxtg and sitemap and have a common model. I started to work on such code in o.a.c.components.accessor in the template block.Why FOM_Request is in jx in the first place? I understand why it is in old jxtg in Cocoon 2.1, but new version should be flow independent.
for that we have to ask Daniel as he was the one to introduce it in TemplateObjectModelHelper revision 159059: "Using FOM wrappers for request session and context, to get the same behaviour as in the original JXTG."
We should revert it IMO and fix inconsistencies other way.
AAHA! remember now. On pure o.a.c.environment.Request you cannot do coocon/request/someParameter (previous syntax) or the better one: cocoon/request/parameters/someParameter cocoon/request/attributes/someAttribute
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.
We could copy the wrappers from flow to make jxtg independent from flow. But as long as we don't factor out flow to a separate block I don't see the point. IMO it is better to focus on finish and start using the accessors that we have discussed in earlier threads about unified unvironment models.
We could provide some kind of request wrapper (do not know how to emulate getParameters though) or implement RequestJXPathBeanInfo (do not know how also :))Carsten added such wrappers in rev 27976 of the TemplateObjectModelHelper and removed them in 153807. Maybe we should add them again ;)
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?
/Daniel
