If a button is optionally shown on a page (or part of page), does it qualify that part to be represented as two different PageObjects, where one PageObject provides methods to interact with the button while other PageObject does not? Or, should it be one page with a method which can throw an exception when the Button is not rendered.
What will be a maintainable solution - because in future releases the button may start appearing in both cases or the functionality may totally change.
In this case
the button may start appearing in both cases or the functionality may totally change
possible solution can be - Transporter design pattern. It's basically - navigation that aggregates reused page objects in one external object. Also centralizes the navigation control in the tested system according to the test requirements. This object encapsulates logic associated with the implementation of navigation within the tested system. Thus the problem of business logic does not interfere with the navigation within the system.
I think that Composite Page Object is acceptable and
maintainable solution
in both cases. Since It will allow you to structure your Page objects in a more “object-oriented” way by separating sub objects that can be reused on different pages and include them into the parent object. Consider this example:
Further reading about GUI automation patterns.
Related
I'm adding accessibility to my project and I have a basic vuetify data table, just like this example, but I can't find a way to make the checkboxes accessible using the tab key on the keyboard, Is there any way to do this? I know there's something called 'tabIndex' and I've used it before, but I don't know how to use it here. Can you guys help me or guide me on how to do it? Thanks!
It is very difficult to impossible to “add accessibility” at the end of a project.
Getting keyboard navigation and aria attributes right in 3rd party components is nearly impossible. You’d need to apply plenty of hacks or bind deeply into the component’s DOM, which breaks once the library gets updated.
With Vuetify you chose a library that has accessibility on top of their list, but unfortunately the data table with checkboxes cannot be used by keyboard at all, and is lacking plenty of other ARIA attributes. They don’t seem to keep up to that promise for that component.
As with any 3rd party library, if you find an issue, you should try to report a bug upstream and fix it together with their developers.
Correct behaviour of data grids
The expected behaviour of tables in web applications is that of a Data Grid.
A data grid is a composite UI component, so it’s expected that the whole component receives focus only once by means of Tab. Then, you’d navigate with arrow keys inside the table, using Space to select rows or Enter to interact with a cell.
See Keyboard Navigation Inside Components
You can try keyboard navigation in AG-Grid
The pattern to apply in code would be a roving tab index:
Only one child element of the table has tabindex="0", while all others have tabindex="-1". Key bindings then will move the 0 around in the component.
So this is quite some effort to implement.
Simple Alternative
As far as I known, it is acceptable—sometimes even expected—by concerned users, for web applications to behave more like websites, where everything is focussed by means of Tab.
This might be ok if the only possible interaction in your table is to select checkboxes, and if you provide possibilities to Bypass Blocks by offering landmarks or headlines. You should test it with some screen reader users.
For this to work, you would indeed only need to add tabindex="0" to the checkbox.
Then, again, the checkbox does not expose any other accessibility information, it’s an ignorant <div>. It should at least be:
<div role="checkbox" aria-label="Select row 5" aria-checked="false" tabindex="0">
See the Checkbox Pattern
All this might be possible, see Vuetify Accessibility (a11y)
Other Accessibility Criteria
Right now, you mention keyboard navigation. This is a great place to start with, since it is the foundation necessary for most assistive technology.
The Web Content Accessibility Guidelines (WCAG) are the reference to look for if you want to achieve compliance. Level AA (including level A) is the one recommended as a baseline.
But be aware that keyboard navigation is only one of 13 guidelines. Exposing state (checked, selected) to assistive technology, or getting contrasts right are examples for other criteria.
For web applications, it’s a good approach to advance the improvements based on critical paths in the story map, similar to an MVP, meaning that you would advance per process/task and make sure that each step in that process is accessible to the audience you prioritised based on the nature of the application.
Usability testing with people with disabilities is also a very good approach that can be applied in parallel, which centres the initiative more on the actual use cases.
I have an elm app designed with the Elm Architecture in mind. I've used it for all the samples in the tutorial and they work fine. I have the following components
ContainerListView
ContainerView
AddressView
RegistrationView
...
The ContainerView component is a very formatted div structure that is used to contain other views (but for now, only 1 at a time)
ContainerListView can contain multiple containerViews. It handles their presentation and positioning. You can think of it as an MDI surface
A menu from the main ui is used to add new container views to the container view list.
I'm presented with with three main questions. Two of them are
How do I create the components such that Container view can contain any other element is I pass in for example the init, update, and view functions and expect all things to be wired correctly? At the moment, the samle views I have are kinda hard-coded. They know exactly who the children is.
Some of the components require access to things like url, access token, etc. Does this always have to be passed in from main to the individual components or it can come from another source which will essentially be readonly and maybe updatable only from main?
I'm not sure if these two should be individual questions on their own. Any information on how to architect larger apps beyound hello world will also be appreciated.
I'm working on something similar! Nested controls. I too have a container object which knows about all the types that it can handle, and has basically case statements to handle each type. So I can't drop in a new control type and expect it to handle it, that requires altering the container.
As far as I know elm doesn't have type classes, which would be how I might try to handle that kind of abstraction in haskell or purescript. There's more about that here:
https://github.com/elm-lang/elm-compiler/issues/38
and here:
https://github.com/elm-lang/elm-compiler/issues/1039
The upshot appears to be that they don't know how they want to solve that problem yet, so they haven't.
I have a listener that is called when a tab is activated.
, listeners: {
activate: function(tab){
var first = tab.down('input'), // will be null
firstEl = tab.getEl().down('input'); // will contain first input element
I'm not having a lot of luck understanding the relationship between tab and tab.getEl(). If this was jquery, $(tab) would give me a jquery element which would largely expand on my set of options. extjs seems to be almost backwards in this regards, or at least more complicated.
I'm trying to understand when and why I need getEl() so that it is less of a development crapshoot about what will and won't work. In other places I do things like:
showFieldHelpOnBlur = function(ctrl) {
ctrl.up('form').down('#helptext').update("");
}
without the getEl(). In this case form is an element tag just like input (above), but I don't need the getEl() before I use it. In general the two sets of functionality that share the same names but don't work the same are frustrating, and the docs don't seem to give any clue as to why there are multiple methods with the same names that do different things, or do similar things in a different way.
Found some similar issues with focus(), but those might make more sense if I just understood why are there are 2 seemingly parallel sets of methods for what are essentially DOM elements wrapped in additional functionality.
I think at the core of your confusion is how you approach the development using ExtJS vs JQuery.
JQuery is all about DOM manipulation and low level API. ExtJS approach is very different, it wants you to think of your page structure as a hierarchy of ExtJS components that are responsible for rendering appropriate HTML. So ExtJS is essentially saying: "Don't worry about html, we'll take care of it - you focus on the larger components, layouts, events, etc. "
You will say "Whoa Nelly! What do you mean don't worry about html? I want control!" And ExtJS will respond OK - we have a wrapper object called Element (http://docs.sencha.com/extjs/4.1.3/#!/api/Ext.dom.Element) you can use it to do DOM manipulation just like you are used to with JQuery .. but be cautious. Because if you manage your own HTML we can't be responsible for what happens to your layouts and components that are not managed by the framework.
My advice is this - when in Rome do like Romans do :)
If you are going to be using ExtJS to build apps - embrace the way ExtJS is designed to work. Learn the different layout mechanics and numerous component types available to you out of the box. Use the MVC development pattern to beautifully organize your code. Use the examples to your advantage. Study the architecture and component guides - these are very useful. Understanding ComponentQuery class is a must (all those up/down methods and query).
At the end, when you have gained comfort using ExtJS components and their style of development you will be very efficient at building your UI compositions and can build much more complex applications than before.
Good Luck!
Pro Tip: Do yourself a favor and get Illuminations for Developers plugin for Firebug - it will open your eyes to see things using component structure rather than HTML elements.
Those are three concepts on Yii that I really don't get what should we use, on what scenarios?
Can anyone be kind enough to clarify those Yii elements, and on what situation should we use them?
In documentation of CForm one can read the following:
...we can divide a form
in two parts: those that specify each individual form inputs, and
those that decorate the form inputs. A CForm object represents the former part...
...and CActiveForm represents the latter.
In other words, CForm specifies elements of the form but CActiveForm (being a widget) renders it.
Looking at the source code we state that CForm can also render() itself and its rendering relies on and is wrapped by CActiveForm widget by introducing its configuration property activeForm, though rendering input elements and buttons is implemented by its own methods renderElements() and renderButtons() relatively. By default their implementations rely on classes using CHtml's static methods what is exactly the same (or almost exactly the same) what CActiveForm's rendering methods do. Of course, default behavior can be overriden by extending the class.
That's why it's the question of a taste which technique to use: CActiveForm widget alone combining form fields' and buttons' declaration with their representation in a view file by calling convenient (required) methods of CActiveForm instance or CForm class declaring form's input specifications in a separate configuration file and customizing its rendering by pointing at appropriate active form widget and/or by overriding default rendering methods. The latter technique allows to reuse a form in several actions easily and is no more than using form builder.
Check here for live examples of ActiveForm, CForm, et cetera. You can also see the live Model, View & Controller files.
Observe the following classes and their containment:
Section has an ItemList which has many Items
But lets say an Item is rendered a different color based on some complicated algorithm that is based off the Section.name it is contained in.
What's the proper/best way to go about abstracting this functionality? Is there a common design pattern that occurs in situations like these? Or is the inherent design flawed?
You should separate your data structures/models from your logic and processing of them. That said, I would make your Item have a Section reference on it referencing it's Section, when you add an Item to the ItemList, ensure the add method looks at the ItemLists Section (parent) and sets the reference on the Item. Same goes for the setter on the ItemList in the Section, it would have to iterate each Item and set the Section.
Alternatively, you could make the Section set on the getter of the ItemList as lazy semantics, that would be entirely up to you depending on the use of your Section the performance statistics would be different between these two approaches.
Further, I would write some form of renderer that took an Item and knew how to render it which would look at the Section on the Item and the Name on that Section.
You may want to render an entire section, but I would write that renderer separate and it would use the ItemRenderer to render each Item.
As an aside, you may want to use a form of IObservableCollection and have the Item implement INotifyPropertyChanged as well so that you could then maintain synchrony both between the rendered version and the item, and synchronize the Item with the Section it exists in by an event registration that updates the Section property appropriately.
What does the rendering? If it's something in Section, or outside of all of these, but accessing the Items from the Section, then there's nothing more needed.
If it's in Item, then you just need to make sure Item knows what Section it belongs to, or can obtain it (e.g. by having an ID it can look up on - useful with languages that make dealing with circular references tricky, but not needless hassle otherwise).
Since the first case causes no difficulty, it's clearly to be preferred over the second, so the closest to a design-pattern is that if you find yourself doing this sort of work in the contained item, to try and move it up to the container, or outside of them all. Beyond that, there isn't much of a problem to need solving.
I would build an ItemRenderer class that knows the algorithm, and pass in the references to each Item you would like to render and the Section it was contained in.
It may also make sense to let each Item know the section it belongs to, but I would still let the ItemRenderer handle the rendering.