A hierarchical tree of all the widgets on the page, where each widget is listed only by its name (e.g. just option0 instead of page.childred.tab.children.option0).

This query provides an exact representation of the widget tree of the page, with the page widget (the root widget) as the top level item in the tree list. Progressively open up the various levels of the tree list to dig into the structure of the page's widget tree, or use the expand all action to lay bare the entire contents of the tree.

A flat list of all the widgets on the page, where each widget is listed with a fully qualified dereferencing path (e.g. page.childred.tab.children.option0).

This query is useful if you want to get a report listing all the widgets on the page, with their full dereferencing paths. Use the as report action to get the entire list of widget paths in a pop-up window, from where you can copy it to your clipboard and paste it into an e-mail, an implementation notes document, or wherever. Widget paths can then later be copied from that e-mail or document and pasted back into the object entry input in order to inspect the widget again (you must be back inspecting the same page, of course).

A two level tree of all the widgets on the page, grouped by widget class, where the top level is the widget classes, and where the items under each widget class is a list of all the instances of that widget class on the page.

Widget classes are sorted in order of the number of instances created, from those classes with the most instances created, to those with the least instances created. For classes with the same number of instances created, the classes are subsorted by name. The number of instances of a widget class created is indicated in parentheses after the widget class' name. Widget classes are listed with full dereferencing paths (e.g. Uize.Widget.Page), and widget instances are listed under each class with fully qualified dereferencing paths (e.g. page.childred.tab.children.option0).

This query is useful to get a quick glance at the prevalence of different widget classes in the widget tree. This information might be helpful when deciding what widget classes should be optimized for performance, or which classes should be more rigorously tested and/or code reviewed.

A flat list of all the widgets on the page that are in the disabled state, where each widget is listed with a fully qualified dereferencing path (e.g. page.childred.tab.children.option0).

Disabled widgets are widgets where the value of the enabledInherited state property is false. This property will be false if the widget's enabled state property is set to false, or if its enabled property is set to 'inherit' and the disabled state is inherited from its parent. It might be interesting to see just how many widgets on a page are in the disabled state at any one time in the use of the page.

A flat list of all the widgets on the page that are not yet wired, where each widget is listed with a fully qualified dereferencing path (e.g. page.childred.tab.children.option0).

Any widgets that are not yet wired after the page widget has already been wired may be an indication of something important. It may be by design that some widgets create child widgets and don't immediately wire them up, or unwire them later for certain reasons. It is, however, not a common implementation choice, so lots of unwired widgets may be an indication of some issue, or an explanation for why some part of a page's UI is not functioning as expected.

A flat list of all the widgets on the page that are wired and that are missing some accessed DOM nodes, where each widget is listed with a fully qualified dereferencing path (e.g. page.childred.tab.children.option0).

This query may be useful in troubleshooting situations where a widget is not functioning as expected. For a more in-depth discussion, consult the section Issues With Missing DOM Nodes.

A flat list of all the widgets on the page that are wired and that are missing all accessed DOM nodes, where each widget is listed with a fully qualified dereferencing path (e.g. page.childred.tab.children.option0).

This query may be useful in troubleshooting situations where a widget is not functioning as expected. For a more in-depth discussion, consult the section Issues With Missing DOM Nodes. Widgets that are missing all DOM nodes are also considered to be missing some DOM nodes, so such widgets will also be listed in the results set for the Wired widgets that are missing some DOM nodes query.

A flat list of all the widgets on the page for which localized strings have been specified, where each widget is listed with a fully qualified dereferencing path (e.g. page.childred.tab.children.option0).

This query is useful when doing internationalization and localization work for a page, and provides one way of performing a casual audit of the page to see how extensively the widgets make use of localized strings. When selecting a widget from the query's results set, the actual localized strings can be viewed under the LOCALIZED STRINGS section in the summary tab. Also, the number of localized strings for a widget in the results set can be seen at a glance in the object info tooltip. The system of localization in the UIZE JavaScript Framework (see the JavaScript Localization guide) allows a widget to "inherit" localized strings from up its parent chain, so keep that in mind when viewing the results set.

A flat list of all the widgets on the page that have some remapped DOM nodes, where each widget is listed with a fully qualified dereferencing path (e.g. page.childred.tab.children.option0).

A widget is considered to have remapped DOM nodes when the value of its nodeMap state property is a non-empty object with one or more node name to remapped node mappings. This query might be useful when learning how node remapping works and how and where it used in widgets in real world applications (so, this query is probably of more academic than diagnostic value).

A flat list of all the widgets on the page that implement the value interface, where each widget is listed with a fully qualified dereferencing path (e.g. page.childred.tab.children.option0).

