Here is a another example of a custom Element similar in concept to the one used in but this is a number. Only this time it deals with something far more devious; the search box with a disappearing default string that was mentioned in even framework opinions should be weakly held.

The actual implementation of this looked something like this in terms of the html.

<pre lang="html"><div class="searchInput">
   <div class="defaultText" id="headerSearchInputDefault" style="display: none">Search for Stuffs!</div>
   <input class="searchParam" id="headerSearchParam" maxlength="100" size="25" type="text" value="flying evil monkies"></input>
</div>

or

<pre lang="html"><div class="searchInput">
   <div class="defaultText" id="headerSearchInputDefault">Search for Stuffs!</div>
   <input class="searchParam" id="headerSearchParam" maxlength="100" size="25" type="text" value=""></input>
</div>

where the content of the headerSearchInputDefault div would be put into the search box if it wasn’t in focus or the mouse wasn’t over it through some JS wizardry. This means of course that the content of that box can be expressed through two possible locators. And because one is just raw text and the other is stored in the value attribute there are two ways to retrieve the content. A quandary I solved like this.

<pre lang="python">def __get__(self, obj, cls=None):
    se = wrapper().connection
    if se.is_visible(locators["footer_default_search_text"]):
        return se.get_text(locators["footer_default_search_text"])
    return se.get_value(self.locator)

Were I to have created two elements for this situation I would have had to start doing comparisons like if the default text is visible and the value of the search box is foo then assert then do something else… or similar. This way all the logic around the state of things is buried in the Page Object and doesn’t leak into the script. Which is exactly where it should be.