Online documentation - Websydian v6.0 |
Users Guide | Patterns Reference | WebsydianExpress | Search |
Introduction Implementing Other Uses Example Background
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:
Source Object | Verb | Target Object |
---|---|---|
WWW Change employee | local view VW ...for VAR ...contains SYS |
Employee.Update OmitDetailsFields Nonkey |
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.
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.
Some fields on a AllFusion Plex panel do not show the internal value of the field. Instead the value is mapped to the value object name representing the value. The fields in question are fields with one of the following triples:
Verb | Target Object |
---|---|
FLD control SYS | Check |
FLD control SYS | Radio |
FLD control SYS | List |
FLD control SYS | Combo |
This mapping is also done by Websydian. Every Page Generator function will automatically convert field values to value object names, whenever a field with one of the above triples is displayed in a WsyDetails region or WsyGrid region.
There may be situations where this functionality is not needed. This could for instance be if one does want the literal database values to be displayed. The value mapping may be suppressed by specifying the following triples:
Source Object | Verb | Target Object |
---|---|---|
MyPageGenerator | option NME ...value SYS |
WSYD Map literal values to names No |
Hidden status fields will not be affected by the specification above. Hidden fields will always be mapped with their literal value.
This option will add the replacement marker /(WSYDHIDDEN) in front of the replacement marker of the field in question. This indicates to the PageGenerator that the literal value is to be used.
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.
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
Source Object | Verb | Target Object |
---|---|---|
MyPageGenerator | option NME ...value SYS |
WSYD URL Encode Marked Data Yes |
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>
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:
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.
Edit Mask with a non-empty LP | Edit Mask with an empty LP | No Edit Mask defined | |
---|---|---|---|
Datetime field | Use the edit masks large property. | Use host system settings. | Use external parameter. |
Numeric field | Use the edit masks large property. | Construct an edit mask from the triples of the field. | Construct an edit mask from the triples of the field. |
Character field | Use the edit masks large property. | Use an empty edit mask (""). | No edit mask is used. |
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.
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:
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):
Source Object | Verb | Target Object |
---|---|---|
ReplacementProcess | variable VAR ...as SYS ...occurs NBR |
StringArray Local 128 |
The limit can be overridden by the individual Page Generator functions.
See the Parent and Child Page Generator Patterns page in the Utility Module. Generate a HTML file using the
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.
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.
Source Object | Verb | Target Object |
---|---|---|
MyPageGenerator | option NME ...value SYS |
Trim trailing blanks No |
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:
Source Object | Verb | Target Object |
---|---|---|
MyPageGenerator | option NME ...value SYS |
WSYD Read external path No |
The path should then be specified in the field Document<DocumentPath> in the edit point 0 Set path.