eValid™ -- Automated Web Quality Solution Browser-Based, Client-Side, Functional Testing & Validation, Load & Performance Tuning, Page Timing, Website Analysis, and Rich Internet Application Monitoring.

Summary
This page describes the eValid Script Language and outlines the principles of its operation. There are over 250 eValid script language commands, and there is an available Script Language Index. You may also want to review the Frame Path Conventions.

General Philosophy
The eValid script language incorporates these General features:

• The eValid script language is intended to be generic, that is, compatible with a wide variety of programming and scripting languages. To the extent possible, our format avoids appearing like an existing language as a means to minimize the impact of interfacing it with an existing language.

• The eValid script language expresses playback scripts that are either created by the eValid recording process, or hand-edited, or machine-created by external means, of some combination of the above.

• Commands are interpreted sequentially at playback time, and flow of control is altered ONLY with FLAG processing commands. Generally the goal of playback is to complete the script if possible, but eV.Manager may treat a playback with any messages as a FAILed test.

• During processing, the eValid playback engine Errors, Warnings, or Notes of various kinds are issued to the message area during playback if problems are detected. It also sets Flags that interact with OnFlagAction-type commands so that alternative actions based on state changes can take place.

Command Language Format & Syntax
Here is the general structure of all eValid commands:

command wid idx modifier [ modifier ] { frame_path } [ NAV | NO_NAV ]

where,

• The command is the name of the action to take, e.g. GotoLink.

• wid is the window identifier where "0" is the parent (main) browser, and "1", "2",... refer to child browsers in the order in which they are opened by the parent.

• idx is the internal HTML Document Object Model (DOM) element number assigned by eValid.

• One or more command modifiers in "quotes like this" are literal strings which cannot contain instances of " (double quote) or of ' (single quote).

  To show these explicitly you need to use a text editor to include such characters in Hex, or escape them with a \" or \\'.

  Any modifiers supplied have meanings that depend on the specific command.

• Lines that begin with # are comments. Blank lines are ignored.

• Lines that require continuation can be separated by a "\" placed inside a string.

• All other modifiers -- i.e. those not in quotes -- are integers (simple numbers).

• Values that represent time are expressed in whole milliseconds.

• Script command modifiers may need additional explanations that are given in each definition.

• frame_path is the name of the frame and/or frame sequence, defined this way:
  • eValid uses "name:title" for labeled frames (if they have a non-blank title) and with "number:N" for unnamed frames, where N is a unique frame number (ordinal number) that depends on the frame position within the actual frameset for the page.
  • The value of N starts with 0 (for the first encountered frame) and increases by +1, e.g. 1,2,3,4..., in an order that is internally determined and is unique to the page properties.
  • Note that the frame_path will always be expressed in terms of an ordinal the "number:N" format if you have chosen the "Record Frame Names as Ordinal Values" setting in the eValid preferences.
  • Also, in case a frame has no name, or in the case of an iframe which does not permit use of a frame name, then eValid will use the "number:N" format to make sure there is no ambiguity.
  • See Frame Path Conventions for a complete description.

• Commands that optionally result in a navigation will contain an additional last field [ NAV ] when navigation is required, and otherwise not.
  • If navigation is to be ignored in a command you can use [ NO_NAV ] instead of the appended [ NAV ].

Constraints & Limitations
Some of the internal constraints and limitations include the following:

• Recursion: A script may not reference itself, i.e. CallScript script.evs is not allowed in script.evs.
• Self-Reference: The definition of the target of a Flag Processing command, may not be itself, i.e. OnErroGoScript script.evs is not allowed in script.evs.
• Stack Operation: Chains of CallScripts use a dynamically allocated stack but very large depths (e.g. > 100 deep) of this stack may produce unexpected, undesirable results.
• Syntax Mistakes: Syntax errors in commands are noted after editing, but do not prevent the script from playback (but illegal commands will be identified as soon as they are encountered).