Update index.rst

[schurma]

The name='btnG' does not exist on "http://www.google.com" and a run of the sample code results in an IndexError exception. I propose that the button be accessed by value='Google Search' as this will make the sample code work and will be more resilient to change than continuing to use the often-changing Google element names.

[jsfehler]

@schurma Your change wouldn't really make the code more resilient, not unless you know Google will never change the text in their submit button. It also introduces a breaking changes for anyone who uses google in a non-English language.

Finding elements by their text content should only be done when the text content is something that needs to be retrieved and evaluated. It's poor practice to use it for finding a button element and not the sort of thing I'd want displayed front and center in the documentation.

The code examples in the documentation should be more abstract. There's no way to control external websites and a google search example should be part of a longer tutorial, not part of the standard docs.

eg:

# Go to a website with a search input and submit button
# Then get the results of the search
with Browser('firefox') as b:
    b.visit('http://my.web.site/')
    b.find_by_css('#searchInput').fill('My Search Query')
    b.find_by_css('#searchSubmit').click()

    results = b.find_by_css('.results')
    if results[0].value == 'My Expected Result':
        print('Success!')
    else:
        print('Failure!')

[schurma]

That’s incorrect. This change will make the code more resilient. This will fix the broken script and prevent the breakage from recurring.

It isn’t true that this causes breakage for non-English users of Google. http://www.google.com defaults to English and the zope.testbrowser, geckodriver, and chromedriver engines used by Splinter all default to English. If someone knows how to change the language settings for those drivers then it’s incredibly unlikely that they’d be learning web automation for the first time using this sample script and then be perplexed why the “Google Search” text doesn’t match “Google [ & something clearly different]” text. That isn’t an instance of breaking changes. A breaking change is what happened to the Splinter example code after an ephemeral selector was used for a popular website.

It's correct that name selectors are often recommended over text selectors for a number of reasons, except that none of those reasons makes sense for the example. Google and other large companies know those recommendations and they craft those fields in order to break tools that crawl their websites. Popular websites have switched best practices with antipatterns for web automation.

The example doesn’t need to be abstract. It needs to work. It's embarrassing to recommend Splinter as the best web automation tool while the first example is broken. Most people won’t read any more docs if the first example is broken, especially if the broken example is used to explain the tool. If it’s important to maintain the remaining docs, then maybe the docs following the resilient example can begin it by asking the reader to get the name field of the button by viewing source. Then say, “For example, the name may equal btnk…”, then proceed from there. A sentence about the name selector being faster and better for dynamic text could be used without building a longer tutorial.

This change is the most resilient solution for the example. The language of the speaker doesn’t break the script and text value is the best selector. The text for that button hasn’t changed since 1998 and it’s reasonable to assume it won’t change in the future.

[nameloCmaS]

This will be fixed in a different way with acceptance of PR #1255.

[schurma]

It's been 2.5 years since I submitted that and I don't care. I tried to help but the response I got was so rude that I abandoned any idea of helping. Soon after that my company and I abandoned even using the project. It's more important to get rid of rude jerks than it is to get rid of software bugs. Especially when those jerks scare away new volunteers for your buggy crappy wreck of a project.

…

On Fri, Mar 1, 2024 at 6:04 AM nameloCmaS ***@***.***> wrote: This will be fixed in a different way with acceptance of PR #1255 <#1255>. — Reply to this email directly, view it on GitHub <#942 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPBNKRMW7IFFQK6IBAO7VTYWB4EZAVCNFSM5HWPQLWKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJXGMYTMMJWGA2A> . You are receiving this because you were mentioned.Message ID: ***@***.***>