Sun,
Thank you for the detailed explanation of how you read the Watir
documentation.
It is now clear to me that there is one key fact about Watir that you
still don't understand (and which may not be well documented).
Watir works with the HTML as *currently rendered in the browser* -- not
as delivered. Specifically "View Source" will show you the html that was
originally loaded by the Browser. But Javascript contained in the page
may execute (either on load or because of user actions) that changes the
structure of the page. This "changed structure" is actually what Watir
works with.
You said "but since in the code, the Javascript is not associated with
an HREF, it is not obvious that I need a link". Well, the Watir commands
that you ended up using won't work unless your "javascript" is
associated with an HREF and therefore the menuItem javascript function
must be making this very association.
If, instead of using View Source, you had used the IE Dev Toolbar, i
think you would see the <a> tag with a href associated with the
"javascript" url. Another way to get the currently rendered html would
be to call ie.frame('top_frame').html in irb.
One of the great things about the IE Dev Toolbar is that it also shows
you the HTML as currently rendered on the page. Maybe we need to say
more about WHY people should use this tool. Or maybe people aren't
getting the message that they need to use this tool?
Does this explanation help make sense of things?
Bret
P.S. I also realize that the RDOC could be made somewhat easier to
navigate internally (simply by, say, including a link from the "frame()"
method to the "Frame" class. It would also be great if we had a short
article that described "how" to read the RDOC. (hint, hint).
Sun wrote:
>> Well...
>>
>>> (1) There should be documentation that specifically
>>>
>> states how to drive a Javascript -- as in, use
>> .link(:url, "path")
>>
>>> (2) It should point out that it is driven by
>>>
>> "click", not fire_event('onclick').
>>
>>> (3) Actually, there should be documentation that
>>>
>> identifies all of the available API's, and provide
>> examples for each. Right now the Watir User Guide is
>> too simple. It doesn't handle real world situations.
>>
>>>
>>>
>> I believe most of this is documented in the API
>> Documentation.
>> http://wtr.rubyforge.org/rdoc/index.html
>>
>
> OK, not to be negative, but surely you're joking.
> Have you looked at that page? It is completely bassackwards when you are
> trying to find something. It is organized top down, hierarchically, and has
> no search feature.
>
> So...if I want to go to the rightmost list and look at each and every
> method...some are well documented others not so documented.
>
> But let's take this example:
> ie.frame("top_frame").link(:url,"javascript:Events.invokeEvent(\'2_11_act\')").click
> Now, the rdoc for frame says:
> ===
> Typical usage:
>
> ie.frame(:index, 1)
> ie.frame(:name , 'main_frame')
> ie.frame('main_frame')
> ===
> Good enough. But does it say I can do ie.frame("top_frame").link? No. Is
> "link listed as a Method? Why yes it is...if I knew that method was what was
> required here, that would be useful -- but since in the code, the Javascript
> is not associated with an HREF, it is not obvious that I need a link -- or
> even that there is a method called link. So I have to scroll through all
> methods hunting and checking. And even then -- I have to take a big guess
> because the typical usage says:
> ===
> Typical Usage
>
> ie.link(:url, /login/) # access the first link whose url
> matches login. We can use a string in place of the regular expression
> # but the complete path must be used,
> ie.link(:url, 'http://myserver.com/my_path/login.asp')
> ie.link(:index,2) # access the second link on the page
> ie.link(:title , "Picture") # access a link using the tool tip
> ie.link(:text, 'Click Me') # access the link that has Click Me as
> its text
> ie.link(:afterText, 'Click->') # access the link that immediately
> follows the text Click->
> ===
> See? Nothing about Javascript in there. Which there should be -- since this
> is a pretty common Javascript situation I think. So even if there WAS a
> search feature -- it wouldn't have hit on this. So as I result I basically
> wade through the forum, trying this and that.
>
> Look, I am not complaining about the work that has been done -- a number of
> people have done an excellent job with Watir. What I am saying is that if
> Testers are to use Watir, some much better documentation needs to be
> developed. As it happens, I am working up documentation as I go through this
> and learn Watir, and eventually that may be of use, but...it doesn't help me
> now! ;-)
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.openqa.org/thread.jspa?threadID=4171&messageID=11912#11912
> _______________________________________________
> Wtr-general mailing list
> Wtr-general@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-general
>
_______________________________________________
Wtr-general mailing list
Wtr-general@rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general
