needed a Get Weblement(s) keyword

[KD1102]

Hello,

I was working on a test for selecting a date from datePicker. By mentioning simply the xpath of the webelement from the calendar, but to requirement is to select (Now+2d) add 2 days to the current day.
Right now, i have to hard code the table cells (tr and td) to select the date.
But to create a dyanmic xpath, i need to work on webelements, which is missing right in current version of Selenium2Library. For example, code implemented in Java- Webdriver,

/*DatePicker is a table.So navigate to each cell
* If a particular cell matches value 13 then select it
*/
WebElement dateWidget = driver.findElement(By.xpath("//table[@Class='ui-datepicker-calendar']"));
List columns=dateWidget.findElements(By.tagName("td"));

    for (WebElement cell: columns){  
        //Select 13th Date   
        if (cell.getText().equals("13")){  
            cell.findElement(By.linkText("13")).click();  
            break;  
        }  
    }  

I want to re-do this code in Robotframework.

Kindly help.

Regard,
Kuldeep

[ombre42]

@emanlove has proposed doing this in the forums so this functionality will probably be coming somewhat soon. In the mean time, you should be able to construct an XPath selector that will select the correct element, something similar to //table[@class='ui-datepicker-calendar']//td[.='13']/a. For help on that please post the Robot Framework user group.

[ombre42]

One option that may be worth considering is to add an argument first_only, which would control whether Get Webelements returns a single WebElement or a list of them. For example,
${elem}= Get Webelements xpath=//* True returns a single WebElement, but ${elems}= Get Webelements xpath=//* returns a list of WebElements (possibly a list of one WebElement).
This would help avoid keyword pollution by avoiding the need for a separate Get Webelement keyword.
Just a thought...

[pekkaklarck]

More generic index could be even better.

[emanlove]

Here is my implementation, as it currently stands from about a month ago. I like @pekkaklarck's idea of 'index'. Listening to your suggestion @ombre42 I was thinking we had several of these dual perform action on one and perform action on many keyword pairs. So I was thinking why not. But reviewing the keyword list I see actually very few; just Get Selected List Label/Get Selected List Labels and Get Selected List Value/Get Selected List Values. Looking at just the documentation I can't see the difference between the singular vs multiple keywords. So I see your point and agree that having only Get WebElements with possibly some sort of index/first/last filter is better.

[ombre42]

I agree @pekkaklarck 's idea is good. The difference being that with first_only (or a separate Get Webelement), returning None if no elements were found is the behavior I was thinking. With an index, it would make more sense to have the keyword fail. With XPath, one could do Wait Until Page Contains Element xpath=(//div[@name='foo'])[3] to wait for at least 3 matches before trying to fetch the 3rd element with Get Elements, so I think this is okay. Any thoughts on this?

Even though Get Element is more consistent with the other keywords, it conflicts with the XML library, so I like the idea of Get Webelements more. WebElement is what the class is actually called and the term used in the Selenium world anyways.

[ombre42]

Hmmm...after @pekkaklarck comments elsewhere I'm having some doubts about whether Get Webelements is better then Get Elements....

• Get Element Text already conflicts with a keyword in XML
• Get Element is more generic, in line with how Selenium is being used outside of HTML and HTML-based applications (e.g. native apps with Appium)
• As noted before, Get Elements is more consistent with existing keywords in this library

[pekkaklarck]

It's a good point that there are already conflicts with XML library and that also other keywords talk about Element. In this case the benefit of WebElement would be that it makes it more clear the keyword deals with exactly those Selenium objects. That can easily be explained in the documentation, though, and talking about Web would definitely be weird outside HTML context.

[ponkar]

Hello ,

This is something I was looking to iterate accross few elements to check their attributes. What is the status of this implementation. Is it pushed to the repo ?

[ombre42]

@ponkar have not heard from Ed. His last commit was at the end of August.
As a temporary workaround, you can use Execute Javascript to return elements or invoke _element_find.

[ponkar]

Ok Can any one comment if it is in development plan that anyone is working on it

[emanlove]

@ponkar, @ombre42: I have added some initial documentation changes to the Selenium2Library Introduction and section about locators. I am still working out formating and wording so any suggestions are welcome.

[ombre42]

Still analyzing, but wanted to suggest changing Get Element Attribute to support using a webelement as a locator. It would be easy to do in a backwards compatible way by adding a name argument that supersedes parsing attribute_locator for an attribute name.