back to the actual discussion at hand, this thread having been thoroughly derailed . . .
Tony, good points regarding things happening on navigation, I hadn't really considered that. I don't think navigating to a url with the http://user:passw...@domainsyntax is sufficient, because some browsers (at least firefox, don't know about others) pop up warnings before sending along user:password in this syntax. trying it just now in firefox popped up: 'Confirm: You are about to log in to the site "[the domain]" with the username "[username]"', and ok/cancel buttons. one option is to modify goto to handle the auth dialog, or maybe security alert, that may crop up during navigation before 'wait' will return. Browser#goto(url, options={:authenticate => ['username', 'password'], :clear_security_alert => (some information? maybe just true?)}) or something along those lines. another option is to make goto take an option not to wait, and deal with that stuff after. browser.goto(url, :wait => false) if modal= browser.modal_dialog modal.set_login_credentials(user, pass) modal.click_button('ok') end browser.wait another thought is that goto could take a block to generally do what is needed to finish the navigation, something like: browser.goto(url) do if modal=browser.modal_dialog modal.set_login_credientials('user', 'pass') modal.click_button('OK') end end and that way goto wouldn't return until wait was finished. I like this one best - I have encountered a number of different reasons the browser blocks, including login credentials and javascript prompts onload, like <body onload=prompt('something')>. another case I had was the browser occasionally hanging and needing to reload; if I could have stuck logic in to try reloading after thirty seconds or so it would have made things easier. this last option leaves the most flexibility to deal with such things. On Sun, Nov 29, 2009 at 13:56, Bret Pettichord <[email protected]> wrote: > > 3. ModalDialog#text (browser.modal_dialog.text) >> > > API is fine. I'm unclear on what text would be returned. > My current implementation has this returning document.textContent for the dialog in firefox. in IE, it looks for controls with a class name of 'static' and concatenates those together. The result of that is, for both browsers, getting the text of popus generated in the following ways all return "foo": javascript:alert('foo') javascript:prompt("foo", "bar") javascript:confirm("foo") For other things like security dialogs, I haven't played around with them to tell you what is returned. > > >> 4. ModalDialog#set_text_field(value) - this would find the first and >> presumably only editable text field on the popup and set its text to the >> given value. >> > > Prefer browser.dialog.text_field.set(value) > What happens for authentication dialogs that have two text fields? > this does look nicer, but then you have to implement another whole class (classes, actually, would need one for each browser I expect) for #text_field to return an instance of. I can't think of much use for such a class apart from setting and getting the value in the text field - none of the other watir methods really apply. and it seems like the (hypothetical) modal dialog class could handle these two operations (get text and set text) just fine. I can't think of any dialogs except for authentication that have two text fields. modal dialogs with html contents being another matter; accessing the container in those would have to go a different route I think, and normal container methods would apply to that. > > >> 5. ModalDialog#set_login_credentials(username, password) >> > > Prefer browser.authenticate(:username => 'username', :password => > 'password') > sure, I have no particular preference. will still need some method on the modal dialog class (which Browser#authenticate would call to), even if the api specifies Browser#authenticate. > > >> 6. ModalDialog#click_button(button_name) >> > > Prefer browser.dialog.button(:name = 'button_name').click > same point as above for implementing classes for #button to return - all it needs to do is be clicked, and maybe get the text of the button. I'm a bit torn; I agree that it reads more nicely, and more consistently with the rest of watir. but it also seems like over-generalization of just a couple of specific actions out into a class of their own. -Ethan On Sat, Nov 28, 2009 at 01:00, ! Tony ! <[email protected]> wrote: > Hi Ethan, Charley > > my take on what i see .... > The proposed api sounds good .. though i have my own list of changes. > > > 4. ModalDialog#set_text_field(value) - this would find the first and > presumably only editable text field on the popup and set its text to the > given value. > 6. ModalDialog#click_button(button_name) > Popups are of 3 types, alert, confirm and a prompt(which takes text as > input). > Instead of having 2 functions enter text and click the button on the > prompt, Just have one. > ModalDialog#click_button(button_name,text_field_value=nil) > > 5. ModalDialog#set_login_credentials(username, password) > This is for handling Basic authentication. In IE just drumming up and > calling this function will not handle it, cause you would have to handle > this in the wait logic. Not sure about firefox though. > Instead a more cross browser and easier solution would be, add a new goto > function. > Browser.goto_authurl(url,myusername, mypassword) { do a goto with " > http://myusername:myuserpassw...@url/<http://myusername:[email protected]/%22,>" > } > That should get you through to the auth page without adding any new > complexity to the wait logic. > > 6. security alerts - Yes Please keep Security popup handling separate, > they all need to be handled in the wait logic. Its not just clicking a > button on another popup. > > we need to have a broader discussion, and it seems like your ideas are >> fully baked right now? > > I am posting this here for discussion. This is just a proposal of what I > think might be a good way to do things. Nothing is fully-baked, I have no > code for this, it's just what I came up with off the top of my head > yesterday and am proposing. Discussing things like this are precisely why > I'm on the mailing list. > -will take 15 mins to come up with the code for IE(code is already out > there, just have to change the function names ) > > > I do deal with things you're dismissing, as do we all. File downloads? > Sounds great, but I don't have them, so I'm less motivated to work on them > in my spare time. Localization is kinda of on my front burner to take a look > at, though I have yet to do that. > -yeah file downloads, uploads, same here i never used them, maybe i > will take a look at it, i had read somebody had already done work on this. > > Thanks, > Tony > >
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
