By deprecate do you mean (a) remove it; or (b) cause to issue a deprecation warning when required?
Bret On Mon, Jan 3, 2011 at 3:39 PM, Charley Baker <[email protected]>wrote: > Yep, of course. My only thought there was to deprecate it, since it is > a bit old and untested, as well as ping the watir general list and > find out who's using it, and make sure we cover the base use cases as > well as inviting people in for however they may have extended it. I'll > send an email to that effect now. > > Cheers, > > Charley Baker > Lead Developer, Watir, http://watir.com > > > > On Mon, Jan 3, 2011 at 1:16 PM, Jarmo <[email protected]> wrote: > > 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 <[email protected]> > > 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 <[email protected]> > >> wrote: > >> > On Mon, Jan 3, 2011 at 7:05 PM, Jarmo <[email protected]> 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 > >> >> [email protected] > >> >> http://rubyforge.org/mailman/listinfo/wtr-development > >> >> > >> > _______________________________________________ > >> > Wtr-development mailing list > >> > [email protected] > >> > http://rubyforge.org/mailman/listinfo/wtr-development > >> > > >> _______________________________________________ > >> Wtr-development mailing list > >> [email protected] > >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > > > _______________________________________________ > > Wtr-development mailing list > > [email protected] > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Director, Watir Project, www.watir.com Blog, www.testingwithvision.com Twitter, www.twitter.com/bpettichord
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
