WebAssist Triggers

Triggers in WebAssist extensions are contained in an editable select list, typically located at the top of extension dialog box. The events in the select list vary according to the elements of the page. Certain events are always found in the list, including:

1. any form post
   
2. before page load
   
3. current page submit

Other potential events are dynamically added to the Trigger list including all the detected submit buttons, recordsets and eCart objects and SecurityAssist rules.

You'll also notice the lightning bolt next to the Trigger list. Select this lightning bolt to set the trigger to any dynamic data, such as a database­ driven field, a session variable or form element posted from another page.

In order to use WebAssist Trigger events, an understanding of form attributes is imperative. There are two key attributes, as far as triggers are concerned: action and method.

A form's method attribute takes one of two values: POST or GET. Generally, it's better to use the POST method rather than the GET method. Many of the available triggers respond to a form POST method and many pages are designed to respond or include data from a form.

The action attribute specifies where the information contained in the form is sent. In most cases, the action is a URL, either relative or absolute. The URL may lead to the next web page to display or it may lead to a CGI script. It's also possible to leave the action blank; this causes the action to submit to the current page. Dreamweaver server behaviors such as Insert Record and Update Record use this technique. After the code in those server behaviors have executed, using the data contained in the form, the page is redirected to another.

Like Dreamweaver, WebAssist can trigger server behaviors based on events that take place within the current page, i.e., the same page containing the server behavior. To achieve this effect, forms can either leave the action attribute blank or explicitly set to the current page URL.

In this case of same page actions, triggers respond to the POST events after the form is submitted.

Same page triggers include:

1. any form post
   
2. before page load
   
3. current page submit
   
4. Button: <Your Button> Pressed

WebAssist triggers can also be used when the form is in a separate page than the server behavior to be triggered. With this potential, you can apply WebAssist server behaviors to create multiple page forms or create dynamic pages that act like web services.

The key to using external page triggers is to make sure certain conditions are met:

1. The action attribute for the form on the external page must be set to the URL or path of the page where the trigger is applied.
   
2. The server behavior using the desired trigger is inserted on the current (and not the external) page.
   
3. An appropriate trigger is selected

To use a form element (such as a submit button) found on an external page, use the WA Form Data command, found in the Bindings panel Add list. Once the page containing the desired form has been identified, the form and all of its elements appear on the Bindings panel – which, in turn, is displayed when the Trigger lightning bolt is selected.

To create a web service type page, use the "any form post" trigger.

Many user problems can be averted by verifying that the form action attribute is set appropriately for the trigger selected. If the form action is blank or set to the current page and the trigger is set to a form element on an external page, the trigger will not fire. Similarly, if the form action is set to another page that contains the server behavior – but the trigger is set to "current page submit" – the trigger will not fire.

The following are examples of trigger events commonly found in WebAssist extensions and how they should be used.

1. Before Page Load: This trigger should be used when you want the server behavior run every time the page is accessed and not in response to a form being posted. This trigger works well when using the eCart Store Summary in Database server behavior and avoids the issue of a checkout form submitting directly to the processing gateway.
   
2. Any form post: Use this trigger for creating pages that act like services or accept form input from multiple sources. This is a very open, unsecured way to submit a form.
   
3. Current page submit: The Current page submit trigger checks the referring page and makes sure that it is the submitting page. This is a very secure way to run server behaviors, because your form post cannot be easily spoofed; however, it may not work in some intranets because firewalls may block the referring page from being identified.
   
4. <Button> press events: These trigger events fire only when a specific form button was used to submit the form. This trigger is best when a single form is used for multiple actions and includes separate buttons for them, like an Update and a Delete button.
   
5. eCart is Empty or eCart is not Empty: These triggers only appear when the WA eCart Object is on the page.
   
6. Recordset is Empty or Recordset is not Empty: These triggers only appear when a recordset is on the page.
   
7. Is Valid Paypal Transaction: This trigger is only available in the Get Cart from Form server behavior, or any other server behavior applied after the Get Cart from Form server behavior appears on the page.

Many of the triggers that WebAssist extensions use to enable the various Server Behaviors are dependent on the value that the Action field in your form displays. If you are using the “any form post” trigger, make sure that either the current page submits to itself or the page that precedes the one containing the Server Behavior with the trigger is using a POST Action to send the user to the current page. If you are using the “current page submit” or “Button: <yourbutton> pressed" options, make sure that the Action for your form is either blank or set to post back to the same page. In this case, a redirect to the next page is required to navigate to another page. A redirect page does not receive any form data from the page that it was redirected from, so you will need to store your data in a database, a Cookie or a Session Variable before you redirect to another page.

Comments will be sent to the author of this tutorial and may not be answered immediately. For general help from WebAssist, please visit technical support.

Sign in to add comments