Repository navigation
Create better architecture for Selenium2Library #771
Description
- 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
Activity
pekkaklarck commentedon Mar 7, 2017
Should the original description be moved into a task list? Some other tasks I'd like to be included:
vairamsvsjdo commentedon Apr 18, 2017
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 commentedon Apr 19, 2017
Why is this architecture a requirement for Python 3.x support release?
aaltat commentedon Apr 19, 2017
This is a hobby for me and therefore there are no timelines.
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.
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.
I don't follow what other forks do with their code base, so cannot comment on their work.
Generally speaking the greatest delay is the lack of time. See point one for why.
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 commentedon Jun 19, 2017
Because of the
ElementFinderchanges, it looks like theCustom Locator Strategyarguments will be changed. Need to look in to the documentation and clear things up.pekkaklarck commentedon Jun 20, 2017
Architecture changes ought to be now done except that registering custom locators mentioned by Tatu above still needs to be fixed.
aaltat commentedon Jun 22, 2017
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.