Squish provides access to Web DOM elements, giving tests the potential for complete low-level access and control. However, working at this level is the Web equivalent of using hard-coded screen coordinates when testing GUI applications—that is, it is a rather fragile approach.
To create robust test scripts, a test framework and the automated tests should interact with the application and the HTML on high-level widgets, instead of interacting with low-level DOM elements. This way tests work on an abstract GUI level without needing any knowledge of the application's internals (i.e., without needing to directly access the application's DOM).
The advantage of using high-level tests which work on widgets rather than directly on the DOM, is that the tests will not break just because the DOM representation or widget implementation changes. And such changes are quite common as applications, and the frameworks they use, evolve.
So in addition to providing low-level access, Squish also provides a way of creating high-level tests that are likely to be a lot more reliable. This is possible because Squish comes with built-in support for popular AJAX and DHTML frameworks and recognizes their widgets. But given the amount of available AJAX, DHTML, and JavaScript frameworks and custom widgets that currently exist, and also the new ones that keep appearing, it is not possible for Squish to support all of them out-of-the box.
Fortunately, even those testing a Web framework that isn't currently supported by froglogic, can still add support for their framework to Squish. This is done by using Squish's JavaScript extension API which makes it possible to extend Squish's widget support to recognize custom AJAX, DHTML, and JavaScript widgets, to identify them properly, and to interact with them, and of course to make their APIs accessible to test scripts.
In this section we will present an overview and examples that show you
how to implement support for your custom widgets yourself.
Alternatively, contact <squish@froglogic.com> if you want
froglogic to implement the extension for your custom widgets or
framework for you.
This extension is enabled by specifying the location of the JavaScript file that implements it. When Squish hooks into the Web browser, it will evaluate the JavaScript in the extension file inside the browser.
Inside the JavaScript extension file it is possible to use Squish's programming interface to hook into the object recognition, name generation, and other functionality provided by the framework. Also, by implementing certain JavaScript hook-functions, it is possible to expose the APIs of the framework's custom widgets to make them accessible to test scripts.
To specify a JavaScript extension file (and assuming for the sake of
example, that the file is called
C:\squishext\myextension.js), add a line such as
this to the squish.ini file located in your
Squish installation's etc subdirectory:
Wrappers/Web/ExtensionScripts="C:\\squishext\\myextension.js"
If you do distributed testing, this only needs to be done on the machine where squishrunner or the Squish IDE are used.
The API which can be used to implement the extensions is documented in the Squish Object (Section 16.1.9.22)—this object provides methods that support Squish's JavaScript extension. The following sections explain the object's API, and show some examples of its use.
To avoid recording superfluous mouse clicks, Squish only records
clicks on DOM elements which are known to respond to clicks. To decide
whether an element responds to clicks, Squish checks to see if the
element has a mouse event handler (such as onClick()) set,
or if the element is a known clickable widget—such as a form input
element, a links, and so on.
If your JavaScript library comes with custom clickable widgets such as
custom buttons, you can tell Squish about them using the Squish.registerWidget() JavaScript function. This
function expects a named argument list which specifies the DOM class of
the element and the type of events that should be recorded.
For example, let's assume that you have a special button implementation which is represented in the DOM as:
<span class='ajaxbutton'>Click Me</span>
To make Squish record mouse click events for this type of widget, add the following line to your extension JavaScript file:
Squish.registerWidget({Class: "ajaxbutton", Event: "click"});
Now, when you record a script and click this button, Squish will
record mouseClick() statements.
To identify widgets when replaying a test, Squish defaults to using
its own built-in name generation algorithm. In this specific example the
innerText will be used since no id or
name is set, and this is sufficient in this case. So,
the generated real name for this object will be, {tagName='SPAN'
innerText='Click Me'}
.
It is possible to supplement Squish's name generator with your own name generation algorithm—this is particularly useful if you want to make use of custom properties from a web framework's custom elements when names are generated. This is covered in the next section.
To generate a name for a widget, Squish generates a list of property
pairs identifying the object. Squish uses a set of pre-defined
properties such as tagName, id,
name, title, innerText, and a few
others.
If the properties do not uniquely identify the object, an
occurrence property is added to the name which specifies
which of the objects matching the other properties is supposed to be
selected.
With the exception of tagName—which is the one
mandatory property that all names must have—
the properties are optional and can be chosen freely.
In some cases it might be desirable to use custom properties in the names of certain types of objects. To do this, it is possible to specify your own hook function which will then be called to generate names for your own widgets. And if necessary, a hook function that performs the property matching that is done when objects are searched for can also be installed.
To show how to implement a custom name generator, we will start with an example menu element:
<SPAN class='menu' id='fileMenu'>
<SPAN class='menuItem' menuID='fileOpen'>Open</SPAN>
<SPAN class='menuItem' menuID='fileQuit'>Quit</SPAN>
</SPAN class='menu'>
First, we must register the menu items as clickable widgets using
the Squish.registerWidget() function:
Squish.registerWidget({Class: "menuItem", Event: "click"});
(We already saw an example of using this function earlier: How to set up Support for Simple Widgets (Section 15.9.2).)
In this example we are going to use the menuID attribute,
along with the DOM class, and the parent element's ID, to give our menu
elements (i.e., each menuItem <span>
tag), their unique identifying names.
var myUiExtension = new Object;
myUiExtension.nameOf = function(obj) {
if (obj.tagName == "SPAN" && Squish.hasClassName(obj, "menuItem")) {
var name = '{';
name += Squish.propertiesToName(obj, ["tagName", "menuID"]);
name += " parentID='" + obj.parentNode.id + "'";
name += " className='menuItem'";
name += "}";
return escape(Squish.uniquifyName(name, obj));
}
return undefined;
}
We have added this function as a property of a custom
myUiExtension object. In the implementation we check if the
object is an object of the type we want to handle, that is,
menuItem <span> tag. If the type is
right we use custom code to create a unique name for it; otherwise we
return undefined—this isn't a valid name value, so
Squish will try each of the other registered name generation hook
functions (if any), and if all of them return undefined (or
if there aren't any), Squish will fall back to using its own default
name generator.
To determine if the element is one of those we want to handle, we check to
see if its tag name is SPAN and if its DOM class is
menuItem. For this second check we use the Squish.hasClassName() helper function, which
returns a true value if any of the DOM object's DOM classes has the same
name as the given class name.
If the element is of the right type we create a name for it using our
own custom name generation algorithm. A name consists of one or more
property name–value pairs, all contained in braces. Here we start
by using the Squish.propertiesToName()
function to create a name string containing the given property names and
values; then we add two additional property pairs, one for the parent ID
and another for the class name. Finally, we use the Squish.uniquifyName() function to ensure that we
produce a unique name. This function accepts a real name as a string and
the object the name is supposed to identify, and will return the name
unchanged if possible, or will return it with the addition of an
occurrence property if it is necessary to distingish the
name further to ensure its uniqueness.
So, given the example shown above, if the object was the
fileOpen menu item, the
Squish.propertiesToName() function would give
us the string "tagName='span' menuID='fileOpen'", and with
the addition of the parent ID and class name, the final name we would
end up with is "{tagName='SPAN' menuID='fileOpen'
parentID='fileMenu' className='menuItem'}".
We could not use the Squish.propertiesToName() function for either the
parent ID or for the class name properties. In the case of the parent ID
this is because the parentID is not a regular property, but
rather a pseudo-property, so we must handle it ourselves. Once part of a
real name though, Squish will be able to work with it like any other
property. In the case of the class name the only reason we cannot use
the Squish.propertiesToName() function is
because the DOM property name is class while Squish uses
the JavaScript className name. Also, a DOM class may
contain multiple values while we only want to specify one—
menuItem.
At the end we make sure that any special characters are escaped
properly—for this we use the standard JavaScript
escape() function. And then we return the result.
Once our name generator function is ready, we must inform Squish of its existence so that it is used when names are needed. This is done by registering it as a hook function:
Squish.addNameOfHook(myUiExtension.nameOf);
Here we have used the Squish.addNameOfHook()
function to register the myUiExtension.nameOf() function
as a name generator function. From now on Squish will use this
function whenever it needs to generate a real name, but falling back on
any other generator function (and its own built-in default name
generator function as a last resort), if the function returns
undefined.
When searching for an object by name, Squish iterates over all objects in the DOM tree and queries the specified object properties to see if their values match those of the name.
Using a custom name matcher hook makes it possible to consider a
name's pseudo-properties (such as the parentID we saw
earlier), when searching for a matching object. Since Squish has no
knowledge about any pseudo-properties we have created, we must implement
a custom function to perform the lookup and name matching and that
accounts for our pseudo-properties.
myUiExtension.matchObject = function(obj, property, valueObject) {
if (property == "parentID")
return Squish.matchProperty(valueObject, obj.parentNode.id);
return undefined;
}
Again, we have implemented this function as a property of our custom
myUiExtension object. Squish will pass the object, the
property name and the expected value as specified in the name to this
function.
If the given property is our pseudo-property, we use Squish's built-in
Squish.matchProperty() function to determine
if there is a match. Otherwise we return undefined; in such
cases Squish will try all the other match objects that are registered
(if any), and if none of these gives a definitive true or false (or if
there aren't any), it falls back on its own internal name matching
function. Note that the valueObject is not simply a string
but rather an object which contains a string value and a flag denoting
whether the matching should be based on a literal string comparison,
wildcard matching, or regular expression matching.
(See also Improving Object Identification (Section 16.8).)
In this example we have chosen to handle the parentID
pseudo-property ourselves; and by returning undefined for
any other property we pass on the matching work to Squish for anything
other than the pseudo-property we are interested in.
The custom name matching setup is completed by installing the hook:
Squish.addMatchObjectHook(myUiExtension.matchObject);
The Squish.addMatchObjectHook() function can
be used to register as many name matching functions as we want.
Using the extension mechanism it is also possible to add dedicated support for complex widgets—that is, widgets which contain items—such as tree widgets, tables, menus, calendar controls, and other item-based widgets. (For example, trees contain nodes, tables contain cells, menus contain items, and calendars contain date cells.) We will generally refer to such complex widgets as “item views”, and will often refer to their nodes, cells, and items, simply as “items”.
To make high-level interactions with such widgets possible, user actions such as mouse clicks on cells or items, and expanding and collapsing tree nodes, must be recognized and replayed—and in a way that is independent of the underlying HTML representation. In addition, certain states and properties, such as the current selection, ought to be queryable from test scripts, to allow for robust and automatic verifications.
Using the item and item view abstractions and the necessary JavaScript hooks and APIs, Squish supports the addition of any custom item view DHTML/AJAX/JS widget so that test scripts can access the widget's and its items' states, properties and functions.
This section explains how to implement such dedicated item view support so that Squish will correctly be able to record test scripts using custom item views and accurately replay such tests. This is done by using Squish's JavaScript extension API.
We will illustrate the explanation by using an example AJAX widget—the tree control from Google's Web Toolkit (GWT). We will implement all the necessary support to properly record and replay clicks on items and item handles, to identify the tree and items independent of the DOM, and to allow querying the tree's selection.
Once the necessary hooks are implemented, calls to the clickItem() function and to the clickTreeHandle() function will be recorded
when interacting with the supported item view widget. In addition, using
the HTML_CustomItemView Class (Section 16.1.9.8) and HTML_CustomItem Class (Section 16.1.9.7) abstraction API, the test scripts
will be able to access the widget and work with its items, states, and
properties.
Before we can start implementing the necessary support, we need to look at the widget's DOM structure since our custom support will use the Web application's DOM internally to provide the abstraction and encapsulation that test scripts will rely on.
Below is a screenshot of the GWT Tree widget as it appears in a Web browser:

The DOM hierarchy that GWT uses to represent this tree widget has the following structure (with irrelevant details, and most of the data, omitted):
<DIV class="gwt-Tree">
<TABLE>
<TR>
<TD">
<IMG src="tree_open.gif"/>
</TD>
<TD>
<SPAN class="gwt-TreeItem">Beethoven</SPAN>
</TD>
</TR>
</TABLE>
<SPAN>
<DIV>
<TABLE>
<TR>
<TD>
<IMG src="tree_closed.gif"/>
</TD>
<TD>
<SPAN class="gwt-TreeItem gwt-TreeItem-selected">Concertos</SPAN>
</TD>
</TR>
</TBODY>
</TABLE>
</DIV>
<DIV>
<TABLE>
<TR>
<TD>
<IMG src="tree_closed.gif"/>
</TD>
<TD>
<SPAN class="gwt-TreeItem">Quartets</SPAN>
</TD>
</TR>
</TBODY>
</TABLE>
</DIV>
</SPAN>
...
</DIV>
So we can see that a tree widget is represented using a DIV
element with the class name of gwt-Tree. The tree itself is
contained inside this DIV element, in a TABLE.
Each tree item is held in a SPAN element that has a class
of gwt-TreeItem. The item's text is the element's inner
text, and selected items have an additional class of
gwt-TreeItem-selected.
Item handles (typically shown as + or
- symbols to indicate that the item can
be expanded or is already expanded), are represented by an
IMG element in the TD element above the
item—specifically, the item's parent's previous sibling's first
child. The IMG's src property can be used to
determine if the item is expanded (src="tree_open.gif") or
collapsed src="tree_closed.gif").
The relationship between the items (i.e., the actual tree structure),
is modeled using nested SPAN elements which contain a
set of siblings relative to their parent.
This information is sufficient for us to be able to detect a GWT Tree element, the tree's item elements, and the items' handles, in the web page's DOM structure. Armed with this knowledge we can create a high-level API that our test scripts can use to interact with a GWT Tree and its items, using Squish's uniform “item view” API.
Note that all the code used in the following subsections is taken from
the file lib/extensions/web/jshook_gwt.js.
![]() | Functions to implement in the toolkit's extension object |
|---|---|
|
The first step is to implement the JavaScript hooks for recording
high-level GUI operations on the GWT Tree. This means, if the user
clicks an item, a function call should be recorded.
Similarly, a click on a tree item's handle should be recorded as
clickItem(treeName,
itemName).
clickTreeHandle(treeName,
itemName)
To achieve this, we must implement three different hooks:
Event object hook: A function that returns the DOM element that is the source of an event.
Type of object hook: A function that returns a DOM object's high-level type name (as a string).
Name of object hook: A function that returns a DOM object's Squish object name (as a string).
Once these functions are implemented, they must be registered with Squish so that they are called by Squish's event recorder. When Squish calls them, it will pass the event's DOM source object as an argument, and based on this we can decide whether we will respond or not. (We can safely ignore events we don't want to handle and leave them to Squish to deal with.)
For the GWT Tree when we implement these functions we must handle three different high-level objects:
Tree objects
Tree items
Tree item handles
So for all three functions we need a way to determine which type of
object we are dealing with. To do this we will start by defining a
gwtExtension object to contain all the GWT Tree-related
code we write. Then we'll define some constants, and then we will create
a getType() function.
var gwtExtension = new Object; gwtExtension.Tree = 0; gwtExtension.TreeItem = 1; gwtExtension.TreeItemHandle = 2;
We will use these constants to distinguish between the objects we are interested in handling. Now we need a function that can match DOM class names to these constantts:
gwtExtension.getType = function(obj)
{
if (Squish.hasClassName(obj, 'gwt-TreeItem'))
return gwtExtension.TreeItem;
else if (obj.tagName == 'IMG' &&
(obj.src.indexOf('tree_open') != -1 || obj.src.indexOf('tree_closed') != -1) &&
Squish.hasClassName(gwttreeExtension.itemOfHandle(obj), 'gwt-TreeItem'))
return gwtExtension.TreeItemHandle;
else if (Squish.hasClassName(obj, 'gwt-Tree'))
return gwtExtension.Tree;
return undefined;
}
The custom getType() function uses Squish's Squish.hasClassName() function to see if the
element is a tree item, and if it is, the appropriate constant is
returned. Similar code is used to handle trees themselves, but for tree
handles we must check that the tag is IMG and that it has
one of the appropriate images and that the element associated with the
image is an item with the correct class (gwt-TreeItem).
We will see the creation of the gwttreeExtension object and
of the gwttreeExtension.itemOfHandle() function shortly.
If the element is not one of those we are interested in, we
return undefined which indicates to Squish that it should
try whatever type functions it hasn't yet tried, or to fall back on its
own built-in functionality.
Now that we have a suitable getType() function, it is quite
easy to implement the three hook functions that are needed:
gwtExtension.eventObject = function(obj)
{
if (!obj)
return undefined;
switch (gwtExtension.getType(obj)) {
case gwtExtension.TreeItem: // fallthrough
case gwtExtension.TreeItemHandle:
return obj;
}
return undefined;
}
If the high-level object type is a tree item or a tree item's handle, we
return this object. This tells Squish that the object is one we want
to record events on, and so should not be ignored by the event recorder.
As usual, if we don't recognize the object, we return
undefined which tells Squish to handle it for us.
If Squish encounters an object for which events should be recorded, it will need know the object's type. For this we must implement a suitable hook function:
gwtExtension.typeOf = function(obj)
{
switch (gwtExtension.getType(obj)) {
case gwtExtension.TreeItem:
return 'custom_item_gwttree';
case gwtExtension.TreeItemHandle:
return 'custom_itemhandle_gwttree';
case gwtExtension.Tree:
return 'custom_itemview_gwttree';
}
return undefined;
}
The type names returned from this function follow a convention that must be followed! Squish provides a common item view abstraction, and for it to work correctly, we must return type names of the correct form.
The three main components used by the item view API for custom trees,
and that correspond to components that the DOM object represents, are
items, handles, and views—a view is a list or table or tree
widget. The naming convention we must follow for custom type names is
very simple: Item type names must begin with custom_item_;
Item handle type names must begin with custom_itemhandle_;
and view type names must begin with custom_itemview_.
The rest of the name must identify our custom view (so in this example,
each type name ends with _gwttree).
The third hook function that we must implement returns the name of a specific high-level object:
gwtExtension.nameOf = function(obj)
{
switch (gwtExtension.getType(obj)) {
case gwtExtension.TreeItem:
return escape(gwtExtension.nameOfTreeItem(obj));
case gwtExtension.TreeItemHandle:
return escape(gwtExtension.nameOfTreeItem(gwttreeExtension.itemOfHandle(obj)));
case gwtExtension.Tree:
return Squish.uniquifyName(gwtExtension.nameOfTree(obj), obj);
}
return undefined;
}
As usual, we tell Squish to handle any objects that we are not
interested in by returning undefined.
This function makes use of two other functions,
gwtExtension.nameOfTree() and
gwtExtension.nameOfTreeItem() to create suitable real
(multi-property) names for the custom objects. Here are their
implementations:
gwtExtension.nameOfTree = function(obj)
{
return '{' + Squish.propertiesToName(obj, ["tagName", "id", "name"]) + "className='gwt-Tree'}";
}
This function creates a unique name for each GWT Tree object that Squish encounters. (See How to Implement a Custom Name Generator (Section 15.9.3.1) for more information about creating names.)
Here is the function which generates a name for a tree item:
gwtExtension.nameOfTreeItem = function(obj)
{
var tree = obj;
while (tree && (!Squish.hasClassName(tree, 'gwt-Tree')))
tree = tree.parentNode;
var treeName = Squish.nameOf(tree);
var item = obj;
return Squish.createItemName(treeName, item.innerText);
}
An item's name consists of the name of the item view containing the item (the tree widget) and the actual name of the item (usually the item's text—i.e., its innerText—is used).
First we find the tree widget that the item belongs to. This is done by
going to the item's parent, and if that isn't the tree, the parent's
parent, and so on until we get an object of class gwt-Tree.
Once we have located the tree object, we can call the Squish.nameOf() function to get its real
(multi-property) name, and then use the Squish.createItemName() function to generate a
unique real name for the item; essentially, the same name as the tree's
but with an additional property containing the item's text (which we get
from the item's innerText).
Now that we have implemented all necessary hook functions we must register them to make them take effect:
Squish.addNameOfHook(gwtExtension.nameOf); Squish.addTypeOfHook(gwtExtension.typeOf); Squish.addEventObjectHook(gwtExtension.eventObject);
With these hooks in place, if we now record events on a GWT Tree, the expected high-level operations will be correctly recorded.
![]() | Functions to implement in the view's extension object |
|---|---|
|
Once the recording hooks are implemented and recording works, the next step is to implement the hooks to enable Squish to recognize and correctly replay the recorded GUI operations.
To support replaying clicks on items (clickItem()), only one additional function
needs to be implemented. This function has to search for an item by name
in the tree, and should return a reference to the DOM object representing
the item. Squish will use this function to get the item to send click
events to.
The name of this function has to follow a certain naming convention. In
particular, it must be called
findItem() and it must exist as a
function property of an object called
typenameExtension where
typename is exactly the same name as
we appended to the type names of the objects in our
typeOf() hook function.
For the GWT Tree example we have typenames
custom_item_gwttree and so on, so the name we must use is
gwttree. This means that we have to create an object called
gwttreeExtension and give it a findItem()
function, as the following code illustrates:
var gwttreeExtension = new Object;
gwttreeExtension.findItem = function(tree, itemText)
{
var node = tree.firstChild;
while (node) {
if (node.firstChild) {
var child = gwttreeExtension.findItem(node, itemText);
if (child)
return child;
}
if (node.className &&
Squish.hasClassName(node, 'gwt-TreeItem') &&
Squish.cleanString(node.innerText) == itemText) {
return node;
}
node = node.nextSibling;
}
return undefined;
}
The tree is a reference to the tree DOM element and the
itemText is the item's text (actually its
innerText).
The function iterates through all child elements of the tree until it
finds an element of class gwt-TreeItem whose
innerText matches the requested item text.
For list and table widgets it is sufficient to provide a
findItem() function, but for tree widgets an additional
function is required to deal with item handles.
For this purpose an itemHandle() function must be
implemented in the same object that returns the handle belonging to the
given item. Here is an implementation of the function that works for GWT
Tree items:
gwttreeExtension.itemHandle = function(node)
{
return node.parentNode.previousSibling.firstChild;
}
This function returns the GWT Tree element that corresponds to an item
handle (an IMG element in the TD element above
the item—i.e., the item's parent's previous sibling's first
child.)
The implementation of these two functions is all that's needed to enable the replaying of high-level operations on items and item handles.
![]() | Functions to implement in the view's extension object |
|---|---|
|
For Squish to be able to detect an item view and its items, and be able to record and replay high-level GUI operations involving them, what we have done so far is sufficient.
But Squish's item view abstraction also provides the tester with APIs to iterate through the items and to query and set the selection and other properties. To support such functionality, various additional functions need to be implemented—all of which we will cover here, again providing examples based on the GWT Tree example.
Squish's test script item-view API allows us to retrieve a tree item
(using tree.findItem(...)), and to query the item's
text property.
By default, Squish returns the item's innerText, but if
this is inappropriate for the items you are working with you can
implement your own itemText(item) function in the view's
extension object, and which will then be called instead of Squish's
default function for your items:
gwttreeExtension.itemText = function(item)
{
return item.innerText;
}
If the typenameExtension has an
itemText() function property, Squish will call this
function and pass a reference to the DOM object representing the
relevant item. This principle applies to the other functions too: if we
provide the function it is used for our extension types; otherwise
Squish falls back to its own built-in functionality.
In this particular case (i.e., for GWT Tree items) there is no need to
implement this function because Squish's built-in version returns the
innerText anyway.
Squish's test script item-view API allows us to retrieve a tree item
(using tree.findItem(...)), and to query the item's
selected property.
To support the querying of an item's selection state, we must provide an
isItemSelected() function in the
view's extension object. Here is an example that works for GWT Trees:
gwttreeExtension.isItemSelected = function(item)
{
return Squish.hasClassName(item, "gwt-TreeItem-selected");
}
If the typenameExtension has an
isItemSelected() function property, Squish will call this
function and pass a reference to the DOM object representing the
relevant item.
To check if the item is selected we simply return true or
false depending on whehter one of the item's class names is
gwt-TreeItem-selected.
Squish's item-view API also supports the changing of an item's
selection state. This can be achieved by implementing a
setItemSelected(item, selected) function in the same
extension object. The item is a reference to the item's DOM
object and selected is a Boolean value, with
true meaning that the item should be selected and
false meaning that it should be unselected.
Squish's test script item-view API allows us to access a tree item's
handle and query it to see if the item is expanded (its children are
visible) or collapsed (its children are hidden). The handle's state is
held in the opened property, and to support this property
we must implement an isItemOpened() function in the tree's
extension object. (Note that this functionality doesn't make sense for
list or table views.)
Here is an example implementation for the GWT Tree:
gwttreeExtension.isItemOpen = function(item)
{
return gwttreeExtension.itemHandle(item).src.indexOf('tree_open') != -1;
}
If the typenameExtension has an
isItemOpen() function property, Squish will call this
function and pass a reference to the DOM object representing the
relevant item.
Here, we simply retrieve the item's handle and return a Boolean that reflects whether it has the opened image.
Squish's item-view API also supports the changing of an item's
expanded/collapsed state. This can be achieved by implementing a
setItemOpen(item, expand) function in the same extension
object. The item is a reference to the item's DOM object
and expand is a Boolean value, with true
meaning that the item should be expanded (opened) and false
meaning that it should be collapsed (closed).
The item view API also includes functions for traversing items in a tree
view. The traveral functions are: childItem(treeOrItem),
nextSibling(item), and parentItem(item). There
is also an itemView(item) function; this returns the view
that the given item is in.
Using these APIs it is possible to iterate over the items in a tree, and using the functions shown earlier, it is then possible to retrieve items' texts, select or unselect items, or expand or collapse items.
If we want our custom view to provide traversal then we must implement
our own versions of these four functions as properties of our custom
view's extension object. And, just the same as for the functions we have
already discussed, if we create our own versions of these functions,
Squish will call them and pass a reference to the DOM object
representing the relevant item. Note that exceptionally, in the case of
the childItem() function, Squish might call it with
either a tree or an item.
Here are implementations of these function for the GWT tree:
gwttreeExtension.childItem = function(node)
{
if (Squish.hasClassName(node, "gwt-Tree")) {
return Squish.getElementByClassName(node, 'gwt-TreeItem', 'SPAN');
} else {
while (node && node.tagName != 'TABLE')
node = node.parentNode;
if (!node || !node.nextSibling)
return undefined;
node = node.nextSibling;
return Squish.getElementByClassName(node, 'gwt-TreeItem', 'SPAN');
}
}
gwttreeExtension.nextSibling = function(node)
{
while (node && node.tagName != 'DIV')
node = node.parentNode;
if (!node || !node.nextSibling)
return undefined;
node = node.nextSibling;
return Squish.getElementByClassName(node, 'gwt-TreeItem', 'SPAN');
}
gwttreeExtension.parentItem = function(node)
{
while (node && node.tagName != 'DIV')
node = node.parentNode;
if (!node || !node.parentNode || !node.parentNode.previousSibling)
return undefined;
node = node.parentNode.previousSibling;
return Squish.getElementByClassName(node, 'gwt-TreeItem', 'SPAN');
}
gwttreeExtension.itemView = function(node)
{
while (node && !Squish.hasClassName(node, 'gwt-Tree'))
node = node.parentNode;
return node;
}
The implementations are quite self-explanatory, especially if you look at the DOM structure that the GWT Tree uses.
If the item view supports multiple columns, the functions
columnCaption(view, column) and
numColumns(view) can be implemented in the view's extension
object to allow the test script to query the column information using
the API calls with the same names through the item view API.