search

site-prism / site_prism

BSD 3-Clause "New" or "Revised" License
318 stars 40 forks source link

Custom Elements #18

Closed ngan closed 5 years ago

ngan commented 5 years ago

This is more of a question than an issue. We have “elements” on the page that require more sophisticated set of actions to interact with the element beyond the set of public API methods on capybara’s Element. For example our “masked text died” requires passing in an option to set or in we have a date picker that needs some trickery to be able to set its value. I’d like to subclass Element and wrap those concepts up. It would be cool if this gem can have a declaration to load those classes instead of the normal Element. If that’s out of this gems control then perhaps a convention of a “Element Wrapper” would work:

element :foo, “#some-I’d”, wrapper: SpecialTextField

Where the wrapper just takes in the capybara element on initialization and proxies calls to the element. Within the wrapper, you can define methods that are special to your weird element.

ngan commented 5 years ago

Hm, I suppose Section does the job of wrapping a complex element. Is this the recommended path?

luke-hill commented 5 years ago

so the idea behind SitePrism is you declare portions of your page inside a Section

your portion could be incredibly tiny, so in pseudo code you could have

section = DatePicker elements = each date number elements = only odd numbers elements = every sunday element = currently highlighted date elements = invalid dates (greyed out)

if you attach an SSCCE with something that isn't possible at the moment then let me know. Or raise a PR if that's easier? I'm convinced you should be fine though

ngan commented 5 years ago

Yea sections is the way to go. The name “Section” just threw me off. Maybe “Component” might be better? Anyways consider this resolved.

ngan commented 5 years ago

Any thoughts on renaming "Section" to "Component"?

luke-hill commented 5 years ago

so Section is named because according to the POM definition that is what is used across the board.

There is some reading you can do here: https://martinfowler.com/bliki/PageObject.html (Java theory but good tutor) A recent medium post here: https://medium.com/tech-tajawal/page-object-model-pom-design-pattern-f9588630800b

It won't be renamed as it is correct as is. Also renaming it would lead to a heap of confusion and would be a backwards facing rear end change. It is very self-descriptive and seems to be the generic use case across the board.

Can I ask where the issue is coming from?