SeleniumHQ / selenium-google-code-issue-archive

Archive, please see main selenium repo
https://github.com/seleniumhq/selenium
346 stars 194 forks source link

Selenium with WebDriver - extensibility of classes #3495

Open lukeis opened 8 years ago

lukeis commented 8 years ago

Originally reported on Google Code with ID 3495

Hi,

we use Selenium RC for a while and we plan to migrate to the new Selenium with the
WebDriver API. Also, we plan to use the Page Object paradigm in writing our tests.
We decided to use the PageFactory to create the "pages" and doing initialization with
the FindBy annotation.
For finding some of the web elements we need to use our internal language translation
service, thus, we decided to create our own FindBy annotation and to use it where it
is needed instead of the existent one. For this, we extended PageFactory and DefaultFieldDecorator.
We also wanted to extend the classes DefaultElementLocatorFactory, DefaultElementLocator
and Annotations, but unfortunatly we were facing problems: in the case of the Annotations
class, the member field is private, it is needed by the constructor and has no getter.
DefaultElementLocatorFactory's searchContext is also private, without a getter/setter.
I would like to ask why are these constraints? What is the reason the classes are so
hard to extend? What could we do if we want to avoid the copy + paste pattern?

Thanks,
Zolta.

Reported by zzolta on 2012-03-05 14:06:45

lukeis commented 8 years ago

Reported by barancev on 2012-05-11 05:47:00

lukeis commented 8 years ago
I have the same problem. The approach in writing own software where you control everything
or a framework that is used by others is totally different.

final field and constructor doing a lot of things is not something you want in a framework.

These simple rules makes a huge differences:
- nothing private, but protected
- no final
- very low use of hardcoded concrete class, instead use method factory (that can be
overriden)

I could add new annotations supporting Ext JS and relative find bad on a root WebElement
way more cleaner if the framework was open. If I ever publish my work, I will make
sure I mention that the twisted code is due to poor design of the core framework.

Reported by sebtardif on 2012-08-07 20:47:17

lukeis commented 8 years ago

Reported by luke.semerau on 2015-09-17 17:44:48