Scaffold currently uses a concept called "Components" as a way to separate out a Page Object into its class that can be called on more than one Page Object - basically mini page objects. For example, one would create a Component for the header of a website that can be called on a Page Object for a home page, a search results page, etc.
The Component concept works well for the use case of there being a singular nth of Objects on a page. However, it struggles to conceptually make sense when building an unknown nth amount of Objects on a page. A good example of this would be the inventory page on the sauce demo website: https://www.saucedemo.com/inventory.html. The representation of an inventory result can be pulled out into its own Component, but building a list of that component isn't technically supported out of the box since there's no knowledge of the index that can be used when establishing a parent locator prior to locating the element from the Component.
This concept deviates from the standard usage of what a Page Object can do, and behaves more like an Element. However, it isn't necessarily an element, either. When performing a findElement, a user is returned a singular element on a page. When performing a findElements, a user is returned nth amount of the elements on a page that match a single selector. This new concept seems to be a combination of both in that it:
Is like a Page Object - it contains an nth number of elements that represent a piece of a website
Is like an Element - it requires knowledge of the parent
In addition, requires knowledge of the index to set a parent locator
After some brainstorming, I think we can call this new concept a "Collection." Essentially, it's just mapper code that converts a list of strongly typed elements into a Component. This will require a small update to Components in that we will need to have users extend off a BaseComponent so we can get the java generic/reflection to work. We can provide access to the AutomationWait for the new base class, and anything else we feel like it should have.
I'm thinking the construction of the Collection of Components can be provided by the BasePage. Using the sauce demo inventory page as an example, we would have an InventoryPage class that has a method called getInventoryListAsItemComponent() that called the build collection method from BasePage, passing in the List<DivWebElement> for the search results.
In addition to these updates, we need to beef up the findElement() and findElements() methods in BaseWebElement to favor the constructor instance of By parentBy, By childBy. Having knowledge of the By locators through this process is going to make it considerably easier. It will also give us an opportunity to expand more upon how we're combining locators, whether that be through CSS or xpath. I think it's at this point where we need to start enforcing opinionated error messaging that informs the user the parentBy and the childBy should always be the same type - where type = all CSS or all XPATH. Ideally, all users should use CSS.
A/C
Scaffold should handle the construction of an nth amount of Components as detailed in the summary above
Scaffold should favor the constructor instances of By parentBy, By childBy
Summary
Scaffold currently uses a concept called "Components" as a way to separate out a Page Object into its class that can be called on more than one Page Object - basically mini page objects. For example, one would create a Component for the header of a website that can be called on a Page Object for a home page, a search results page, etc.
The Component concept works well for the use case of there being a singular nth of Objects on a page. However, it struggles to conceptually make sense when building an unknown nth amount of Objects on a page. A good example of this would be the inventory page on the sauce demo website: https://www.saucedemo.com/inventory.html. The representation of an inventory result can be pulled out into its own Component, but building a list of that component isn't technically supported out of the box since there's no knowledge of the index that can be used when establishing a parent locator prior to locating the element from the Component.
This concept deviates from the standard usage of what a Page Object can do, and behaves more like an Element. However, it isn't necessarily an element, either. When performing a
findElement, a user is returned a singular element on a page. When performing afindElements, a user is returned nth amount of the elements on a page that match a single selector. This new concept seems to be a combination of both in that it:After some brainstorming, I think we can call this new concept a "Collection." Essentially, it's just mapper code that converts a list of strongly typed elements into a Component. This will require a small update to Components in that we will need to have users extend off a
BaseComponentso we can get the java generic/reflection to work. We can provide access to theAutomationWaitfor the new base class, and anything else we feel like it should have.I'm thinking the construction of the Collection of Components can be provided by the
BasePage. Using the sauce demo inventory page as an example, we would have anInventoryPageclass that has a method calledgetInventoryListAsItemComponent()that called the build collection method fromBasePage, passing in theList<DivWebElement>for the search results.In addition to these updates, we need to beef up the
findElement()andfindElements()methods inBaseWebElementto favor the constructor instance ofBy parentBy, By childBy. Having knowledge of the By locators through this process is going to make it considerably easier. It will also give us an opportunity to expand more upon how we're combining locators, whether that be through CSS or xpath. I think it's at this point where we need to start enforcing opinionated error messaging that informs the user the parentBy and the childBy should always be the same type - where type = all CSS or all XPATH. Ideally, all users should use CSS.A/C
By parentBy, By childBy