A widget is considered to implement the value interface if the class of which it is an instance declares the value state property. Widgets that implement the value interface are fun to play around with, because they most often are the widgets used in a page for obtaining input from a user. When selecting a widget from the query's results set, the actual value for the widget can be viewed in the table of state properties displayed in the state tab. If you then click on the "set" action in the row for the value state property, you will get a setter expression that you can use to modify the value for the widget and see how the UI responds in the page being inspected.

A hierarchical tree of all the JavaScript modules built for the page, where each module is listed only by its name (e.g. just Page instead of Uize.Widget.Page).

This query provides an exact representation of the module hierarchy for the page. Progressively open up the various levels of the tree list to dig into the structure of the module hierarchy (and, to some extent, class hierarchy), or use the expand all action to lay bare the entire contents of the tree. Click on any of the modules listed in the tree to inspect the module further in the summary tab, to see its automatically detectable features in the features tab, or to read documentation for it in the documentation tab.

A flat list of all the modules built for the page, where each module is listed with a fully qualified dereferencing path (e.g. Uize.Widget.Page).

Modules are listed in the order in which they are built, which is a good indication of the order in which they are needed (i.e. dependency order). This query can be useful when creating JavaScript library files (see the JavaScript Libraries guide for more details). You can use the as report tree list action to get the list of built modules in plain text form in a pop-up window. From there, you can copy the list and then paste it into a library file you are creating or updating (make sure to leave out the Uize.Class base class, though, since that is usually loaded in with its own script tag).

A flat list of all the modules built for the page that are widget classes (i.e. subclasses of the Uize.Widget base class), where each module is listed with a fully qualified dereferencing path (e.g. Uize.Widget.Page).

Modules are listed in the order in which they are built. For any module listed in the results set for this query, the module can be inspected and the instances of the class on the page (if any) will be shown under the INSTANCES OF THIS WIDGET CLASS section in the summary tab. Also, the number of instances created for a class will be displayed in the object info tooltip when mousing over the class in the query results set.

A flat list of all the modules built for the page that are widget classes (i.e. subclasses of the Uize.Widget base class) and of which instances have been created, where each module is listed with a fully qualified dereferencing path (e.g. Uize.Widget.Page).

Modules are listed in the order in which they are built. For any module listed in the results set for this query, the module can be inspected and the instances of the class on the page will be shown under the INSTANCES OF THIS WIDGET CLASS section in the summary tab. Also, the number of instances created for a class will be displayed in the object info tooltip when mousing over the class in the query results set.

A flat list of all the modules built for the page that are widget classes (i.e. subclasses of the Uize.Widget base class) and of which no instances have been created, where each module is listed with a fully qualified dereferencing path (e.g. Uize.Widget.Bar.Slider.Plus).

Modules are listed in the order in which they are built. A widget class built for a page may have no instances created if it is purely a base class for some other widget subclass of which instances are created, or the need to create instances may not yet have arisen due to the current state of the page and the user's interaction with it, or the widget class may be loaded unnecessarily (possibly in some JavaScript library). This query may, at a glance, provides hints as to how a page may be optimized to load less JavaScript code.

A flat list of all the modules built for the page that are not widget classes (i.e. not subclasses of the Uize.Widget base class), where each module is listed with a fully qualified dereferencing path (e.g. Uize.Util.Coupler).

Modules in the results set for this query may be all sorts of non widget class modules, including other kinds of class modules, package modules, extension modules, and any other kind of module (see JavaScript Modules) that doesn't define a Uize.Widget subclass.

A flat list of all the modules built for the page that are under the Uize namespace (i.e. part of the UIZE JavaScript Framework), where each module is listed with a fully qualified dereferencing path (e.g. Uize.Widget.Page).

This query may be useful in providing an at-a-glance sense of how extensively modules provided with the UIZE JavaScript Framework are utilized in a page, versus proprietary modules that are created specifically for a Web site or Web application. The query also provides clues as to which parts of the framework are being utilized most heavily.

A flat list of all the modules built for the page that are not under the Uize namespace (i.e. not part of the UIZE JavaScript Framework), where each module is listed with a fully qualified dereferencing path (e.g. MySite.MyPageWidgetClass).

This query may be useful in providing an at-a-glance sense of how many proprietary modules are needed for a specific Web site or Web application (versus just using the modules that come bundled with the framework). This may provide some good direction on features that should be considered for addition to the framework. The query may also be helpful in narrowing down the list of modules if you're hunting specifically for a module that you know is proprietary and not part of the framework.

A flat list of all the accessed widget DOM nodes, where each node is listed by its ID with a prepended "#" (pound) character.

DOM nodes are considered accessed widget DOM nodes if some widget in the entire widget tree contains a mapping for it in its node cache (i.e. the widget tried to access it). The results set for this query may contain listings for DOM nodes that are present as well as DOM nodes that are missing. For DOM nodes that are present, the ID used when listing a node in the results set will be the value of the node's id attribute. For DOM nodes that are not present, the ID used when listing a node will be constructed using the value of the idPrefix state property of the widget that owns it, and the listing will have the suffix "[MISSING]".

