On 4/4/07, Alexander Klimetschek <[EMAIL PROTECTED]>
wrote:

Sounds good. We had this discussion a few months ago, where Daniel
explained
the problems with the parameters:

http://thread.gmane.org/gmane.text.xml.cocoon.devel/68157

I'd like to mention that there are two things we are talking about (I was
mixing them up in my first post ;-):

1) the original HTTP request parameters
2) cocoon attributes that can be set by the caller

The first was solved by you easily since it is static and overriding works
as expected. But with setting attributes (eg. by an action in a sitemap),
the separation between global attributes (for any block) and local
attributes (only for the current block and maybe the one's called by him)
is
needed.

There is also the request-scoped bean mentioned, where some work has
happened in the last time (regarding cocoon Environment). But I don't know
if this is in a state that allows you to do new things or at least
implement
the 2nd point more easily.


Yes, I think a lot of things to meet the requirements in the discussion have
been done in trunk but the author (Daniel?) seems not have time to connect
all stuffs together. For example, there has been a call frame stack.
All I do is just having a quick-but-dirty implementation of the logic I
stated earlier.

Rice

Alex

Rice Yeh schrieb:
> Not only  request.getParameter(String name) has problem but
> request.getLocale() has problem too. So I decide to modify some methods
in
> BlockCallHttpServletRequest. My logic is as follows:
>
> For parameters:
>  First ask the request in the current call frame. If a parameter is not
> found in the current request,  ask the request in the previous call
frame.
>
> For locale:
>  Directly ask the request in previous call frame and eventually the
request
> in the first call frame, which is not an instance of
> BlockCallHttpServletRequest,   answer the question.
>
> With such logic, a parameter in current request can override the
previous
> one for the time in current call frame. Once leaving current call frame,
> the
> overriding effect disappear.
>
> I test it in my application. It works for me now. But do not know such
> logic
> applies to others' use cases.
>
> Rice


--
Alexander Klimetschek
http://www.mindquarry.com


Reply via email to