$storedVariableName notationWhen compared to ClassicSelenese, automation scripts with SeLite are shorter and clearer. SelBlocks Global enhances syntax of ClassicSelenese > Selenese parameters target and value. It allows those expressions to
$storedVariableName notation and$object-var-name.fieldXYZ, $object.method(...) or $array-var-name[index]<>...<>$storedVariableName notationThis syntax enables Selenese commands and structures that evaluate their parameter(s) as Javascript to access stored variables as $storedVariableName. It’s for
<>...<> (and its variations) andtarget parameter of:
getEval (and its auto-generated variations as per ClassicSelenese > Auto-generated Selenese commands),promise, storePromiseskipNext, gotoIf, if, elseIf, throw, catch, while, for, continue, break, returnvalue parameter of:
forEach, forIterator, forIterable, loadJsonVars, loadXmlVarscall - only on right side of function parameter assignmentsSee also SelBlocks Global > Accessing stored variables.
If you need to pass '$' (a dollar as a string constant) to any of the above Selenese commands, use String.fromCharCode(36).
This notation allows you to pass results of one or multiple Javascript expressions (each enclosed within a pair of <>...<>) to Selenese commands in their parameter (target or value). It evaluates any Javascript code in target or value that is between any pair of <>...<> (excluding the pair of <> itself).
This is similar to standard Selenese javascript{...} as per Selenium IDE > JavaScript Usage with Non-Script Parameters. However, javascript{...} must have no prefix/postfix - i.e. it must be the only content of a Selenese command’s parameter (target or value). Hence, there can’t be multiple occurrences of javascript{...} in the same Selenese parameter.
This converts the evaluated result to a string. You can have any prefix or suffix around <>...<>. The whole Selenese parameter (target or value) is treated as a string. Results of Javascript codes from <>...<> are concatenated together with any prefix, interlacing strings and any suffix.
Following are variations of <>...<> syntax. They all treat the string between the pair of <>...<> as a Javascript expression. However, they treat the result in a special way, or they apply extra transformation to it.
They all start with special characters =, <> or @ immediately in front of the opening pair of <>. Those characters =, <> and @ are only a part of the syntax; they are not included in the result that is passed to the Selenese command.
If a Selenese parameter contains only one =<>...<> with no prefix and no suffix (not even a space), then its result is not treated as a string. SelBlocks Global preserves the type of result of Javascript expression within <>...<> and it passes the exact result as a Selenese parameter. That’s useful if you want to pass a number, an object or an array (and it still works for strings). If there is any prefix or suffix, SelBlocks Global reports an error.
If a Selenese command supports (or requires) an object passed this way, then do not invoke that Selenese command with an extra parameter passed through @<>...<>.
\<>...<> is like <>...<>, but it quotes and escapes its result as string literal/constant for XPath expression. You can have multiple occurrences of \<>...<> in the same Selenese parameter, with any prefix/suffix and interlacing strings, and you can mix them with basic <>...<>.
Like <>...<> without prefix, \<>...<> evaluates the enclosed part as Javascript expression. The result is treated as content of a string literal/constant for XPath. Then this escapes both apostrophes and/or quotation marks in it. It generates an XPath string sub-expression that may use XPath function concat(). (For details see quoteForXPath() in Selenium Core’s online htmlutils.js or offline at chrome:// URL chrome://selenium-ide/content/selenium-core/scripts/htmlutils.js).
Due to a bug in Selenium IDE, you need to put two backslashes in the edit field for that cell. Please vote for ThirdPartyIssues > Backslashes get reduced to half.
By default, Selenium IDE allows to pass only two parameters to commands: target (usually a locator) and value. However, some SeLite commands (e.g. in Exit Confirmation Checker) need to receive extra one or two parameters. SelBlocks Global enhances syntax by allowing value of each standard Selenese parameter (target or value) to include one occurrence of @<>...<> containing a Javascript expression.
This notation extracts and completely removes that @<>...<> from the parameter. It concatenates the rest (any prefix merged with any suffix) for the string value (potentially empty) of that Selenese parameter (target or value). It transforms that value into a String object (rather than a string primitive). Then it evaluates the Javascript from within @<>...<> (the part that it extracted and removed). It stores the result as an extra (optional) field seLiteExtra on that String object (one made from any prefix and suffix). Then it passes the result String object to the called action as the actual value of the intended Selenese parameter (either target or value).
The Selenese command (i.e. a custom command or a custom override/intercept of standard Selenese) can access the result of Javascript through field seLiteExtra if it is set on the parameter. Using @<>...<> makes the command receive instance of String object rather than a primitive string. That will work with most use cases of primitive strings. Hence this mechanism is mostly forward compatible.
<>...$storedVariableName...<> works. It translates to <>...storedVars.storedVariableName...<>. The javascript expression will be valid or invalid regardless of type of stored variable with name storedVariableName.
However, <>...${storedVariableName}...<> (as per ClassicSelenese > Stored variables) doesn’t work. Side note: We don’t want this second form anyway, because ${storedVariableName} works through brute string substitution. It could cause unexpected Javascript errors. E.g. when developing the script, ${variableName} could be a number. However, later it could become a non-numeric string. If there were no quotes/apostrophes around it, an the Javascript expression would expect a number, it would fail. Also, it would need extra handling of strings containing apostrophes/quotes. Indeed, ${storedVariableName} works in any prefix/suffix of <>...<> (as per standard Selenese).
Same limitations apply as per ClassicSelenese > limitations of getEval and its derivatives.
To pass actual text <> to Selenium, generate it from an expression. For example, pass <>'<' + '>'<>. See SelBlocksGlobal/selenese-scripts/misc_case.html.
This applies to any target or value, whether they contain <>...<> or not. (Also in prefix or suffix of <>...<> or in Javascript within <>...<>). That includes contents of Javascript string literals (within '...' or "...") passed to classic getEval (and actions generated from it, as per ClassicSelenese > Auto-generated Selenese commands).
As a result, with SelBlocks Global, any valid Selenese parameter can’t contain an odd number of <> pairs.
A simple rule is: Don’t pass =<>...<> or @<>...<> to getEval or to custom commands that evaluate values of their Selenese parameters (target or value) as Javascript expression(s), unless those commands are designed for it. The same applies to derivative commands like storeEval (as per ClassicSelenese > Auto-generated Selenese commands).
Alternatively, if you’d really like to pass the string value of this object as a parameter to command getEval (or storeEval…), which would then evaluate it as a Javascript expression (again), use <>...<> instead.
If you develop Selenese commands that may be used with =<>...<> or @<>...<> then:
target and value) using strict comparison operators === and !==. Also, don’t depend on their typeof, which will be object rather than string if the passed parameter uses =<>...<> or @<>...<>... If you’d like to use strict comparison or typeof with such a parameter, transform it to a string (see rule #4 below).<>...<> syntax, the user shouldn’t pass an object (i.e. =<>...<> with no prefix and no suffix, or @<>...<> with any prefix/postfix). If typeof(first_or_second_parameter_name)==='object' then make it fail. See Selenium.prototype.preprocessParameter and Selenium.prototype.getEval online in selblocks.js or offline at chrome:// URL chrome://selite-selblocks-global/content/extensions/selblocks.js.=<>...<> with no prefix and no suffix), then prevent it to be passed through @<>...<> by mistake. If typeof first_or_second_parameter_name==='object' && 'seLiteExtra' in first_or_second_parameter_name then make it fail. See Selenium.prototype.doCall online in selblocks.js or offline at chrome:// URL chrome://selite-selblocks-global/content/extensions/selblocks.js.target or value) as Javascript and you also want it to work with @<>...<>, then in the definition of the command
seLiteExtra from the parameter and store it for later use (if needed), e.g. var seLiteExtra=target.seLiteExtra;target=''+target; and only then pass it to eval().(See also Mozilla’s documentation of String object > Distinction between string primitives and String objects.)
Selenium IDE supports access to stored variables via ${xyz} syntax. (Implementation note: it is handled by preprocessParameter().)
Alternatively, you may use shorthand javascript{...} - see Selenium IDE docs > JavaScript Usage with Non-Script Parameters. However, those Javascript expressions don’t support classic ${storedVariableName} shorthand.
Also, you may call getEval as storeEval, which stores the evaluated result of target parameter in a Selenese stored variable that is named in value parameter. E.g. if value parameter is xyz, then you can access the result as ${xyz}. However, <>...<> syntax operates at level different than getEval. So, in general you can’t just copy any expression between <>...<> and getEval (it works for some expressions, but not for others).
Without <>...<> you’d need either to
javascript{...}. They’d have to access stored variables via storedVars. Such expressions are more wordy and less intuitive.storeEval to save the result into a temporary variable. Then pass that stored variable as ${xyz} to the further command(s). That makes your script longer. The unnecessary variables make it less clear and more fragile.storedVars.variableName with getEval and related commands.$variableName with commands from SelBlocks Global.${variableName} or <>$variableName<> with any other Selenese commands.javascript{...} for special purposes. See online Selenium Core reference > Parameter construction and Variables or offline at chrome:// URL chrome://selenium-ide/content/selenium-core/reference.html#parameter-construction-and-variables. Use this notation with e.g. window.opener.resizeTo() and window.opener.innerWidth.