|
|
In version 2.5 of Websydian, the Websydian pattern libraries has been moved to CA Plex version 4.0 (CA Plex 4.0a, build 130 to be precise!). Computer Associates no longer actively supports CA Plex 3.5 and by the time writing, all Plex customers have been advised to move their development models to version 4.0 or 4.5 of CA Plex.
A number of new patterns and facilities have been added to Websydian in version 2.5 of the product. Most of the new patterns and facilities have been added to the existing Websydian Utility module.
Presentation Control is a new Websydian module which is aimed at multi-lingual web applications where HTML pages and error messages must appear in different languages. In addition, the Presentation Control module may be used in situations where browser specific content must be sent to the client browser.
The XmlGenerator pattern provides the ability to specify a special kind of Websydian 'Page Generators' which generate XML documents. Generating complex XML documents will involve a nested structure of such XML Generators.
The MultipleInputGrid pattern makes it possible to specify a single Event Handler which receives as input several rows in a Grid table. In this way, it is possible to specify functionality which updates or creates several rows in a Grid table by one press on the Event Handler push button.
The Parent and Child Page Generator patterns are used to implement Websydian functionality where Page Generators are calling other Page Generators in order to produce extended documents. As an example, the patterns can be used to implement drop-down boxes populated with table data.
The PageGeneratorWithErrorList pattern is used in case of failed validation, where the generated error message(s) will be merged with the original page on which the erroneous data were entered. The input values from the failed request are preserved and in this way, the user will be able to correct the error(s) and resubmit the request.
It has always been possible to encapsulate Websydian application pages in a frame document. With the new FrameSetPageGenerator pattern, it is now possible to model this directly in the Websydian application model and get Websydian to construct a FrameSet Document Template.
The ParameterStore pattern makes it possible to specify automatically saving and retrieval of parameter field values across different Websydian functions. In this way, parameters do not need to be specified as hidden input fields in order to be transferred from a Page Generator to an Event Handler function.
The Document Template Generator function has been extended to generate an error log file with the errors encountered during Template generation (see description). This way, a number of common error situations are detected when running the Document Template Generator. This is a very useful tool to catch errors during Websydian development.
Instead of using buttons on the HTML pages to trigger a Websydian Event Handler function, it is now possible to get the Document Template Generator to create a link instead (see description).
A BinaryPageGenerator pattern has been added to the Websydian Base module. This pattern can be used to send binary content to a browser, e.g. for specifying download functionality for binary files stored on the web server.
All known errors have been corrected in Websydian version 2.5.
Nested page generation is when Page Generators call other Page Generators in order to generate complex documents. In earlier versions of Websydian, a work-around was needed when implementing nested Page Generators on the iSeries web server platform. In Websydian version 2.5, no work-arounds are needed when specifying nested Page Generators on iSeries platform.
Characters in a position that is dividable by 1024 on a single line were mistakenly removed when the line was sent to the browser. This bug has been fixed so that long lines now are sent correctly to the browser.
When a session could not be created, the WAP Dispatcher function would generate an HTML error page rather than a WML error deck. This bug has been fixed now.
There is now full support for structured fields in Websydian.
A line break generation error in the replace module (WSYDREPL) has been fixed.
Previously there was a limit of 256 character as the maximum number of characters per line sent to the web browser. This limitation has now been removed so the lines in the Document Template can contain any number of characters.
The HTML templates generated and used by Websydian are now compliant with the HTML 4.01 standard from the W3C organization. The only exception to this rule is the AUTOCOMPLETE attribute used in the FORM tag. This attribute is inserted for security reasons.
The EventHandlerWithValidation building block now also calls the meta view validation function (Meta.ValidateView) when it validates the fields in WebInput variable.
When the Dispatcher function contains calls-triples to Event Handler functions that are set to implement No, no call statements will be included in the generated code.
Previously, the Document Template generation would give strange results if a field had no type triple. Now, it is assumed that the default type is Character if no triple is specified.
These commands have been changed so that it is no longer necessary to include the application library in the library list when executing the WSYDCRTQ and WSYDCRTRQ commands.
A hidden field with a displayed as-definition will no longer be generated in the HTML input form. This is because a field of this type will receive its value from the scoped displayed as-field rather than from the Page Generator field value.
When a field did not have an implementation name, Websydian would not work because the field’s implementation name is used as the replacement marker name. Now, Websydian will use the surrogate name of a field if no implementation name has been specified.
This section lists modifications made to the internals of Websydian.
These API calls have now been changed so they both expect the position field to be a one-based index. Furthermore, the API calls have been wrapped into an internal CA Plex function.
The inheritance path of this object has been changed so it inherits directly from the WebShell pattern, and the code that sends the HTML page to the browser is inserted into this function rather than inherited.
The Start read document and End read document edit points are no longer available in the CardGenerator and DeckGenerator functions.
The initialization of the WsyDetails<SessionId> field is moved from the 0 Process input pre point to the Start initialize pre point.
The call to the Fetch detail subroutine has been moved from the Process input pre point to the End initialize post point.
A WsyDetails = Input assignment has been inserted into the 0 Process input pre point.
The following changes have been applied to the inheritance path structure of the EventHandler and the PageGenerator patterns.
The ReadDocumentTemplate and WriteHtmlPage functions have been merged into the ReplacementProcess function. This includes action diagram code, edit points, and triples.
The ReadTemplateFromFile and WriteHtmlPageToCgi functions have been removed from the inheritance path, and the functionality in these function has been moved into the new SendHtmlPage and ReadHtmlPage functions. These new functions are now called by the PageGenerator function. All edit points have been preserved in the PageGenerator.
The WriteHtmlPageToFile function has been removed from the Websydian model.
This should not result in any upgrade problems since the abstract functions in the inheritance path that is removed is not likely to have been used in existing projects.
The following changes have been applied to the Event Handler structure:
The code in the EventHandlerShell function have been merged into the WebShell function.
Most of the functionality in the ParseInput function has been separated out in a GetRequestInfo function. This has the effect that some edit points will be removed from the ParseInput function. These edit points are:
Do post
After post PC
Do get
After get PC
After post iSeries
After get iSeries
This should not be a problem, since the ParseInput function is only used by the Dispatcher function and the edit points above are not likely to have been used in any applications.
Most likely, no changes will be necessary when upgrading a Websydian model from version 2.1 to version 2.5. See the Upgrade Guide to Version 2.5 technical paper for the circumstances in which to do minor modifications when migrating a Websydian model from version 2.1 to 2.5.
Online documentation - Websydian v6.5