Context-full Functions

In contrast to context-less functions, context-full functions are designed to use results from previous function calls. How results are to be used is specified in a way that does not incorporate dynamic data.

Context-full functions in Silk Performer page-level API include:

The WebPageLink function downloads the target URL of a link.

Example HTML code:
<a href=http://www4.company.com/store/5423/account>Edit Account</a>

The above link contains load balancing information (www4) and a session id (5423) in the target URL.

Assume the user clicks this link. This can be modeled in BDL using the WebPageUrl function:

WebPageUrl("http://www4.company.com/store/5423/account");

The problem with this is that the dynamic components of the URL are hard-coded into the script.

Alternatively, the WebPageLink function can be used: WebPageLink("Edit Account");

This solution is better because the Silk Performer replay engine will, using its HTML parser, use the actual URL that is associated with the link name Edit Account during replay. While it is still possible that a link name can change dynamically, it is far less likely than having a URL change.

The WebPageSubmit function submits a form. By doing so, it combines a form definition from a previously downloaded HTML document with a BDL form defined in the script.

<form action="/cgi-bin/nav.jsp"
      name="frmNav"
      method="post"
      target="basketframe">
  <input type=input  name="quantity" 
                     value="1">
  <input type=hidden name="BV_SessionID"
            value="@@@@1245417051.1003814911@@@@">
  <input type=hidden name="BV_EngineID"
            value="dadccfjhgjehbemgcfkmcfifdnf.0">
</form>

Now suppose the user changes the quantity from 1 to 3 and submits the form.

This can be modeled in BDL using the context-less WebPageForm function with a corresponding form definition:

WebPageForm("http://www4.company.com/cgi-bin/nav.jsp", FORM_BASKET_1);
...
dclform
  FORM_BASKET_1:
    "quantity"    := "3",
    "BV_SessionID" := "@@@@1245417051.1003814911@@@@",
    "BV_EngineID"  := "dadccfjhgjehbemgcfkmcfifdnf.0";

The problem with this solution is that everything is hard-coded into the script: the URL, which in this case contains load balancing information, and the form fields, which carry session information.

The better solution is to use the context-full WebPageSubmit function:

WebPageSubmit("frmNav", FORM_BASKET_2);
...
dclform
  FORM_BASKET_2:
    "quantity"     := "3",
    "BV_SessionID" := "" <USE_HTML_VAL>,
    "BV_EngineID"  := "" <USE_HTML_VAL>;

The WebPageSubmit function references an HTML form from a previous server response by name. The Silk Performer replay engine, using its HTML parser, automatically uses the actual action URL and HTTP method (GET or POST) to submit the form. The replay engine then uses the values of the BV_SessionID and BV_EngineID fields from the actual HTML code, so they do not need to be specified in the script.

Form Definitions in BDL

In Silk Performer, the syntax of form definitions in BDL scripts has been enhanced so that it is possible to specify whether individual fields should use values included in scripts, from HTML code, or be suppressed entirely.

Such specification is achieved using syntactical elements called form attributes. Form attributes are also used to specify encoding types for form fields.

For forms that are used context-fully using the WebPageSubmit function, the following usage attributes are allowed:

  • USE_SCRIPT_VAL (default)
  • USE_HTML_VAL
  • SUPPRESS

USE_SCRIPT_VAL means that the field value from the script is to be used for submission. This is the default attribute and can be omitted.

USE_HTML_VAL means that the field value from the HTML form definition is to be used. The value in the script is ignored and set to "". Form fields in the script are matched by name with form fields in the HTML form definition.

SUPPRESS means that even if a field with a specified name is present in an HTML form definition, neither the field's name or its value will be submitted. The field value in the script is therefore meaningless and is ignored.