Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Leszek Gawron wrote:
Vadim Gritsenko wrote:
<snip/>
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.
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.
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.
For the record, the back incompatible changes were removed :-)
from flow POV, not JXPath in JXTG...
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?
Update TreeProcessor so that it stores the parameter stack in the object
model?
Seems like addressing a problem at the basis :)
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
