You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Remy Maucherat <re...@apache.org> on 2000/12/06 20:41:14 UTC
Header and HeaderElement
Hi,
I'll probably get rid of the current Header class, and replace it with the
HeaderElement class (actually, HeaderElement will become Header).
The only thing which will be changed is NameValuePair.toString(), which
would have to do what Header.toString() is doing. Header and NameValuePair
have the same API, so it shouldn't break anything (except I'll have to
replace HeaderElement by Header in the code).
Is it ok with you BC ?
Remy
Re: Header and HeaderElement
Posted by "Park, Sung-Gu" <je...@thinkfree.com>.
There is no order. Even though it's not important.
----- Original Message -----
From: "B.C. Holmes" <bc...@roxton.com>
To: <sl...@jakarta.apache.org>
Sent: Thursday, December 07, 2000 1:15 PM
Subject: Re: Header and HeaderElement
> Remy Maucherat wrote:
> >
> > I'll probably get rid of the current Header class, and replace it with the
> > HeaderElement class (actually, HeaderElement will become Header).
> >
> > The only thing which will be changed is NameValuePair.toString(), which
> > would have to do what Header.toString() is doing. Header and NameValuePair
> > have the same API, so it shouldn't break anything (except I'll have to
> > replace HeaderElement by Header in the code).
> >
> > Is it ok with you BC ?
>
> That's fine by me, although right now, the HeaderElement really
> only models the value part of the Header. I'd had, in the back of my
> mind, a plan to turn Header into a subclass of NameValuePair with an
> overload on toString(), but your approach also works.
>
> BCing you
> --
> B.C. Holmes \u2625 http://www.bcholmes.org/
> "How often has somebody sensed they were needed without being told?
> When you have a hurt in your heart you're too proud to disclose
> Look over there... look over there... Somebody always knows."
> - _La Cage aux Folles_
>
Re: Header and HeaderElement
Posted by "B.C. Holmes" <bc...@roxton.com>.
Remy Maucherat wrote:
>
> I'll probably get rid of the current Header class, and replace it with the
> HeaderElement class (actually, HeaderElement will become Header).
>
> The only thing which will be changed is NameValuePair.toString(), which
> would have to do what Header.toString() is doing. Header and NameValuePair
> have the same API, so it shouldn't break anything (except I'll have to
> replace HeaderElement by Header in the code).
>
> Is it ok with you BC ?
That's fine by me, although right now, the HeaderElement really
only models the value part of the Header. I'd had, in the back of my
mind, a plan to turn Header into a subclass of NameValuePair with an
overload on toString(), but your approach also works.
BCing you
--
B.C. Holmes \u2625 http://www.bcholmes.org/
"How often has somebody sensed they were needed without being told?
When you have a hurt in your heart you're too proud to disclose
Look over there... look over there... Somebody always knows."
- _La Cage aux Folles_