RE: Problem related to event parameters

Hi Jack,

> Our source tree for Barracuda is probably out of date.

Ok, so let's start by seeing if we can get you up and running on the latest
and greatest Barracuda - that way, we're both looking at the same code base.

Now, looking at the archives, here's what I did:

<b>csc_120602.1</b> - Change HttpServletRequestWrapper so that
getParameterMap returns map values as String[], like its supposed to
according to the spec. Also make it handle multiple values (previously it
didn't). Thanks to Udovenko Sergey [[email protected]] for bringing
this to my attention.

<b>csc_120502.1</b> - Added support to BaseEvent class to support the notion
of params. This means adding the following methods:
- void setParam(String key, String val)
- void setParam(String key, String[] vals)
- Map getParams()
You can use these events to "add" parameters to a URL request. Basically, if
you shove any values in here, then when this event is dispatched (by adding
it to the event queue) then the param values will get pulled out and
appended into the underlying Http req object. Thus to the code that handles
this event, it will look like the parameters where there all along. Pretty
slick! Thanks to Jack Hodges [[email protected]] for submitting this patch

All the places modified in the code by this second one can actually be found
by searching for jbh_112202.1.


> We have encountered a problem that others may encounter. When I
> use the 'setParam' approach multiple times, and on the 'other'
> side of the request (new event), I use 'req.getParameter', there
> will be more than one copy of a parameter in the request, one
> associated with the HttpRequest and the other associated with
> the Barracuda HttpServletRequestWrapper. Unfortunately, the
> ordering is not most-recent=lowest so the default retrieval is
> the first rather than the last value assigned.
>
> To counter this, we used our knowledge of the
> HttpServletRequestWrapper to cast the request and then call
> removeParameter for the key we are about to add into the event:
>
> ((org.enhydra.barracuda.core.helper.servlet.HttpServletRequestWrapper)
> req).removeParameter("personId");
> ((org.enhydra.barracuda.core.helper.servlet.HttpServletRequestWrapper)
> req).removeParameter("addressId");
> newEvent.setParam(AddressBookScreen.PERSONID,  personId);
> newEvent.setParam(AddressBookScreen.ADDRESSID, addressId);

Ok, so let me see if I understand the issue you are encountering here. Let's
say you have a starting URL like this:
http://myco.com/MyApp/GetFoo.event?parm1=Foo

When you are handling GetFoo, if you do a event.setParam("parm1","Blah"),
then when the event gets forwarded on, its actually being treated as
http://myco.com/MyApp/GetFoo.event?parm1=Foo&parm1=Blah ... in other words,
its converting to multiple parameters, rather than overwriting.

Is this a correct understanding of the problem?

Ok, now on to your request:

> The third possibility would be to modify the BaseEvent and
> DefaultBaseEvent
> Barracuda classes as follows:
>
> BaseEvent.java:
> ==============
>
>     /**
>      * Remove an associated param
>      */
>     public void removeParam(String key);
>
> DefaultBaseEvent.java:
> =====================
>
>     /**
>      * Remove an associated param
>      */
>     public void removeParam(String key) {
>         params.remove(key);
>     }
>
> This way, our code becomes the following:
>
> newEvent.removeParam(AddressBookScreen.PERSONID);
> newEvent.removeParam(AddressBookScreen.ADDRESSID);
> newEvent.setParam(AddressBookScreen.PERSONID,  personId);
> newEvent.setParam(AddressBookScreen.ADDRESSID, addressId);
>
> Is there any interest at your end in institutionalizing this modification?

Ok, so here I'm not sure if I correctly understand the proposed solution -
basically, the HttpServletRequestWrapper maintains its own param map (over
the top of HttpServletRequest), but the event params are completely separate
(ie. their own map). The only time they ever come together is when
DefaultEventDispatcher takes any params associated with the event and "adds
them on" to the req object. So the process here is always implicitly
addative.

Given that, I'm not sure how adding a removeParam method to the event would
make any difference - it would remove the object from the event param map,
but not from the original request.

So before I spend to much more time trying to guess at what you are
intending here, could you clarify?

I'm definitely open towards making a change, but I want to make sure its the
right one first.

Cheers,
Christian

ps - I'm cc'ing the list with this email just in case anyone else wants to
comment on it.
----------------------------------------------
Christian Cryder [[email protected]]
Internet Architect, ATMReports.com
Barracuda - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"

> -----Original Message-----
> From: Jack Hodges [mailto:[email protected]]
> Sent: Monday, March 03, 2003 9:44 PM
> To: 'Christian Cryder'
> Cc: Jack Hodges
> Subject: Problem related to event parameters
>
>
> Christian,
>
> A few months ago we worked together on adding parameters to
> events using the
> 'setParam' notation.
>
> At the time, you recommended that we use 'addParameter' instead of
> 'setParameter'.
>
> We have encountered a problem that others may encounter. When I use the
> 'setParam' approach multiple times, and on the 'other' side of the request
> (new event), I use 'req.getParameter', there will be more than
> one copy of a
> parameter in the request, one associated with the HttpRequest and
> the other
> associated with the Barracuda HttpServletRequestWrapper.
> Unfortunately, the
> ordering is not most-recent=lowest so the default retrieval is the first
> rather than the last value assigned.
>
> To counter this, we used our knowledge of the HttpServletRequestWrapper to
> cast the request and then call removeParameter for the key we are about to
> add into the event:
>
> ((org.enhydra.barracuda.core.helper.servlet.HttpServletRequestWrapper)
> req).removeParameter("personId");
> ((org.enhydra.barracuda.core.helper.servlet.HttpServletRequestWrapper)
> req).removeParameter("addressId");
> newEvent.setParam(AddressBookScreen.PERSONID,  personId);
> newEvent.setParam(AddressBookScreen.ADDRESSID, addressId);
>
>
> There are a few ways around this of course. Although it might seem obvious
> to change 'addParameter' to 'setParameter', the fact that the Barracuda
> HttpServletRequestWrapper class shadows the HttpServletRequest class means
> that this will not help.
>
> Second, one could do as we have [temporarily] done, but that requires an
> in-depth understanding of the Barracuda classes and just isn't
> very pretty.
>
> The third possibility would be to modify the BaseEvent and
> DefaultBaseEvent
> Barracuda classes as follows:
>
> BaseEvent.java:
> ==============
>
>     /**
>      * Remove an associated param
>      */
>     public void removeParam(String key);
>
> DefaultBaseEvent.java:
> =====================
>
>     /**
>      * Remove an associated param
>      */
>     public void removeParam(String key) {
>         params.remove(key);
>     }
>
> This way, our code becomes the following:
>
> newEvent.removeParam(AddressBookScreen.PERSONID);
> newEvent.removeParam(AddressBookScreen.ADDRESSID);
> newEvent.setParam(AddressBookScreen.PERSONID,  personId);
> newEvent.setParam(AddressBookScreen.ADDRESSID, addressId);
>
> Is there any interest at your end in institutionalizing this modification?
>
> Jack Hodges