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

Changes from pull request #121 #122

Open
emaks opened this issue Jun 10, 2016 · 10 comments
Open

Changes from pull request #121 #122

emaks opened this issue Jun 10, 2016 · 10 comments

Comments

@emaks
Copy link
Contributor

emaks commented Jun 10, 2016

Changes from pull request #121 have removed difference between TypifiedElement.class and HtmlElement.class. Now we can do all actions that provides selenium api using TypifiedElement.class while this class has been implemented not to provide this possibility

@ham1
Copy link
Contributor

ham1 commented Jun 10, 2016

This is correct. What do you see the disadvantages of being able to access the WebElement API with TypifiedElements? Do you know why it was different in the first place?

I found the major advantage being able to explicitly wait for it like a normal WebElement.
It also reduces code duplication, often you want to perform actions which are identical to the WebElement API and before the PR they were been passed through, without modification, to the wrapped WebElement.

@emaks
Copy link
Contributor Author

emaks commented Jun 10, 2016

Because when I use Button.class I mustn't have functionality like sendKeys(), getText() etc.

@ham1
Copy link
Contributor

ham1 commented Jun 10, 2016

Why must the functionality not be there?

Is already is there as you can still get access to the API using .getWrappedElement() - so easy to get around.

You can chose just not to use it.

Whereas, if it's not there, .getWrappedElement() has to be called or things such as explicit "wait for (in)visibility of all in" a List cannot be done without a custom ExpectedConditions.

In your example, you might want getText() on a button to check it has the expected text, also you might want to send the enter key on the button to test keyboard navigation.

@emaks
Copy link
Contributor Author

emaks commented Jun 10, 2016

Why must the functionality not be there?

because it looks like https://hsto.org/getpro/habr/post_images/9b8/71b/a0b/9b871ba0b4fe575aa9d896a6d642c55a.jpg

@lanwen
Copy link
Contributor

lanwen commented Jun 10, 2016

TypifiedElements is a architect fail. So in most cases we have more troubles than profit from using it. So its just a step to make unification of this classes

@emaks
Copy link
Contributor Author

emaks commented Jun 10, 2016

@lanwen in that case TypifiedElements have to be removed

@ham1
Copy link
Contributor

ham1 commented Jun 10, 2016

I totally agree. As well as being more 'correct' it will simplify the code base, which is always good, but what of backward compatibility?

@lanwen
Copy link
Contributor

lanwen commented Jun 10, 2016

yep, we can't just remove this class without set of small steps which are: unification - deprecation - removing.

@ham1
Copy link
Contributor

ham1 commented Oct 19, 2017

Can this be closed or are we going to look to deprecate TypifiedElements?

@artkoshelev
Copy link
Contributor

i would vote for deleting it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants