You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Donald Ball <ba...@webslingerZ.com> on 2001/07/10 21:27:50 UTC

augmenting the Request object

hey guys. i've got a patch that adds a new method to the Request object -
getCookieMap. does what it say, returns the Cookies in a Map. i find it to
be helpful and i'd like to commit it, but i wanted to check and see what
the party line was on augmenting the Request object. as long as the
augmented methods are implemented without resorting to any cocoon-specific
api's or objects, does anyone have a problem with adding new methods to
the Request object? if not, should the methods be named specially to avoid
possible conflicts with future servlet api's? (e.g. getXCookieMap() or
something).

- donald


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


AW: augmenting the Request object

Posted by Carsten Ziegeler <cz...@sundn.de>.

> -----Ursprungliche Nachricht-----
> Von: Donald Ball [mailto:balld@webslingerZ.com]
> Gesendet: Dienstag, 10. Juli 2001 21:28
> An: cocoon-dev@xml.apache.org
> Betreff: augmenting the Request object
>
>
> hey guys. i've got a patch that adds a new method to the Request object -
> getCookieMap. does what it say, returns the Cookies in a Map. i find it to
> be helpful and i'd like to commit it, but i wanted to check and see what
> the party line was on augmenting the Request object. as long as the
> augmented methods are implemented without resorting to any cocoon-specific
> api's or objects, does anyone have a problem with adding new methods to
> the Request object? if not, should the methods be named specially to avoid
> possible conflicts with future servlet api's? (e.g. getXCookieMap() or
> something).
>
No, I have no objection against augmenting the Request object as long as
the methods are valuable for everyone.
But I would like to have the interfaces fixed for the beta 2.


Carsten

Open Source Group                        sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de                          mailto: cziegeler@sundn.de
================================================================

> - donald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org