A flat list of all the present accessed widget DOM nodes, where each node is listed by its ID with a prepended "#" (pound) character.

DOM nodes are considered present accessed widget DOM nodes if some widget in the entire widget tree contains a non-null mapping for it in its node cache (i.e. the widget tried to access the node and the node existed at the time). The ID used when listing a node in the results set will be the value of the node's id attribute.

A flat list of all the missing accessed widget DOM nodes, where each node is listed by its ID with a prepended "#" (pound) character.

DOM nodes are considered missing accessed widget DOM nodes if some widget in the entire widget tree contains a null mapping for it in its node cache (i.e. the widget tried to access the node and the node did not exist at the time). The ID used when listing a node will be constructed using the value of the idPrefix state property of the widget that owns it, and the listing will have the suffix "[MISSING]".

A flat list of all widget DOM nodes that have not been accessed by widgets (see Unaccessed Widget DOM Nodes), where each node is listed by its ID with a prepended "#" (pound) character.

This query may be useful when troubleshooting problems where widgets are not functioning as expected. There are number of valid reasons why widget DOM nodes may not have been accessed, but the presence of a very large number of unaccessed widget DOM nodes could also be an indication of some underlying problem.

A flat list of all DOM nodes that have IDs but that do not appear to belong to widgets, where each node is listed by its ID with a prepended "#" (pound) character.

DOM nodes are considered to not belong to widgets if they have not been accessed by any widget in the entire widget tree and their ID is also not consistent with the value of the idPrefix state property for any widget in the entire widget tree. Web developers creating the HTML for a Web page may assign IDs to DOM nodes for the sake of CSS selectors in stylesheets, and these IDs are unlikely to conform to the ID syntax for widgets.

DOM nodes that are not recognized as belonging to widgets but that look like they are intended for widgets could be an indication of an underlying problem. This query may be useful when troubleshooting problems where widgets are not functioning as expected. A DOM node that is not considered to belong to a widget on the page, but whose ID syntax looks like the ID syntax for a widget DOM node, could be an indication of any of the following...

A very large number of DOM nodes that are not recognized as belonging to widgets but that look like they are intended for widgets may be an indication of a more catastrophic failure in the wiring up of the page.

The "1 level" tree list action sets the expanded depth of the entire tree to one level deep.

EXAMPLE

page
  colorPicker

The "2 levels" tree list action sets the expanded depth of the entire tree to two levels deep.

EXAMPLE

page
  colorPicker
    sliderR
    sliderG
    sliderB

The "3 levels" tree list action sets the expanded depth of the entire tree to three levels deep.

EXAMPLE

page
  colorPicker
    sliderR
      drag
    sliderG
      drag
    sliderB
      drag

The "expand all" tree list action expands all levels of the entire hierarchy of the tree list query results.

Reports can be useful when troubleshooting issues during development, and where it may be helpful to alert another developer to some problem or to solicit another engineer's advice / feedback / comments on a situation.

A report that provides an indication of some state that the page is in might be useful data for the person who has to do an analysis and provide some assessment. In such cases, a plain text report can be copied from the popup window and then pasted into an e-mail, or otherwise shared with somebody who can then weigh in on the issue.

The "as report" tree list action produces a report containing the tree list query results for the currently selected tree list query, in plain text form in a popup window.

Indentation is used in the plain text report to reflect the hierarchy of the items in the tree list. Also, some tree list queries don't display full dereferencing paths for results. An example of this is the All widgets on the page, as a tree query, where each widget is listed only by its name (e.g. just option0 instead of page.childred.tab.children.option0). For such queries, there is usually a corresponding flat list version of the query, where the tree will have no hierarchical structure and where the results are listed with full dereferencing paths. The All widgets on the page query, for instance, produces the same results set as the All widgets on the page, as a tree query, but there will be no indentation in the report that is produced when using the as report action, and items will have full dereferencing paths.

The "uber summary" tree list action produces a summary for all of the available tree list queries, in plain text form in a popup window.

Using the "uber summary" action causes the entire set of tree list queries to be performed in sequence. What's captured in the "uber summary" popup window is the names of all the queries and the number of results that were produced for each. Scanning this list might prompt further investigation with individual queries. Where you might not go through the rigmarole of manually cycling through each one of the queries in the tree list query selector, the "uber summary" action makes it easy to see at a glance where further investigation might be warranted. For instance, you might see from the list of queries an unusually high number of results for a particular query, and this might point to some problem or a case of poor optimization. Or some number may be surprisingly low.

Changing the expression in the object entry input always updates the active tab.

So, if the summary tab is the current active tab when the expression changes, then the summary tab will be updated to provide a summary for the new object being inspected. If the state tab is the active tab at the time, then the state tab will be updated to display the state (if applicable) for the new object being inspected. This same principle applies for all the other tabs.

