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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev