add argument for get_list_items

[qitaos]

1. the keyword get_list_items docstring wrote "Returns the values in the select list identified by locator.", but it returns the labels. So fix the docstring to "Returns the labels in the select list identified by locator."
2. add the keyword get_list_values. It will "Returns the values in the select list identified by locator.".

[aaltat]

Thank you from the PR.

Could you raise an issue about this, so that it makes the tracking the problem easier for maintainers. Also showing some examples which demonstrates the problem, would be really nice. Because I do not recall this type of problem. but I must say that I do not recall when was the last time I did use the keyword either.

When we have are sure that we have a problem and what the problem actually is, we can think a solution for it.

[qitaos]

@aaltat I rase an issue #722 about this. Thank you.

[aaltat]

Looks OK from mobile screen but have to take closer look from bigger screen.

[aaltat]

Code look OK also from big screen. But there is some documentation enhancements that should be done. Also some nit picking on test location.

[aaltat]

We usually say Example: and not Sample:

[qitaos]

Fixed it

[aaltat]

It would be good to explain what the label argument actually does in the documentation.

[aaltat]

Perhaps it would be good to place the test before the Get Selected List Value, then the test related to same keyword are in same location.

[qitaos]

Fixed it

[aaltat]

And you can add your name to the BUILD.rst file if you want.

[pekkaklarck]

This will be true if someone executes this keyword like label=False. A workaround is using label=${FALSE} (as shown in the docs), but that's ugly. RF itself handles these cases so that strings false and no, case-insensitively, are considered false. Was there @aaltat already an issue about handling Boolean arguments consistently within the library and, preferably, same way as Robot handles them? If there is, perhaps this could just be added there as one place to fix later.

Alternatively the signature could be changed to value=False. They you'd basically never wanted to pass explicit false value and using value=True on Robot would work.

[aaltat]

I like the later idea better at least in this PR

[qitaos]

I have changed to label=False, but it is true. maybe should fix the issue about handling Boolean arguments first.

[aaltat]

I think you did miss understood. Instead of using label=True argument (in line 11) we would like to use instead value=False argument. And then lines 25 - 26 would look like:

if value: return self._get_values_for_options(options) else: return self._get_labels_for_options(options) 

And this would solve the problem explained by @pekkaklarck. I would like to keywords work in same manner that users would not have think that in keyword X string False is actually true and in keyword Y string False is actually false. It could lead in confusing situations for the user point of view.

As for now, it is OK like this:

| Get List Items | xpath=//table | value=${FALSE} | # Returns labels | | Get List Items | xpath=//table | value=FALSE | # Returns values | 

[aaltat]

Did try to clarify in what way the PR should be changed.

Also my previous comments are not yet fixed.

[aaltat]

I think you did miss understood. Instead of using label=True argument (in line 11) we would like to use instead value=False argument. And then lines 25 - 26 would look like:

if value: return self._get_values_for_options(options) else: return self._get_labels_for_options(options) 

And this would solve the problem explained by @pekkaklarck. I would like to keywords work in same manner that users would not have think that in keyword X string False is actually true and in keyword Y string False is actually false. It could lead in confusing situations for the user point of view.

As for now, it is OK like this:

| Get List Items | xpath=//table | value=${FALSE} | # Returns labels | | Get List Items | xpath=//table | value=FALSE | # Returns values | 

[qitaos]

I got it. @aaltat