Because of the auto evaluation feature, if you're entering an expression like Uize.Widget.Page, the active tab will be updated at various points during the entering of the expression where the expression enters into a valid state. So, for example, if the active tab was the summary tab, then entering the expression Uize.Widget.Page would update the summary tab when the expression's text gets to Uize, then again when the expression's text gets to Uize.Widget, and then finally when the expression's text gets to Uize.Widget.Page.

When entering DOM node IDs into the object entry input, objects that are defined in the page being inspected, and that happen to have exactly the same name in the global namespace as the node ID being entered, will take priority over the DOM node.

So, for example, if you were entering the DOM node ID "page_colorPicker_sliderR" and there just happened to be a global variable by that name defined in the global namespace of the page being inspected (which is admittedly rather unlikely), then the global variable will take priority over the DOM node and will become the object being inspected, instead of the DOM node ID being converted into a document.getElementById expression.

The SUMMARY FOR section displays in the summary tab for all valid objects, and displays the text of the expression entered into the object entry input - this is merely to reinforce what the summary info is for.

The INSTANCE OF section displays in the summary tab for all valid objects, and displays the class or object of which the object being inspected is an instance.

So, for example, if the expression was 2 + 3, then the result of the expression would be a number and the INSTANCE OF section would display "Number". If the expression entered was 'hello, world', then the INSTANCE OF section would display "String". If the expression entered was 3 > 2, then the result of the expression would be a boolean and the INSTANCE OF section would display "Boolean". If the expression was an object path to a button widget, then the INSTANCE OF section would display "Uize.Widget.Button". And so on.

The object or class displayed in the INSTANCE OF section is an object link, where the object link text and the object link expression are both the name or dereferencing path for the object / class in the global namespace. This means that clicking on the link will let you further inspect the object or class of which the object being inspected is an instance. This can be particularly useful for widget instances, since clicking on the class for the widget will take you to the summary info for the widget's class, and in the summary for the class you will be able to see all other instances of this widget class.

The INHERITANCE CHAIN section displays in the summary tab for all objects that are Uize.Class subclasses, and displays the entire inheritance chain (i.e. all superclasses) for the class being inspected.

The inheritance chain for a class is displayed as a series of classes, separated by "->" (arrow) delimiters, starting on the left with the root class (i.e. Uize.Class) and ending on the right with the class being inspected. Each one of the classes listed in the chain is an object link that links to the class, so you can navigate to anywhere in the inheritance chain for the class being inspected with a single click.

Additionally, the inheritance depth for the class being inspected is displayed in the subtitle of the INHERITANCE CHAIN section's heading. This is the same value that would be displayed in the INHERITANCE DEPTH row of the object info tooltip that shows when mousing over an object link for a class.

The SUBCLASSES (ON THIS PAGE) section displays in the summary tab for all objects that are Uize.Class subclasses, and displays a list of all the classes on the page being inspected that inherit (directly or indirectly) from the class being inspected.

Subclasses that are direct subclasses of the class being inspected are indicated with the suffix "- DIRECT SUBCLASS" appended after their names. Each subclass is listed as an object link, where clicking on the link will let you further inspect the subclass. Additionally, the number of subclasses on the page of the class being inspected is displayed in the subtitle of the SUBCLASSES (ON THIS PAGE) section's heading. This is the same value that would be displayed in the SUBCLASSES row of the object info tooltip that shows when mousing over an object link for a class.

If the class being inspected is a widget class and it has no subclasses on the page, then it is not a base class for some other widget class. You might, therefore, expect there to be some instances of the class created on the page, which you would see listed in the INSTANCES OF THIS WIDGET CLASS section. If there are no instances created, it may just be that the situation has not yet arisen where it is appropriate for instances to be created, or it may be an indication of some problem with the code for the page, or an opportunity to optimize the page so that it's not loading in unused widget class modules.

The INSTANCES OF THIS WIDGET CLASS section displays in the summary tab for all objects that are widget classes, and displays a list of all the instances of the widget class that are in the widget tree for the page.

The instances of the widget class being inspected are displayed in a widget instances table. Additionally, the number of instances of the widget class is displayed in the subtitle of the INSTANCES OF THIS WIDGET CLASS section's heading. If a widget class has no instances in the page's widget tree, and if the widget class is not a base class for some other widget class (see SUBCLASSES (ON THIS PAGE)), then it may either be that the situation has not yet arisen where it is appropriate for instances to be created, or it may be an indication of some problem with the code for the page, or an opportunity to optimize the page so that it's not loading in unused widget class modules.

The PARENTAGE section displays in the summary tab for all objects that are widget instances, and displays a list of all the widget instances up the parent chain, from the widget's immediate parent widget, all the way to the root widget of the widget tree (i.e. the page widget).

