One feature unique to WebAssist extensions is the concept of triggers. A trigger detects a specific event and runs a server behavior or other function. The power of triggers in WebAssist extensions lies in the flexibility they give you as a developer. Unlike the triggers in native Dreamweaver server behaviors, WebAssist triggers can fire in reaction to many different kinds of events, even those contained in other pages. This document provides background information and discusses the appropriate use of the various triggers available.
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:
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:
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:
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.
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.