cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rice Yeh" <rice...@gmail.com>
Subject Re: Parameters in request get lost when using servlet: protocol
Date Wed, 04 Apr 2007 09:50:08 GMT
On 4/4/07, Alexander Klimetschek <alexander.klimetschek@mindquarry.com>
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
>
>

Mime
View raw message