My proposed changes assume that the only thing needed was a more convenient way
to set cookie
parameters.
What you are proposing is a completely new API for cookie handling that would
require more
backwards-incompatible changes than simply adding one more method to an
existing interface. In
addition, all of what you are proposing, except for iterating over all cookies,
can be done already.
What you are proposing can be done but I don't know whether the gain in
functionality outweighs the
effort. Thoughts?
Cheers,
Uli
On 19.11.2012 12:38, Denis Stepanov wrote:
> It looks more like a cookie writer than a builder.
>
> It would be better to create an interface a.p.t.s.Cookie alternative to the
> javax.servlet.http.Cookie so it would be possible to modify current cookie
> value without using the servlet api, all setters could return Cookie instance
> to support method chaining, than there is no need for a builder at all.
>
> Suggested API:
>
> cookies.create("abc", "xyz").setPath("fff").setMaxAge("fdfdf") ...
>
> cookies.has("abc") // checks if cookie with a name "abc" exists
>
> cookies.get("abc").setValue("fffff"); // throws an exception if a cookie with
> a name "abc" doesn't exist
>
> cookies.remove("abc")
>
> cookies.getAll() : Collection<Cookie>
>
> for ... each ... when ...
> cookie.remove()
>
> I would deprecate all current methods from the a.p.t.s.Cookies service and
> remove them in the next version. Should be CookieSource and CookieSink
> refactored to use a.p.t.s.Cookie or removed?
>
> Denis
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
