You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Leszek Gawron <lg...@mobilebox.pl> on 2005/05/10 16:35:48 UTC
#{$cocoon/request/request/protocol}
I know now why #{$cocoon/request/protocol} does not work for JXPath in
JXTG. Thing is FOM_Request is not "JXPath friendly". JXPath is querying
for all FOM_Request properties and finds none.
if you add public Request getRequest() to FOM_Request then you are able
to do #{$cocoon/request/request/protocol} and it works.
What should I do to make it work?
Do we go with FOM_RequestJXPathBeanInfo and provide our own introspector?
What do we really need FOM_Request for if the API has been unrestricted?
--
Leszek Gawron lgawron@mobilebox.pl
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
Re: #{$cocoon/request/request/protocol}
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Leszek Gawron wrote:
> Vadim Gritsenko wrote:
>
>> 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.
+1: I would expect new jxtg finally work in completely "flowless" environment.
Vadim
Re: #{$cocoon/request/request/protocol}
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>
>> Leszek Gawron wrote:
>>
>>> Daniel Fagerstrom wrote:
>>
<snip/>
>>>> IMO we should make the Request interface bean friendly and add the
>>>> methods:
>>>>
>>>> Map getParameters();
>>>> Map getAttributes();
>>>
>>> You won't reach those as collection in HttpServletRequest
>>>
>>> http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpServletRequest.html
>>>
>>
>>
>> I know, but we have an own environment abstraction, so we can have
>> stuff that isn't part of the servlet definition. For the
>> implementation we just need to wrap the parameters and attributes as
>> maps in HttpRequest.
>
> You're right. We could take the approach Carsten implemented in
> DynamicMap. Request parameters parameters could be lazily fetched from
> underlying implementation and put into a map. Still we could not
> provide an iterator...
>
There are getAttributeNames and getParameterNames in the ServletRequest
so iterators should be possible.
/Daniel
Re: #{$cocoon/request/request/protocol}
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
>
>> Daniel Fagerstrom wrote:
>
>
> <snip/>
>
>>> Are you certain about that it doesn't work for properties? I can't
>>> test right now, but looking at
>>> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/scratchpad/java/org/apache/cocoon/environment/TemplateObjectModelHelper.java?rev=27976&view=markup
>>>
>>> in DynamicMap.getDynamicInfo it looks to me that it handle properties.
>>> ...
>>>
>>> result = PropertyUtils.getProperty(*this*.information, key.toString());
>>
>>
>> Misunderstanding. You cannot access "protocol" attribute. meaning
>> $cocoon/request/protocol gets the property and the syntax does not
>> provide a way do do request.getAttribute( "protocol" );
>
>
> Ok. The fact that the property shadows the attribute is a "feature" of
> making the request attributes accessible through
> $cocoon/request/myAttribute. One could of course let the attribute
> shadow the proprty instead. But the shadowing is a result of the
> original FOM design.
>
>>> IMO we should make the Request interface bean friendly and add the
>>> methods:
>>>
>>> Map getParameters();
>>> Map getAttributes();
>>
>>
>> You won't reach those as collection in HttpServletRequest
>>
>> http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpServletRequest.html
>>
>
>
> I know, but we have an own environment abstraction, so we can have stuff
> that isn't part of the servlet definition. For the implementation we
> just need to wrap the parameters and attributes as maps in HttpRequest.
You're right. We could take the approach Carsten implemented in
DynamicMap. Request parameters parameters could be lazily fetched from
underlying implementation and put into a map. Still we could not provide
an iterator...
--
Leszek Gawron lgawron@mobilebox.pl
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
Re: #{$cocoon/request/request/protocol}
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
<snip/>
>> Are you certain about that it doesn't work for properties? I can't
>> test right now, but looking at
>> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/scratchpad/java/org/apache/cocoon/environment/TemplateObjectModelHelper.java?rev=27976&view=markup
>>
>> in DynamicMap.getDynamicInfo it looks to me that it handle properties.
>> ...
>>
>> result = PropertyUtils.getProperty(*this*.information, key.toString());
>
> Misunderstanding. You cannot access "protocol" attribute. meaning
> $cocoon/request/protocol gets the property and the syntax does not
> provide a way do do request.getAttribute( "protocol" );
Ok. The fact that the property shadows the attribute is a "feature" of
making the request attributes accessible through
$cocoon/request/myAttribute. One could of course let the attribute
shadow the proprty instead. But the shadowing is a result of the
original FOM design.
>> IMO we should make the Request interface bean friendly and add the
>> methods:
>>
>> Map getParameters();
>> Map getAttributes();
>
> You won't reach those as collection in HttpServletRequest
>
> http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpServletRequest.html
>
I know, but we have an own environment abstraction, so we can have stuff
that isn't part of the servlet definition. For the implementation we
just need to wrap the parameters and attributes as maps in HttpRequest.
>>> Of course there are similar problems with session and context.
>>> It is a serious blocker for users to just try to switch to 2.2-dev
>>> and use new JXTG.
>>
>>
>>
>> IIRC it has nothing to do with the new JXTG, it didn't work with the
>> original either. It is, IIRC, an effect of the refactoring of FOM in
>> 2.2.
>
> yes but it affects JXTG a lot.
>
Sure, and we should solve it. Just wanted to point out that it not is an
effect of the JXTG refactoring.
/Daniel
Re: #{$cocoon/request/request/protocol}
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
>
>> Daniel Fagerstrom wrote:
>
>
> <snip/>
>
>> The accessors do not solve the problem with
>> $cocoon/request/requestAttribute or $cocoon/request/requestParameter
>> (preferably $cocoon/request/attributes/someAttribute and
>> $cocoon/request/parameters/someParameter)
>>
>>>> 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 ;)
>>
>>
>> They aren't correct. The only thing changed from oryginal Request
>> interface is that you can access request attribute using
>> cocoon/request/attribute. It wouldn't work for "protocol" attribute as
>> there is such property in Request interface. It does not work for
>> request parameters at all - you have to query them using a method).
>
>
> Are you certain about that it doesn't work for properties? I can't test
> right now, but looking at
> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/scratchpad/java/org/apache/cocoon/environment/TemplateObjectModelHelper.java?rev=27976&view=markup
>
> in DynamicMap.getDynamicInfo it looks to me that it handle properties.
> ...
>
> result = PropertyUtils.getProperty(*this*.information, key.toString());
Misunderstanding. You cannot access "protocol" attribute. meaning
$cocoon/request/protocol gets the property and the syntax does not
provide a way do do request.getAttribute( "protocol" );
>
> ...
>
>> I'd like to fix that even before we move to accessors.
>
>
> Its a different concern from what accessors solves, so that sounds
> reasonable.
>
>> I do not know how to do it properly though so these constructs provide
>> valid results:
>>
>> JEXL:
>> cocoon.request.property - works now
>> cocoon.request.parameters.someParameter
>> cocoon.request.attributes.someAttribute
>>
>> JXPath:
>> $cocoon/request/property
>> $cocoon/request/parameters/someParameter
>> $cocoon/request/attributes/someAttribute
>
>
> IMO we should make the Request interface bean friendly and add the methods:
>
> Map getParameters();
> Map getAttributes();
You won't reach those as collection in HttpServletRequest
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpServletRequest.html
>> Of course there are similar problems with session and context.
>> It is a serious blocker for users to just try to switch to 2.2-dev and
>> use new JXTG.
>
>
> IIRC it has nothing to do with the new JXTG, it didn't work with the
> original either. It is, IIRC, an effect of the refactoring of FOM in 2.2.
yes but it affects JXTG a lot.
--
Leszek Gawron lgawron@mobilebox.pl
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
Re: #{$cocoon/request/request/protocol}
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
<snip/>
> The accessors do not solve the problem with
> $cocoon/request/requestAttribute or $cocoon/request/requestParameter
> (preferably $cocoon/request/attributes/someAttribute and
> $cocoon/request/parameters/someParameter)
>
>>> 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 ;)
>
> They aren't correct. The only thing changed from oryginal Request
> interface is that you can access request attribute using
> cocoon/request/attribute. It wouldn't work for "protocol" attribute as
> there is such property in Request interface. It does not work for
> request parameters at all - you have to query them using a method).
Are you certain about that it doesn't work for properties? I can't test
right now, but looking at
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/scratchpad/java/org/apache/cocoon/environment/TemplateObjectModelHelper.java?rev=27976&view=markup
in DynamicMap.getDynamicInfo it looks to me that it handle properties.
...
result = PropertyUtils.getProperty(*this*.information, key.toString());
...
> I'd like to fix that even before we move to accessors.
Its a different concern from what accessors solves, so that sounds
reasonable.
> I do not know how to do it properly though so these constructs provide
> valid results:
>
> JEXL:
> cocoon.request.property - works now
> cocoon.request.parameters.someParameter
> cocoon.request.attributes.someAttribute
>
> JXPath:
> $cocoon/request/property
> $cocoon/request/parameters/someParameter
> $cocoon/request/attributes/someAttribute
IMO we should make the Request interface bean friendly and add the methods:
Map getParameters();
Map getAttributes();
A poll is needed for such interface changes.
I'm not certain why $cocoon/request/property doesn't work. But I think
that
o.a.c.components.flow.javascript.fom.FOM_Cocoon.AttributeHolderJavaObject,
the base class of FOM_Request etc, makes sure that the Java bean
properties only can be accessed as functions, not as properties.
If we use the Request object directly in TemplateObjectModelHelper, the
reflection mechanism in JXPath should be able to handle ordinary Java beans.
> None of above JXPath constructs work now.
> I've listed JEXL and JXPath separately because we have to provide
> different wrappers for Request interface.
>
> Jexl uses JSIntrospector (assumes cocoon.request is scriptable).
> JXPath assumes nothing and tries to work on the bean as it is - does
> not work at all.
IMO we should make Request bean friendly instead. To me it seem like all
this special purpose reflection stuff only makes things hard to
understand, use and maintain.
> Of course there are similar problems with session and context.
> It is a serious blocker for users to just try to switch to 2.2-dev and
> use new JXTG.
IIRC it has nothing to do with the new JXTG, it didn't work with the
original either. It is, IIRC, an effect of the refactoring of FOM in 2.2.
/Daniel
Re: #{$cocoon/request/request/protocol}
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
>> 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.
The accessors do not solve the problem with
$cocoon/request/requestAttribute or $cocoon/request/requestParameter
(preferably $cocoon/request/attributes/someAttribute and
$cocoon/request/parameters/someParameter)
>> 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 ;)
They aren't correct. The only thing changed from oryginal Request
interface is that you can access request attribute using
cocoon/request/attribute. It wouldn't work for "protocol" attribute as
there is such property in Request interface. It does not work for
request parameters at all - you have to query them using a method).
I'd like to fix that even before we move to accessors. I do not know how
to do it properly though so these constructs provide valid results:
JEXL:
cocoon.request.property - works now
cocoon.request.parameters.someParameter
cocoon.request.attributes.someAttribute
JXPath:
$cocoon/request/property
$cocoon/request/parameters/someParameter
$cocoon/request/attributes/someAttribute
None of above JXPath constructs work now.
I've listed JEXL and JXPath separately because we have to provide
different wrappers for Request interface.
Jexl uses JSIntrospector (assumes cocoon.request is scriptable).
JXPath assumes nothing and tries to work on the bean as it is - does not
work at all.
Of course there are similar problems with session and context.
It is a serious blocker for users to just try to switch to 2.2-dev and
use new JXTG.
> 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?
If you're asking for non-ugly ones - none..
--
Leszek Gawron lgawron@mobilebox.pl
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
Re: #{$cocoon/request/request/protocol}
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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 lgawron@mobilebox.pl
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
Re: #{$cocoon/request/request/protocol}
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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.
$cocoon/request/getProperty() this will not work now either.
JXPath queries FOM_Request for properties (with public getters - thats
my understanding) and gets none "meaningful" as FOM_Request looks like this:
> public static class FOM_Request extends AttributeHolderJavaObject {
> private final Request request;
>
> public FOM_Request(Scriptable scope, Request request) {
> super(scope, request, Request.class);
> this.request = request;
> }
>
> protected Enumeration getAttributeNames() {
> return this.request.getParameterNames();
> }
>
> protected Object getAttribute(String name) {
> return this.request.getParameter(name);
> }
> }
If you "accidentally" provide a getter for
private final Request request;
than you are able to do $cocoon/request/request/protocol and the
properties are visible. It means that FOM_Request is not able to
properly proxy Request interface to JXPath.
--
Leszek Gawron lgawron@mobilebox.pl
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
Re: #{$cocoon/request/request/protocol}
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez wrote:
> 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? :-/
<map:parameters> ...
--
Leszek Gawron lgawron@mobilebox.pl
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
Re: #{$cocoon/request/request/protocol}
Posted by Sylvain Wallez <sy...@apache.org>.
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
Re: #{$cocoon/request/request/protocol}
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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!
/Daniel
Re: #{$cocoon/request/request/protocol}
Posted by Sylvain Wallez <sy...@apache.org>.
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 :-)
> 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?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: #{$cocoon/request/request/protocol}
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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.
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
Re: #{$cocoon/request/request/protocol}
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Leszek Gawron wrote:
> Vadim Gritsenko wrote:
>
>> Leszek Gawron wrote:
>>
>>> I know now why #{$cocoon/request/protocol} does not work for JXPath
>>> in JXTG.
>>
>>
>>
>> [assuming that we are talking here about Cocoon 2.2 template block]
>>
>>
>>> Thing is FOM_Request is not "JXPath friendly". JXPath is querying for
>>> all FOM_Request properties and finds none.
>>
>>
>>
>> Why FOM_Request is in jxtg? I though this has already been refactored
>> to use flow independent accessor.
>>
>>
>>> if you add public Request getRequest() to FOM_Request then you are
>>> able to do #{$cocoon/request/request/protocol} and it works.
>>
>>
>>
>> Yuck! Don't even think about it!
>
> Of course. I just wanted to show what change makes a difference...
>
>>> What should I do to make it work?
>>> Do we go with FOM_RequestJXPathBeanInfo and provide our own
>>> introspector?
>>> What do we really need FOM_Request for if the API has been unrestricted?
>>
>>
>>
>> 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
We could provide some kind of request wrapper (do not know how to
emulate getParameters though) or implement RequestJXPathBeanInfo (do not
know how also :))
--
Leszek Gawron lgawron@mobilebox.pl
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
Re: #{$cocoon/request/request/protocol}
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Vadim Gritsenko wrote:
> Leszek Gawron wrote:
>
>> I know now why #{$cocoon/request/protocol} does not work for JXPath in
>> JXTG.
>
>
> [assuming that we are talking here about Cocoon 2.2 template block]
>
>
>> Thing is FOM_Request is not "JXPath friendly". JXPath is querying for
>> all FOM_Request properties and finds none.
>
>
> Why FOM_Request is in jxtg? I though this has already been refactored to
> use flow independent accessor.
>
>
>> if you add public Request getRequest() to FOM_Request then you are
>> able to do #{$cocoon/request/request/protocol} and it works.
>
>
> Yuck! Don't even think about it!
Of course. I just wanted to show what change makes a difference...
>> What should I do to make it work?
>> Do we go with FOM_RequestJXPathBeanInfo and provide our own introspector?
>> What do we really need FOM_Request for if the API has been unrestricted?
>
>
> 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.
--
Leszek Gawron lgawron@mobilebox.pl
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
Re: #{$cocoon/request/request/protocol}
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Leszek Gawron wrote:
> I know now why #{$cocoon/request/protocol} does not work for JXPath in
> JXTG.
[assuming that we are talking here about Cocoon 2.2 template block]
> Thing is FOM_Request is not "JXPath friendly". JXPath is querying
> for all FOM_Request properties and finds none.
Why FOM_Request is in jxtg? I though this has already been refactored to use
flow independent accessor.
> if you add public Request getRequest() to FOM_Request then you are able
> to do #{$cocoon/request/request/protocol} and it works.
Yuck! Don't even think about it!
> What should I do to make it work?
> Do we go with FOM_RequestJXPathBeanInfo and provide our own introspector?
> What do we really need FOM_Request for if the API has been unrestricted?
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.
Vadim