• jQuery Library Injection. The Web 2.0 Add-in support is based on the jQuery JavaScript library. Therefore, if you load any Web 2.0 add-in, OpenText Functional Testing injects the jQuery JavaScript library into every Web page that opens in a browser while OpenText Functional Testing is open (unless a jQuery library is already included in the page).

  The specific jQuery UI file injected for each Web 2.0 add-in is specified in the add-in's toolkit XML file, located in: <OpenText Functional Testing installation>\dat\Extensibility\Web\Toolkits\<ToolkitName>\<ToolkitName>.xml.

• F1 Help Support. When you press F1 on a test object operation that was inherited from the Web Add-in, the Help displays information about that operation for the Web Add-in test object class from which the operation was inherited, and not for the extensibility-based test object class used in your step.

  Additionally, the details in the Help file reflect the behavior of the test objects and operations in the XML files provided with OpenText Functional Testing. If these files were customized or modified in any way, the details in the Help files supplied with OpenText Functional Testing may no longer be accurate.

  In general, when the content of the extensibility files for a Web 2.0 toolkit is modified, the Help file should also be changed as described in Customization Guidelines, below. In these cases, you should contact the person or organization who customized the files as your first contact point for support.

• Checkpoints and Output Values. Inserting checkpoints and output values on Web 2.0 objects is supported only when recording steps.

• Container Objects. Some Web 2.0 objects that visually or behaviorally seem to contain other objects in a Web application are not learned as container objects in terms of the test object hierarchy. For example, this is the case for the YUIDialogBox and GWTDialogBox test objects.

• values. When working in Mozilla Firefox, the value of the selected item or selected is not available in the Object Spy for some Web 2.0 test object classes. The same is true when updating property values from the application in the object repository. This is because the value is only retrievable when the browser is in focus.

  Workaround: Retrieve the property value without removing focus from the browser. For example:

  Browser("Dijit Tree Test").Page("Dijit Tree Test").DojoTree("mytree").Select "Continents;Africa"
  msgbox Browser("Dijit Tree Test").Page("Dijit Tree Test").DojoTree("mytree").
  GetROProperty("selected item")

• Object Type Identification. In the toolkit XML file, the <HTMLTags> and <Conditions> elements in the <Identification> section for the relevant test object class define how OpenText Functional Testing maps Web controls to that class.

  In the example below, OpenText Functional Testing identifies a control as a GWTToggleButton test object (when the GWT Add-in is loaded) if it has a <div> HTML tag and a className HTML property with a value that matches the regular expression: .*gwt-ToggleButton.*

  <Control TestObjectClass="GWTToggleButton">
     <Settings>
     <Variable name="default_imp_file" value="JavaScript\GWTToggleButton.js"/>
     </Settings>
     <Identification>
  	 <Browser name="*">
  	   <HTMLTags>
  	   <Tag name="div"/>
  	   </HTMLTags>
  	   <Conditions type="IdentifyIfPropMatch">
  <!-- The search string in this condition is treated as a regular expression and is therefore equivalent to .*gwt-ToggleButton.* -->
  	    <Condition prop_name="className" expected_value="gwt-ToggleButton" is_reg_exp="true"/>
  	   </Conditions>
  	</Browser>

  In some cases (for example, when <Conditions type="CallIDFuncIfPropMatch">), a JavaScript function that contains identification criteria is also used to help map controls to a test object class.

  Keep in mind that the support provided in the Web 2.0 add-ins is dependent on the HTML and DOM structure of the controls. If developers of a Web 2.0-based application change the values of a control's properties, then the values defined for the <HTMLTags> and <Conditions> elements of the toolkit XML files (or JavaScript files) may not enable OpenText Functional Testing to correctly identify those controls.

  If OpenText Functional Testing is not identifying an object in your application as you expect, you can view or adjust these values in the relevant toolkit support files.

  The toolkit XML files are located in: <OpenText Functional Testing installation>\dat\Extensibility\Web\Toolkits\<ToolkitName>\<ToolkitName>.xml

  The JavaScript files are in a JavaScript folder under the above folder.

  If you modify this (or any) extensibility toolkit support set file, follow the guidelines described in Customization Guidelines, below.

  For more details on the way OpenText Functional Testing identifies supported controls and for details on the implementation of the supported operations, see the comments provided in the XML and JavaScript files for the relevant toolkit support set.

If you are familiar with Web Add-in Extensibility, then you can customize or further extend the built-in Web 2.0 support to match the needs of the Web 2.0 toolkit application you are testing.

Additionally, if you have installed Extensibility Accelerator, you can use this IDE to make it faster and easier to design and develop the required extensibility XML files so that you can invest your main efforts in the development of the JavaScript functions that will enable OpenText Functional Testing to work with your custom Web controls.

Extensibility Accelerator also comes with built-in projects for the OpenText Functional Testing Web 2.0 add-ins. You can use these projects to help you learn the Extensibility Accelerator features or to more easily add to or modify the provided support files.

If you customize or further extend any of the Web Add-in Extensibility files, you should also do the following:

• Make a copy of, or otherwise back up, the original files.

• Change the name and description that are displayed in the Add-in Manager for the toolkit. Include the text: "Provided by <YourOrganization>" in the Add-in Manager description (in the Controls\Description element of the toolkit XML file).

• Create your own Help file to be opened for the customized test object classes or operations. You must use a different file name than the OpenText-provided Help file. (Change the file name in the HelpInfo element of the Test Object XML file.)

  Note: When installing the Web 2.0 add-ins, if a previous version of a selected add-in is installed on your computer, the setup stores the previous files in a backup folder before installing. You may need to merge any customizations you made to the previous version into the new version.

For details on how to make these changes and how to customize the support files, see the Web Extensibility Developer Guide.