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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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:
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
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
17 matches
Mail list logo
