I'd suggest first (b) and then (a). Least harm done. Jarmo
On Tue, Jan 4, 2011 at 12:12 AM, Bret Pettichord <[email protected]>wrote: > 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 >
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
