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

Elements need support for being enabled or disabled #129

Open
PanoramicPanda opened this issue Oct 24, 2018 · 3 comments
Open

Elements need support for being enabled or disabled #129

PanoramicPanda opened this issue Oct 24, 2018 · 3 comments

Comments

@PanoramicPanda
Copy link
Member

No description provided.

@PanoramicPanda
Copy link
Member Author

💡 Had a moment of clarity on this today.

We've discussed the methods and functionality before, and really only boiled down to finding out a good naming convention for them. I had an apostrophe today and thought of the following:

element.interactive? # Looks at the @interactive property of the element according to Oz
element.interactive_when(Boolean) # Much like activate_if, toggles interactivity according to Oz
element.enabled? # Like present?, calls watir_element.enabled?

@greenarrowdb @Castone22 Thoughts? Concerns?

@Castone22
Copy link
Contributor

I'm not really sure we should expose two differing verbages here, shouldn't #.interactable? Encapsulate the enabled test?

@PanoramicPanda
Copy link
Member Author

If you look at the current setup, we have .active? which only returns what oz thinks it should be, that is the @active property.

When we run validation, we check if active == present?.

enabled? is just a way to keep the same verbage, since present? also checks the watir element.

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

2 participants