Support other locator types for working with element attributes and values

[GoogleCodeExporter]

Haven't checked in detail, but looks like SeleniumLibrary uses the default 
Selenium RC methods to work with attributes? Which would be using XPath.

If other non-XPath locators are supported, disregard this request. Otherwise...

There is a way to work with attributes w/o XPath, to support CSS locators and 
by name/ID, if you use code similar to this PHP code snippet, where $this is 
selenium object and . is also a string concatenator:

if($attribute=="class")
            return $this->getEval("this.browserbot.findElement(\"".$element."\").className");
        else
            return $this->getEval("this.browserbot.findElement(\"".$element."\").".$attribute);

Original issue reported on code.google.com by manga...@gmail.com on 17 Oct 2011 at 2:57

[GoogleCodeExporter]

We support all the locating strategies that Selenium itself supports. So, all 
keywords that take a locator can be used with CSS selectors like this:

| Page Should Contain Element | css=table.id td |

Original comment by janne.t....@gmail.com on 17 Oct 2011 at 5:35

• Changed state: Invalid

[GoogleCodeExporter]

Well, does it work with something like these for example:

| Get Element Attribute | css=table.id1 td@name |
| Get Element Attribute | id=imgId@src |

the above based on the library documentation that the input is attribute 
locator in the format of "locator@attribute". Attribute related keywords are 
the only affected ones with this request. Janne's provided example does not 
exercise element attributes so is not a good example.

The default get_attribute method from Selenium I believe was designed to handle 
only XPath locators because that was the only type that allowed specifying an 
attribute directly. CSS locators might be a partial exception, but I don't 
recall how you specify an attribute with a CSS locator.

And element values are simply one type of attribute, so they apply as well.

I have a hunch the above examples don't work. If they do, nevermind.

Also, I realize such an enhancement might break backward compatibility of 
existing keywords. Fix could be to allow both argument methods, with 
attributate name being optional, if not specified keyword will look for 
attribute within locator as it does now (locator@attributeName), otherwise, if 
specified, will look for them as separate arguments one for locator, and one 
for attribute name.

Please reopen this as a valid enhancement after you review whether you can 
actually specify an attribute with a non-XPath locator with SeleniumLibrary 
using Get Element Attribute keyword (for example).

I know for a fact that the code snippet will work for CSS locators, and should 
work for id/name locators as well.

This issue request will help with issue 211 as well.

Original comment by manga...@gmail.com on 17 Oct 2011 at 4:25

[GoogleCodeExporter]

by the way, I did forget to assign return value of Get Element Attribute to a 
variable in my examples, but that doesn't matter for this discussion.

Original comment by manga...@gmail.com on 17 Oct 2011 at 4:26

[GoogleCodeExporter]

FYI, proposed change to the interface of the library, as suggested by issue 211 
is:

| ${var}= |Get Element Attribute | locator | attribute name |

and with backwards compatibility 

| ${var}= |Get Element Attribute | locator@attributeName |

and where we perhaps now support locator@attributeName like "id=myId@src" and 
"css=image#myId@src" rather than the old "xpath=//image[@id=myId]/@src"

Original comment by manga...@gmail.com on 17 Oct 2011 at 4:39

[GoogleCodeExporter]

1) You wrote: "I have a hunch the above examples don't work. If they do, 
nevermind." Could you please test that? Until we know that discussing this 
further makes no sense.

2) Currently all that `Get Element Attribute` keyword does is this:

    return self._selenium.get_attribute(attribute_locator)

What locators are supported is thus totally dependent on what Selenium 
supports. I don't know how we even could add support for additional locators.

3) We cannot make any larger backwards incompatible changes without first 
deprecating the old behavior.

3) Adding support for `|Get Element Attribute | locator | attribute name |` 
would be pretty trivial and wouldn't cause backwards compatibility problems. 
Please submit a separate issue about that if you think that would be useful.

Original comment by pekka.klarck on 19 Oct 2011 at 10:13

[GoogleCodeExporter]

I stand corrected, my misunderstanding of how Selenium worked. Getting 
attributes works for any locator type, whether in Selenium RC or 
SeleniumLibrary. 

I will submit separate request for item `|Get Element Attribute | locator | 
attribute name |`.

Original comment by manga...@gmail.com on 24 Oct 2011 at 3:47