The widgets in the parent chain for the widget being inspected are displayed in a widget instances table. Additionally, the number of widgets up the parent chain, from the widget's immediate parent to the root widget, is displayed in the subtitle of the PARENTAGE section's heading. For the page widget, which is at the root of the widget tree, no parentage list will be displayed - a message to the effect that the widget has no parents will be displayed in place of the widget instances table, and the number of widgets will be displayed as "0" in the subtitle of the PARENTAGE section's heading.

The CHILDREN section displays in the summary tab for all objects that are widget instances, and displays a list of all the child widgets of the widget being inspected.

The children of the widget being inspected are displayed in a widget instances table. Additionally, the number of children is displayed in the subtitle of the CHILDREN section's heading. For widgets that don't have any chilren, no children list will be displayed - a message to the effect that the widget has no children will be displayed in place of the widget instances table, and the number of widgets will be displayed as "0" in the subtitle of the CHILDREN section's heading.

The SIBLINGS section displays in the summary tab for all objects that are widget instances, and displays a list of all the siblings of the widget being inspected.

Siblings for a widget are defined as other children (i.e. not including itself) of the widget's parent. The siblings of the widget being inspected are displayed in a widget instances table. Additionally, the number of siblings is displayed in the subtitle of the SIBLINGS section's heading. For widgets that don't have any siblings (either an only child, or a widget like the page widget that has no parent), no siblings list will be displayed - a message to the effect that the widget has no siblings will be displayed in place of the widget instances table, and the number of widgets will be displayed as "0" in the subtitle of the SIBLINGS section's heading.

The DOM NODES section displays in the summary tab for all objects that are widget instances, and displays a list of all the widget DOM nodes for the widget being inspected.

A widget DOM nodes summary is displayed in the subtitle of the DOM NODES section's heading. The widget DOM nodes for the widget being inspected are displayed in a table, with a row for each DOM node, and various columns used in describing each node, as described below...

4.3.5.4.1. NODE NAME

4.3.5.4.2. ACCESSED

4.3.5.4.3. EXISTS

4.3.5.4.4. ID

4.3.5.4.5. TAG

The LOCALIZED STRINGS section displays in the summary tab for all objects that are widget instances, and displays a list of all the specified localized strings for the widget being inspected.

The specified localized strings for the widget being inspected are displayed in a table with NAME and VALUE columns. Additionally, the number of localized strings is displayed in the subtitle of the LOCALIZED STRINGS section's heading. For widgets that don't have any specified localized strings, no localized strings table will be displayed - a message to the effect that there are no localized strings specified for the widget will be displayed in place of the table, and the number of localized strings will be displayed as "0" in the subtitle of the LOCALIZED STRINGS section's heading.

4.3.5.5.1. Linked String Names

