Support other locator types for working with element attributes and values

[spooning]

Originally submitted to Google Code by mangaroo on 16 Oct 2011

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);

[spooning]

Originally submitted to Google Code by @yanne on 16 Oct 2011

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 |

[spooning]

Originally submitted to Google Code by mangaroo on 17 Oct 2011

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.

[spooning]

Originally submitted to Google Code by mangaroo on 17 Oct 2011

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.

[spooning]

Originally submitted to Google Code by mangaroo on 17 Oct 2011

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"

[spooning]

Originally submitted to Google Code by @pekkaklarck on 19 Oct 2011

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.

[spooning]

Originally submitted to Google Code by mangaroo on 23 Oct 2011

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 |.