Other Uses of the Page Generator

Introduction    Implementing    Other Uses     Example     Background

Omitting Fields from Generated Document Template

Fields declared in the WsyDetails and the WsyGrid variable will by default be shown in the Details table and as columns in the Grid table on the generated HTML Document Templates.

It is possible to declare that certain fields of the details and grid tables should not be included in the generated Document Template.  This is done by including the omitted fields as local fields in the OmitDetailsFields and OmitGridFields variables of the Page Generator function.

Example:

The result of the above declarations will be that only the key fields of the Employee records will be shown as read-only fields in the Details table on the generated Document Template.

Define Own Template Page Generator

New Page Generator functions can be defined by using application specific 'Template Page Generators' from which all application Page Generators inherit.  All common definitions can the be put into this template pattern.  Or the Page Generator pattern templates may be defined from one of the composite patterns in the WSYUTIL pattern library.

Converting HTML Special Characters

When the Page Generator function substitutes replacement markers with text strings, some of these strings might be data supplied by a user.  A user may try to make the web application misbehave by entering valid HTML text in the input data, eg. server side include directives.  When this data is merged into the HTML template during page generation, the outcome is unpredictable.

To prevent this scenario, Page Generators must inherit from the PageGeneratorWithCharConversion building block.

URL-encoding Field Values

When the Page Generator function substitutes replacement markers with text strings, special characters like spaces and e.g. "&" are substituted directly into the document without any character conversion.

If URL-safe values are needed, specify the option

and enclose the section where URL encoded values are needed with the replacement marker /(WSYDURLENC) in the template file.

Sample template file:
 

<TR>

    <TH ALIGN=LEFT>Field1</TH>

    <TD ALIGN=LEFT>/(WSYDURLENC)/(AA1vA)/(WSYDURLENC)</TD>

</TR>

Formatting of Field Values

When a replacement marker is found and a field with the corresponding implementation name is located, the value of the field is formatted to a representation as described by the following rules:

• If the field has an edit mask, this mask is used to format the value. The syntax for an edit mask is the same as for a normal Windows/GUI application written in Plex.
• If no edit mask is defined for fields of type Date, Time, or Timestamp, the Page Generator function will look after edit masks in the external parameters of the Dispatcher functions. Refer to the section Specification of Field Appearance and Intepretation.

The table below summarizes how an edit mask is found for different types of fields, depending on whether the FLD edited by LBL triple is specified or not.

Calling Error Page if Template Document Is not Found

If the Document Template can not be located, a standard error page is generated. This happens, if the path to the Document Template has not been specified for the Dispatcher function.

It may also happen if a wrong path or document name has been set in the 0 Set path edit point.

Example:

A Websydian Error page is called when the HTML Document Template cannot be found.

Specify Sum Fields for a Grid Page

Due to the implementation of the Page Generator function pattern, some limitations exist on specifying summation functionality, e.g. functionality counting totals on the grid lines shown on an HTML page.

A Page Generator function locates and reads a Document Template and for each line read, it substitutes the replacement markers in the Document Template with the corresponding field values in the WsyDetails or in the WsyGrid variable.  The resulting string lines are sent directly to the web user and no memory is kept of the lines of the HTML page when they are produced.

This means, that it is not possible to write a number of grid lines and then afterwards produce a calculated sum for e.g. one of the columns at the top of the HTML page.

Sum field in top of the HTML page must be implemented as described below.

The summation field must be produced before the grid, which is impossible before the grid records are read.  In this way Websydian differs from normal AllFusion Plex Windows/GUI design where all fields at the screen can be accessed at any time in the action diagram logic before the window is presented to the user.

There are three possible solutions to implement summation fields:

1. The summation fields may be placed at the bottom of the page after reading the grid records (and constructing the grid table).  The summing can be done during the grid load in the 0 Load fields in grid edit point.  After having generated the grid, the result can be put to the summation field in the WsyDetails variable in the 0 After loop in grid edit point.
2. Run through the records twice.  First, to calculate the sum field(s).  Secondly, load the grid table.  It must be ensured that the same set of records is read in both iterations.
3. The summation fields may be hidden in fields below the grid and assigned to visible fields at the top of the page using direct object access with JavaScript.

Maximum Number of Field Columns in Grid Table

The maximum number of lines of text between the two grid markers in the Document Template is set to 128.  If this value is exceeded, an HTML Error page will be called.

The maximum number of grid table columns is controlled by the Websydian StringArray variable in the ReplacementProcess pattern (which all Page Generator functions inherit through):

The limit can be overridden by the individual Page Generator functions.

Dynamic Population of Drop-down Boxes

See the Parent and Child Page Generator Patterns page in the Utility Module. Generate a HTML file using the

Generate a HTML file using the PageGenerator

With a few changes to the PageGenerator you will be able to produce a file with the html document created by the PageGenerator.

See the XMLFileGenerator for further information on how to create your own PageGeneratorToFile.

Option to disable trim spaces (Windows only)

When a character field is read from an ODBC data source, some database engines will pad the field with spaces up to the length of the field. To compensate for this CA Plex (and Websydian) removes trailing spaces before displaying the field value.

If the database engine used does not pad character strings or if the trailing spaces should be sent to the HTML page, a new option (Trim trailing blanks) has been introduced that disables the removal of trailing spaces.

Disable read of path information from configuration file

By default the PageGenerator function finds the path to the template files in the platform specific configuration file (INI file, property file, or data area).

It is possible to disable this functionality by specifying the following option on the PageGenerator function:

The path should then be specified in the field Document<DocumentPath> in the edit point 0 Set path.

Full-load of grid data

In some cases, you want to load all available data to the grid - this is for instance relevant if the grid page is used to load a dynamically loaded drop down box, or if you know that there is a limited number of records.

This has always been possible, by specifying the max value for the field WsyGrid<GridCount> in the edit point Before loop in Grid.

To make this easier, an new option "Full grid load" has been introduced in Websydian 6.1.4.

To force a full load of the grid specify:

For WebsydianExpress, note that if your template contains a replacement marker specifying the grid length, the length specified in this replacement marker is used.