|
|
Users Guide | Patterns Reference | WebsydianExpress | Search |
|
|
Users Guide | Patterns Reference | WebsydianExpress | Search |
This upgrade guide is aimed at development sites that have already built AllFusion Plex models based on Websydian 2.5 and want to move those to Websydian version 3.0x. If the AllFusion Plex model is based on a Websydian version prior to 2.5, the upgrade guides for these versions should be read and the guidelines in all the upgrade guides applied.
A number of changes have been made to the internal structure of Websydian, but these changes should not affect existing Websydian applications unless they have been using any of the internal parts of Websydian. Go to the Minor Modifications section of the Websydian Version 3.0x - What Is New? document to get an overview of all internal changes.
Upgrading from Websydian 3.0 to Websydian 3.01 - Build 4 requires no additional action beside extracting from the new libraries delivered. If developing for AS/400 make sure to install the wsyd300ptf library, which is delivered with the Websydian 3.01 - Build 4, on your AS/400.
The Grid Child option determines whether a Child Page Generator function is to be inserted and called from the Details or Grid region of the Parent page (and whether to map parameters with fields in the WsyDetails or WsyGrid variables).
The WSYUTIL/GridChild option is no longer used (has been renamed to GridChild_OLD). Instead, use the new WSYBASE/GridChild name object.
The above means that all Child Page Generator functions that has the Grid option specified should be updated to make use of the new name object. A Child Page Generator function is a function that inherits from ChildPageGenerator or a pattern based on ChildPageGenerator.
In the MessageStore pattern of the Presentation Control module, &-signs are now used instead of #-signs to specify parameter messages. If the MessageStore pattern has been used and messages have been defined to print out message parameters then the associated #-signs must be changed to &.
On the Windows platform, a Newline is represented by two characters: Carriage Return and Line Feed (ASCII characters x0D and x0A). When a file is read in text mode all Newlines will be converted from the two character representation to a one character presentation (Line Feed). Conversely, the Line Feed character will be converted to a Carriage Return - Line Feed sequence when data is written to a file in text mode.
Previously Websydian had read and written files in text mode, but with the introduction of PKA (Parallel Keep-Alive) this was causing problems as the PKA layer did not perform a similar conversion when data was sent to the Relay Service. Therefore, Websydian now opens and reads files in binary mode to get rid of the CR/LF conversion.
This change should only impact existing applications if one of the following things apply:
The scope structure of Page Generator functions is used by the Document Template Generator in order to retrieve information about a Page Generator and its associated Event Handlers.
'Old Scope' was the way that Page Generators and Event Handlers were structured in the very first versions of the Websydian product where a 'dummy function' was needed to scope each Page Generator together with (and at the same level as) the associated Event Handlers.
In version 3.0, the old scope of Page Generator functions and Event Handler functions are no longer supported. Page Generators structured in the old way will still run, but the Document Template Generator will not work properly.
Due to internal restructuring of the ReplacementProcess pattern, the WriteFirstPartOfString and WriteSecondPartOfString internal sub routines have been commented out from the ReplacementProcess function. These routines were previously used to implement the use of nested Page Generator functions. Any action diagram code placed in these internal subroutines must be moved.
Because of the changes to the ReplacementProcess function the following edit points now exists in a different context:
0 Before replacement of string
0 After replacement of string
1 After replacement of string
These edit points will only be accessed if a replacement marker was found. The name of the replacement marker can be found in Document<DocumentString>. In the edit point 0 After replacement of string the DocumentString field will contain the value the replacement marker is to be substituted with.
If you need to process everything that is read the edit point 0 After read of new string should be used. Remember to check in the Document<ReadDataType> field whether the DocumentString field contains plain text or a replacement marker name.
If code has been inserted into these edit points it should be reviewed to see if it still apply in the new context.
Websydian now uses the data area IFSCCSID to indicate which CCSID should be used to read the Document Templates. Default is set to 01252 (Windows, Latin 1).
Use the command
CHGDTAARA IFSCCSID
to set the value.
Further information on codepages can be found in the manual:
Title: AS/400 International Application Development V4R2
Document Number: SC41-5603-01
Build Date: 12/01/97 19:46:21 Build Version: 1.3.0
Book Path: /home/publib/epubs/book/qb3aq501.boo
Note that the Websydian character conversion table ASCII2E now is obsolete.
When upgrading to Websydian version 3.0, all Websydian Packages and application functions (Dispatchers, Page Generators, Event Handlers) should be regenerated and built. This is due to changed internal field lengths and parameter lists as well as the use of new internal functions.
Online documentation - Websydian v6.0