Create better architecture for Selenium2Library

[aaltat]

• Remove the multi inheritance madness from the S2L
• Remove the meta classes and automatic keyword decoration by done the keywordgroup.py
• Start using the Robot Framework dynamic library API. It allows to separate keywords, public methods and private methods from each other.
• Start using context object to store the different library information. Example the store the different WebDriver instances in the context.
• Unify logging.
• Introduce Base class. Example logging could come from the Base class.
• TableElementFinder to use ctx
• ElementFinder to use ctx

[pekkaklarck]

Should the original description be moved into a task list? Some other tasks I'd like to be included:

• Clean and documented API to extend the library. Somehow being able to inject additional library components would be great.
• Clean and documented API to use functionality provided by the library externally. This basically consists of specifying the public API.

[vairamsvsjdo]

Is there a timeline for this to be completed to get to 2.0? Are you looking for contribution that can be added to accelerate this project? What way can we make this project reach 2.0 milestone?

Have the following fork as an alternative for Python 3.6+RF3.x+S2L is a stop gap solution. But would appreciate if the core library reach maturity and current support. Is trying to support 2.7 causing delay in 2.0 milestone?

Fork: https://github.com/HelioGuilherme66/robotframework-selenium2library

[vairamsvsjdo]

Why is this architecture a requirement for Python 3.x support release?

[aaltat]

1. This is a hobby for me and therefore there are no timelines.

2. For the architecture: I am not looking contributions. I don't even know how I want the architecture to work before I read the code and write it. For other stuff: Definitely yes.

3. Code reviews for the new architecture, see Selenium2Library new architecture #770, are welcomed. Also checking the FF, geckodriver and selenium compatibility and could we make 1.9.0 release to support FF before and after geckodriver would be really good thing. After the new architecture, the code has to support Python 3 and 2 and also how to make the release process more easier is needed too.

4. I don't follow what other forks do with their code base, so cannot comment on their work.

5. Generally speaking the greatest delay is the lack of time. See point one for why.

6. If looking for a code point of view, no it's not needed for Python 3 and 2 support. But it makes the Python 3 and 2 support lot easier.

[aaltat]

Because of the ElementFinder changes, it looks like the Custom Locator Strategyarguments will be changed. Need to look in to the documentation and clear things up.

[pekkaklarck]

Architecture changes ought to be now done except that registering custom locators mentioned by Tatu above still needs to be fixed.

[aaltat]

The custom locator is now fixed by #837 and the custom locator API is now unchanged.

Now the new architecture is now done and issue is closed.