Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using keyword with dot in name using long format (e.g. MyLib.Keyword.with.dot) fails #1771

Closed
pekkaklarck opened this issue Aug 13, 2014 · 0 comments
Assignees
Milestone

Comments

@pekkaklarck
Copy link
Member

If you have a library with a keyword with a dot in name like Keyword.with.dot using it without the library name works but prefixing it with the library name fails:

*** Settings ***
Library    MyLib

*** Test Cases ***
Example
    Keyword.with.dot    # works
    MyLib.Keyword.with.dot    # doesn't work

The reason that the latter doesn't work is that if there are dots in keyword name, possible library is always considered to be the part before the last dot. The motivation has been that you can have libraries with dots in name like org.robotframework.ExampleLibrary but dots in keyword names are very rare.

You can actually only have a dot in a keyword name when using the dynamic library interface where you can define the name yourself. Neither Python nor Java support having a dot in a method name when defining a keyword using the static library API. Because dots in keyword names are rare, and a simple workaround is avoid using them, this issue isn't too severe. Should definitely be fixed, though, because the current behavior is very inconsistent.

The problem is relatively easy to fix by splitting the given keyword name from all possible dots and testing does any library/keyword name combination work. Because string matching is blazingly in Python and keyword names used in test data typically don't even contain dots, there is no risk that this would somehow slow down execution speed.

@pekkaklarck pekkaklarck added this to the 2.8.6 milestone Aug 13, 2014
@pekkaklarck pekkaklarck self-assigned this Aug 13, 2014
pekkaklarck added a commit that referenced this issue Aug 18, 2014
The idea of this refactoring was to split keyword finding logic away
from way too long and pretty horrible `Namespace` class.  The main
motivated was to ease adding new features (e.g. #888) and fixes
(e.g. #1771) to the keyword finding logic. New `KeywordStore` is still
too closely coupled with `Namespace`, but didn't want to do much
bigger changes in a minor release.

@guykisel, any comments about the changes are appreciated. It seems to
me that the approach I used was very similar to what you have done in
your fork to implement #1771.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant