Open Stack

About 10 years ago, we were promised a fully semantic version of HTML.
No more nested divs to structure your documents.  However, all we got
was a few generic, and only marginally useful elements like <footer> and
<article>.

On 2017-08-03 18:59, Ana Krivokapic wrote:
> Hi TripleO devs,
> 
> In our effort to make the TripleO UI code friendlier to automation
> testing[1], there is an open review[2] for which we seem to have some
> difficulty reaching the consensus on how best to proceed. There is already
> a discussion happening on the review itself, and I'd like to move it here,
> rather than having it in a Gerrit review.
> 
> The tricky part is around adding HTML element ids to the Nodes page. This
> page is generated by looping through the list of registered nodes and
> displaying complete information about each of them. Because of this, many
> of the elements are repeating on the page (CPU info, BIOS, power state,
> etc, for each node). We need to figure out how to make these elements easy
> for the automation testing code to access, both in terms of locating a
> single group within the page, as well as distinguishing the individual
> elements of a group from each other. There are several approaches that
> we've come up so far:
> 
> 1) Add unique IDs to all the elements. Generate unique `id` html attributes
> by including the node UUID in the value of the `id` attribute. Do this for
> both the higher level elements (divs that hold all the information about a
> single node), as well as the lower level (the ones that hold info about
> BIOS, CPU, etc). The disadvantage of this approach is cluttering the UI
> codebase with many `id` attributes that would otherwise not be needed.

While this is useful for addressing a particular element, I think it
would still require quite a bit of parsing.  You'd find yourself writing
string-splitting code all over the place.  It would make the code harder
to read without providing much semantic information --- unless of course
every single element had some kind of ID.

> 2) Add CSS classes instead of IDs. Pros for this approach: no need to
> generate the clumsy ids containing the node UUID, since the CSS classes
> don't need to be unique. Cons: we would be adding even more classes to HTML
> elements, many of which are already cluttered with many classes. Also,
> these classes would not exist anywhere in CSS or serve any other purpose.

I like this option the best.  It seems to be the most natural way of
adding semantic information to the bare-bones building blocks of the
web.  Classes are simple strings that add information about the intended
use of the element.  Using jQuery-like selectors, this can make for some
easy-to-understand code.  Do you want to grab the power state of the
currently expanded node in the list?

    $('#node-list div.node.expanded').find('.power-state')

By default, Selenium can query the DOM by id, by class name, and by
xpath.  It can be extended to use pyquery which is the Python
implementation of the jQuery css selector.  I think many of the
automation implementation headaches can be solved by using pyquery.

https://blogs.gnome.org/danni/2012/11/19/extending-selenium-with-jquery/

Furthermore, I think that classes can be used effectively when
describing transient state like the expanded/collapsed state of a
togglable element.  It's easy to implement on the client side, and it
should be helpful on the automation side.

Relying on patternfly presentational class names won't suffice.

> 3) Add custom HTML attributes. These usually start with the 'data-' prefix,
> and would not need to be unique either. Pros: avoids the problems described
> with both approaches above. Cons: AFAIU, the React framework could have
> problems with custom attributes (Jirka can probably explain this better).
> Also, casual readers of the code could be confused about the purpose of
> these attributes, since no other code present in the UI codebase is using
> them in any way.

This seems pretty drastic.  I wonder if there is a way we could extend
the React component class to give us automatic and painfree ids.

> It seems that a perfectly optimal solution does not exist here and we will
> have to compromise on some level. Let's try and figure out what the best
> course of action here is.
> 
> [1] https://blueprints.launchpad.net/tripleo/+spec/testing-ids
> [2] https://review.openstack.org/#/c/483039/
> 
> -- 
> Regards,
> Ana Krivokapic
> Senior Software Engineer
> OpenStack team
> Red Hat Inc.