|
eValid -- Automated Web Quality Solution
Browser-Based, Client-Side, Functional Testing & Validation,
Load & Performance Tuning, Page Timing, Website Analysis,
and Rich Internet Application Monitoring.
|
|
eValid -- Script Language Principles
eValid Home
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).