As a sidenote, deprecating CookieManager can be a totally independent thing since currently nothing loads it automatically in Watir. So if someone is using it then they had to load it manually. I'd say that makes it even more doubtful that it's used. But who knows. Just don'd deprecate it before there's some real implementation :)
Jarmo On Mon, Jan 3, 2011 at 10:11 PM, Charley Baker <charley.ba...@gmail.com>wrote: > That sounds like a good general API. Watir has had the CookieManager > trailing around for a while as a contributed component. I'm not sure > how many people use it, but it's a bit weak and is more of an addon > than truly integrated into the core API which it should be. I've > hacked around that area a bit for some of the gap common domains, and > cookie refreshes. > > I'd like to get more feedback from users, as this is a fairly common > case. I'll ping a few people as well, since the Gap uses various > toplevel domains and redirection but some common cookies across > domains for a type of SSO. A lot of the cookie work there was visiting > custom urls for refreshing/deleting. FB had something similar. > > This is a good idea to incorporate cookie management more cleanly, and > the api looks good. Next steps imho, let's figure out who if anyone is > using the CookieManager, and deprecate that. Pull a few use cases from > some companies that are doing a lot cookie management, write some > tests and implement. > > Thoughts? > > > Charley Baker > Lead Developer, Watir, http://watir.com > > > > On Mon, Jan 3, 2011 at 11:58 AM, Jari Bakken <jari.bak...@gmail.com> > wrote: > > On Mon, Jan 3, 2011 at 7:05 PM, Jarmo <jarm...@gmail.com> wrote: > >> In #watir channel we had a short discussion about a possible unified API > >> between all current Watir implementations. We came up with an API like > this: > >> browser.cookies # returns Cookies object which includes Enumerable > >> browser.clear # removes all cookies > >> browser << new_cookie # adds cookie > >> browser.delete new_cookie > >> #<< should take a Cookie object as an argument if i understood correctly > >> with #delete cookies are deleted only by "name" when talking about > >> Watir-WebDriver, but maybe it's/will be different with other > implementations > >> so #delete should also take a Cookie object as an argument. Or maybe > just > >> "name". > > > > You probably mean browser.cookies.clear, browser.cookies << etc. > > Something like this: https://gist.github.com/763769. > > > > I think #add wouldn't need to take a separate Cookie object - a Hash > > will probably do fine (the Cookies class can do some validation). The > > way it works in WebDriver (which IMO it would make sense to adopt), > > cookies look like this: > > > > { > > :name => "foo", > > :value => "bar", > > :path => "/some/path", > > :domain => "some.domain", > > :expires => DateTime, > > :secure => true/false > > } > > > > When adding a Cookie, only the :name and :value keys are mandatory, > > :path defaults to "/", :secure defaults to false, :domain defaults to > > the current domain, and :expires will only be set if set by the user > > (valid types are Time, DateTime, or Numeric (number of seconds)). > > > > A constraint in WebDriver is that cookie manipulation only affects the > > current domain - if Cookies#add is called with another domain, it will > > raise an InvalidCookieDomain error. Likewise, Cookies#clear will only > > clear cookies for the current domain. I'm not entirely sure what the > > reason for this is (I'm suspecting IE), perhaps Simon can shed some > > light. If we want cross-browser compatible, we may need to > > (artificially) impose this constraint , even for implementations that > > can support cross-domain cookie manipulation. > > > > Jari > > > > > > > > > > > > > > > > > > > > > >> Jari liked more the API where "name" is the argument due to the > limitations > >> of WebDriver, but this would mean that if user has a Cookie object > already > >> then he/she had to execute #name explicitly. I wouldn't make that as a > >> requirement. > >> I also noticed that currently Watir doesn't have anything related with > >> cookies except CookieManager, which seems not to be best. And nothing > for > >> FireWatir. That means that the API for cookies is an open subject and > free > >> to change, i guess. > >> What are other's thoughts about the matter? > >> Jarmo > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development@rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > >> > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development@rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development@rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development >
_______________________________________________ Wtr-development mailing list Wtr-development@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-development
