Insert Dynamically Loaded Drop Down Box

• Overview
• Inheritance
• Include the drop down box in the page

Overview

In many situations it is desirable to let a page contain a drop down box, which instead of being loaded with static values is loaded using a function accessing the database.

Websydian offers such a functionality. The way this is done in standard Websydian is described here.

This functionality is of course also offered in WebsydianExpress.

This section describes the implementation of a dynamically loaded drop down in WebsydianExpress, with focus on the things, which are different from the standard implementation.

Inheritance

The drop down box is basically just a special child page, which is being inserted on a parent page. The child page is created and the functions you need to generate is set to implement Yes using the following triples:

Inheriting from the WSYAPI/HTMLDropDwonGeneratorForProcess ensures that the generated template for the drop down box can be placed in the same folder as rest of the application - and that you can specify special behavior for the drop down based on the presentation used. 

Include the drop down box in the page

As all functions inheriting from PageGeneratorForProcess are automatically ParentPageGenerators the only thing needed is to include the drop down box in the page like this:

Generate, build and run the DocumentTemplateGenerator for MyDropDown. This generates the template for the drop down box - customize this as needed.

Generate, build and run  the DocumentTemplateGenerator for MyPageGenerator. The generated template will contain a replacement marker specifying the implementation name of MyDropDown.

The child page created by MyDropDown will be inserted instead of this replacement marker at run time.

Specifying Restrict fields

When  the HTMLDropDownGenerator calls the BlockFetch function, it will call with blank values for the fields in the Position variable. This ensures that all records in the table is shown in the drop down box. However, this is a problem if the BlockFetch function restricts on one or more of the fields in the Position variable. In this case, the BlockFetch will get a blank value for the restrict field - and the BlockFetch will not return any records.

To ensure that all restrict fields are transferred unaltered to the BlockFetch, you must add them to the local variable Restrict. The values of these fields will be set to the values of the fields in the Position input variable and they will be used as parameters for the call to the BlockFetch function.

This behavior is specific to the WebsydianExpress implementation of the drop down functionality.

In versions prior to WebsydianExpress version 3.5, there is an error in the pattern, which means that the mapping of the field in the Restrict variable wasn't used as parameters for the call to the BlockFetch - in these versions, you must map the parameters manually.