The HTML section displays in the summary tab for all objects that are widget instances, and displays the HTML for the widget being inspected (provided that the widget's HTML can be discovered).

The HTML for the widget being inspected is determined by first checking if the widget has a non-null container node (i.e. there's a valid node specified for the container state property of the widget). If there is no container node for the widget, then DELVE checks for the presence of a shell node for the widget (i.e. the DOM node with the name "shell"). If there is no shell node for the widget in the page, then DELVE checks for the presence of the root node for the widget (i.e. the DOM node with the empty string name). If a DOM node can be found for the widget in the page being inspected, then the outer HTML of that node is displayed in the HTML section.

If the HTML for the widget cannot be discovered by DELVE, then a message to the effect that the widget has no container node, shell node, or root node will be displayed. If DELVE can't discover the HTML for the widget being inspected, it might be that the widget's HTML is not in the page, or it might just be that the HTML is actually there but it has no shell or root node (not all widgets require that their HTML have a shell or root node) and there is no container node specified for the widget. It could also be that there is a mismatch between the idPrefix specified for the widget and the idPrefix used when generating the HTML intended for the widget.

The OWNER WIDGET section displays in the summary tab for all objects that are DOM nodes, and displays the widget that owns the DOM node being inspected (if it can be discovered).

The owner widget for the DOM node being inspected is determined by traversing the entire widget tree for the page being inspected, until a widget is found whose idPrefix is consistent with the ID of the DOM node being inspected. If an owner widget can be discovered, then a widget link for that widget will be displayed. If the DOM node being inspected does not appear to belong to a widget (not all DOM nodes do belong to widgets, after all), then a message to this effect will be displayed (i.e. you won't just see a blank line).

The ID section displays in the summary tab for all objects that are DOM nodes, and displays the value of the id attribute for the DOM node being inspected.

If the DOM node being inspected does not have an ID specified, then the ID section will display a message to this the effect (i.e. you won't just see a blank line).

The TAG section displays in the summary tab for all objects that are DOM nodes, and displays the value of the tagName property for the DOM node being inspected.

The HTML section displays in the summary tab for all objects that are DOM nodes, and displays the outer HTML of the DOM node being inspected.

The CODE section displays in the summary tab for all objects that are function references (and that are not a constructor for a Uize.Class subclass), and displays the code for the function being inspected.

The code that is displayed for the function being inspected is obtained by a simple toString serialization of the function object. This means that the function's code may not appear exactly as it does in the actual code where it is defined, and the serialization may differ slightly (in purely cosmetic ways) from one browser to the next.

The TO STRING section displays in the summary tab for all objects that are not functions, instances of Uize.Class subclasses, or DOM nodes, and displays the toString serialization of the object being inspected.

The toString serialization of the object being inspected will depend on its type - it's really up to the object's particular implementation of the toString method. Because the toString serialization can sometimes be quite different to a JSON serialization and may provide additional useful clues when troubleshooting, the toString serialization is provided in addition to the JSON serialization displayed in the JSON SERIALIZATION section.

The JSON SERIALIZATION section displays in the summary tab for all objects that are not functions, instances of Uize.Class subclasses, or DOM nodes, and displays the JSON serialization of the object being inspected.

The object being inspected is serialized to JSON using the Uize.Json module. This module tries to do as good a job as possible at serializing all types of values (such as instances of JavaScript's built-in Date object, RegExp object, Boolean object, String object, etc.), but not all types of objects can be successfully serialized. Values that cannot be serialized are replaced with {} (an empty object).

The Get Action is an object link whose object link expression is a getter expression that can be used to query the value of the state property.

4.4.4.1.1. Instance Getter or Static Getter

4.4.4.1.2. When the Get Action is Useful

The Set Action is an object link whose object link expression is a setter expression that can be used to set the value of the state property.

4.4.4.2.1. Instance Setter or Static Setter

4.4.4.2.2. Deliberately Incapacitated

4.4.4.2.3. When the Set Action is Useful

The Name column displays the name for a feature.

For instance features, the name displayed in this column will be the name of the property of the prototype object. For example, the name displayed for the wireUi instance method would be simply "wireUi". For static features, the name displayed will be the full dereferencing path for the static feature. For example, the Uize.Widget.Page.stateProperties static method of the Uize.Widget.Page class would be displayed as "Uize.Widget.Page.stateProperties".

Displayed names for all features, except state properties, are navigable values. Instance features are linked to inspect the feature on the prototype object of the class. For example, the object link for the wireUi instance method of the Uize.Widget.Page class would have the object link expression of Uize.Widget.Page.prototype.wireUi. In this case, clicking on the feature name will let you inspect the function that implements the wireUi instance method for this class.

By contrast, static features are simply linked to those features on the class object. For example, the object link for the Uize.Widget.Page.stateProperties static method of the Uize.Widget.Page class would have the object link expression of Uize.Widget.Page.stateProperties. In this case, clicking on the feature name will let you inspect the function that implements the Uize.Widget.Page.stateProperties static method.

The Access column displays the access control for a feature.

Since the features table currently only displays what are considered to be public features, the value displayed in this column will always be "Public".

The Context column displays the context in which a feature is defined and accessible.

A feature is considered to exist in one of the following three contexts...

The Type column displays the type of a feature.

A feature is considered to be one of the following three types...

The Introduced In column displays the class in which the feature was first introduced.

Knowing the class in which a feature was introduced can be useful when troubleshooting a problem. You might want to find the very first implementation of a feature to use as a reference when looking at an override of the implementation in a subclass (or the class being inspected).

4.5.4.5.1. How Introduced In Is Determined

The Last Overridden In column displays the last class in which the feature was overridden.

Knowing the class in which a feature was last overridden can be useful when troubleshooting a problem, as the last class in which a feature was overridden would be a prime suspect to examine first when that feature is not behaving as it should. If it's suspected that the last override of the feature introduced some issue, then you can use the Introduced In column to find out where to go to see the original implementation (which you can then use as a reference).

4.5.4.6.1. How Last Overridden In Is Determined

The class that a feature was Introduced In can be the same as the class that the feature was Last Overridden In.

This can be the case if the feature was only introduced for the first time in the class that is being inspected. It can also be the case if the feature was introduced in some base class up the inheritance chain and was never overridden in any subclass, including the class being inspected.

Whenever the object being inspected is set to a non-watchable object, the event log will be cleared and a message, to the effect that there is no valid object to watch, will be logged.

Property Change Events are events that are fired whenever one or more of the state properties for an instance of a Uize.Class subclass are changed during a set operation.

Unlike custom events, property change events are only applicable to instances and not to classes. Whenever Property Change Events are logged, an object specifying all the properties that have changed value, along with their new values, is serialized to a one line JSON formatted string and appended to the log message.

EXAMPLE

23:20:58.185 : PROPERTIES CHANGED: {alignX:0.7542372881355932,alignY:0.5847457627118644}

Custom Events are events that are fired deliberately in the implementation for Uize.Class subclasses, and all such events are automatically logged in the events tab.

Custom Events can be fired on instances (as instance events) by calling the fire instance method, and they can be fired on classes (as static events) by calling the MyClass.fire static method. If the object being inspected is either an instance of a Uize.Class subclass or a Uize.Class subclass, then its Custom Events are automatically logged.

Whenever Custom Events are logged, the event object is serialized to a one line JSON formatted string and appended to the log message. Certain contents of the event object may not be serializable, however, such as the value of the source property. In such an event, an empty object will appear in place of the unserializable value.

EXAMPLE

23:21:56.522 : INSTANCE EVENT: {name:'Palette Dismissed',bubble:true,source:{}}

4.7.2.2.1. Static Events Also Supported

An example of where an object link's expression matches the object link's text is the items of the tree list query results for the All widgets on the page query.

With this query, each item in the results set is a widget link, where both the object link text and the object link expression are identical and are the full dereferencing path for the widget.

An example of where an object link's expression does not match an object link's text is in the items of the tree list query results for the All widgets on the page, as a tree query.

With this query, each item in the results set is a widget, but each object link's text is just the widget's name while the object link's expression is the full dereferencing path for the widget. When viewing all the widgets on the page as a hierarchical tree, it's not as useful to see the widgets listed with their full dereferencing paths displayed. However, the items in the tree still need to link to the widgets and so the expression for every link is a full dereferencing path.

In some cases there is just no space available for the entire expression to be the link text, and in other cases the expression is not even the most compelling or useful representation and would be inelegant, confusing, or even overwhelming to use as the link text.

An example of this can be found in the DOM NODES section of the summary tab when the object being inspected is a widget instance. The NODE NAME column of this table contains object links for the widget's DOM nodes, where the object link's text for a DOM node is just the name of the node, while the object link's expression is a complete expression for accessing the DOM node through the widget (for accessed widget dom nodes) or a complete expression for accessing the DOM node using document.getElementById (for unaccessed widget dom nodes). In this situation, not displaying the object link expression for widget DOM nodes is much more pleasant on the eyes and also more useful.

Shown for all objects, the text displayed will be one of: "null", "undefined", "widget" (for widget instances), "class" (for Uize.Class subclasses), "DOM node" (for DOM nodes), "simple object" (for instances of JavaScript's built-in Object object, or else the type of the object as reported by JavaScript's typeof operator (e.g. "number", "string", "boolean", etc.).

Shown for any value that is not null or undefined, the text displayed will be the global name of the class of which the object is an instance.

For instances of Uize.Class subclasses, the text displayed will be the name of the module that implements the class (e.g. "Uize.Widget.Bar.Slider"). For instances of other objects, it will be the name of the constructor function (e.g. "Number", "String", "Boolean", "RegExp", etc.). For classes and functions, the text displayed will be "Function". For DOM nodes, it will be the name of the DOM object of which the DOM node is an instance (e.g. "HTMLAnchorElement", "HTMLDivElement", "HTMLImageElement", etc.).

Shown only for objects that are Uize.Class subclasses, the text displayed will be the global name of the class' superclass.

For the Uize.Class base class, the text displayed will be "this is the root class", since the Uize.Class class is the root class for all classes that use the UIZE JavaScript Framework.

Shown only for objects that are Uize.Class subclasses, the text displayed will be the inheritance depth of the class.

Inheritance depth is how deep the class is in the class hierarchy. Put another way, it's how many subclasses removed the class is from the Uize.Class base class. So, for example, for the class Uize.Widget.Button the text displayed would be "2", since the Uize.Widget.Button class is two subclasses removed from the Uize.Class base class. For the Uize.Class base class, itself, the text displayed will be "this is the root class".

Shown only for objects that are Uize.Class subclasses, the text displayed will be the number of modules built for the page that are subclasses of the class - directly or indirectly.

So, for example, if only the class modules Uize.Class, Uize.Widget, and Uize.Widget.Button have been built for the page, then the text displayed for the Uize.Class class would be "2". This is because both the Uize.Widget and Uize.Widget.Button classes inherit from Uize.Class. For classes that have no subclasses on the page that inherit from them, the text displayed will be "no subclasses on this page". So, in our example, the text displayed for the Uize.Widget.Button class would be "no subclasses on this page", since it is at the end of the inheritance chain.

Shown only for objects that are widget classes (i.e. Uize.Widget, or a subclass thereof), the text displayed will be the number of instances of the widget class that have been created on the page.

For widget classes of which no instances have been created, the text displayed will be "no instances of this class".

Shown only for objects that are widget instances (i.e. instances of Uize.Widget, or a subclass thereof), the text displayed will be the depth of the widget instance in the widget tree.

Depth in tree is how deep the widget instance is in the widget tree of which the page widget is the root widget. Put another way, it's how many levels removed the instance is from the page widget. So, for example, for the widget instance page.children.colorPicker.children.sliderR, the text displayed would be "2", since the page.children.colorPicker.children.sliderR widget is two levels removed from the page widget. For the page widget, itself, the text displayed will be "this is the root widget".

Shown only for objects that are widget instances (i.e. instances of Uize.Widget, or a subclass thereof), the text displayed will be a count of the number of child widgets that the widget has.

For widgets that do not have any child widgets, the text displayed will be "no children".

Shown only for objects that are widget instances (i.e. instances of Uize.Widget, or a subclass thereof), the text displayed will be a count of the widget's sibling widgets.

The number of siblings of a widget will be the count of the number of children of that widget's parent widget, minus one. For widgets that do not have any sibling widgets (i.e. only child widgets, or the page widget), the text displayed will be "no siblings".

Shown only for objects that are widget instances (i.e. instances of Uize.Widget, or a subclass thereof), the text displayed will be a count of the number of specified localized strings for the widget.

For widgets for which no localized strings are specified, the text displayed will be "no localized strings".

Shown only for objects that are widget instances (i.e. instances of Uize.Widget, or a subclass thereof), the text displayed will be a summary of all the DOM nodes that belong to the widget.

The DOM nodes summary text displayed in the object info tooltip is the same text that is displayed in the header of the DOM NODES section in the summary for widget instances that is shown in the summary tab when the object being inspected is a widget instance. For a detailed description of the text displayed, see the section Widget DOM Nodes Summary.

Shown only for objects that are DOM nodes, the text displayed will be the value of the node's id property.

Shown only for objects that are DOM nodes, the text displayed will be the value of the node's tagName property, which indicates the tag type of the node.

For div tags, the text displayed will be "DIV". For image tags, the text displayed will be "IMG". For anchor tags, the text displayed will be "A". And so on.

Shown only for objects that are DOM nodes, the text displayed will be the full dereferencing path for the widget that "owns" the node.

A DOM node is considered to be owned by a widget if the widget uses that node in its implementation and the widget has accessed the node, or if the ID for the node is consistent with the value of the idPrefix state property for the widget (even if the node has not been accessed by the widget). For DOM nodes that are not considered to be owned by a widget, the text displayed will be "not owned by a widget".

Shown only for objects that are DOM nodes, the text displayed will be the full dereferencing path for the widget class of the widget that "owns" the node.

A DOM node is considered to be owned by a widget if the widget uses that node in its implementation and the widget has accessed the node, or if the ID for the node is consistent with the value of the idPrefix state property for the widget (even if the node has not been accessed by the widget). For DOM nodes that are not considered to be owned by a widget, the text displayed will be "not owned by a widget".

Shown only for objects that are instances of Uize.Class subclasses that implement the value interface, the text displayed will be a simple toString serialization of the value of the instance's value state property.

For highlighting of a DOM node, the position and dimensions of the node are determined as accurately as possible, and then the highlight overlay is placed at the calculated coordinates.

If a DOM node to be highlighted is not visible on the page, then no highlight will be shown (see Non-visible DOM Nodes).

For highlighting of a widget, the position and dimensions of the entire widget are determined, as accurately as possible, as the outer bounding rectangle that contains all of the widget DOM nodes of the widget, along with all of the widget's child widgets.

Because the process of calculating a widget's coordinates can be recursive in nature (because the widget may have child widgets, which may in turn have their own child widgets, etc.), the process gets slower the closer a widget is to the root of the widget tree and it has a bigger tree of its own underneath it. The page widget, which is the root of the widget tree, can be quite slow to compute coordinates on.

In some cases, a node to be highlighted (or that is part of a widget to be highlighted) may not be visible in the page.

This could be as a result of a style rule, applied to the node, that is setting its display style property to none or its visibility style property to hidden. Or it could be that some other DOM node up the node's parent chain is not visible, or that the DOM node is part of some other node's content overflow that is either hidden or scrolled out of view. Whatever the reason, if a DOM node to be highlighted is not visible, then no highlight will be shown. If a DOM node is not visible and it is part of a widget to be highlighted, then the outer bounds that are calculated for the widget highlighting will not be affected by the non-visible DOM node.

The object highlighting feature is implemented to be unobtrusive and to avoid polluting the DOM of the page being inspected (see DELVE is Gentle).

To that end, the DOM that is added to the page being inspected, that creates the highlight effect, is only added as needed to highlight an object being previewed, and then it is removed immediately when the preview is no longer shown. So, once you're done interacting in the DELVE window and have used the object highlighting feature to see where something is in the page, you can then switch over to the page and some other debugging tool (such as Firebug) and not have to worry about encountering extraneous cruft added by DELVE.