|
|
Users Guide | Patterns Reference | WebsydianExpress | Search |
|
|
Users Guide | Patterns Reference | WebsydianExpress | Search |
The structure of the Websydian product has been completely reorganized. From being a Web and WAP development tool, Websydian is now a product suite covering all aspects of todays corporate enterprise E-business. The Websydian development suite now contains the following five products:
The two first products - the Web Developer and the Wireless Developer are extensions of the former Websydian product with the Wireless Developer being augmented with full support for the I-Mode standard.
The remaining three products are brand new though the WebShop Developer makes use of the existing Websydian Shopping Cart pattern.
The Websydian PKA (Parallel Keep-Alive) interface is developed for high performance and scalability in Websydian applications. By applying the Websydian PKA interface, a Websydian application can be scaled by distributing the application on several application servers.
Due to the increased modularization, the PKA interface also makes it easier to deploy Websydian applications on different platforms - e.g. the web server could be an Apache running on a Linux box, the Websydian application could be executed on a pc platform connecting to an Oracle database on a Unix platform.
Server-side scripting is a popular approach to web application development. Therefore, web application development with server-side scripting is now fully implemented in Websydian.
Using the PKA (Parallel Keep-Alive) interface, Websydian applications can be generated and implemented in 100% pure Java. The Java code generation facility makes it possible to deploy Websydian applications on virtually any hardware platform.
A number of minor changes have been applied in the new version 3.0 of Websydian, most of these due to the redefinition of the Websydian product structure.
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.
In the MessageStore pattern of the Presentation Control module, &-characters are now used instead of #-characters to specify parameter messages. If the MessageStore pattern has been used and a message have been defined to print out message parameters then the associated #-characters must be changed to &.
The Websydian Packages have been restructured. From now on only the packages named xxxObjectsToGenerateAndBuild should be generated and built. These are the following packages:
Whether to generate and build the Win-, Rpg-, Pka-, and PkaWin packages depends on the implementation environment.
A new RPG version/level has been introduced and it must be selected when implementing applications on an AS/400 web server. The new version and level are used to give all fields in the Win/Java environment of type varying length a field length triple as required by the RPG generator.
The _DocumentTemplateGenerator function has been restructured in order to implement generation of script enabled Document Templates. If any Template Generator functions have been customized, it should be verified that the customized functionality still works as expected.
When a Document Template is generated by a Websydian Document Template Generator function, the Grid Marker (<!--/(Grid)-->) is no longer generated with an ending line break. This change has been possible because the ReplacementProcess function now only parses the Grid Marker itself as the start of the grid where as it previously was the whole line where the Grid Marker appeared that was seen as the beginning/end of a grid section and therefore removed from the final result.
This change will not affect existing Document Templates.
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.
The way the ReplacementProcess function produces the final output to the web server has been changed.
In Websydian 2.5 and prior versions, this function would read a block of characters from the Document Template (typically one line at at time) and then do a search and replace of all replacement markers found in the block read.
This has now been changed so that the read functionality now either returns a block of characters that contains no replacement markers or if a replacement marker is found only the name of that replacement marker. In the first case, the ReplacementProcess function simply streams the block returned from the read function to the web server and then reads the next block of data. In the second case, the ReplacementMarker function uses the returned name to find the value that should be returned to the web server.
This change removes the overhead of replacing data into the read block of characters thereby improving the overall performance.
The restructuring should not affect existing Websydian applications unless there has been made explicit use of the way the read function reads the Document Template, or read function specific code has been inserted in the Edit Points 0 Before replacement of string, 0 After replacement of string, or 1 After replacement of string.
Also, the WriteFirstPartOfString and WriteSecondPartOfString sub routines have been commented out from the ReplacementProcess function. These routines were previously used to implement the use of nested Page Generator functions. Instead use the Parent and Child generator functions in the Websydian libraries to implement this kind of functionality.
The ServiceFunctions.ConstructString function now come in two versions:
The WSYDREAD and WSYDSTDO run-time objects now comes in new versions named WSYDREAD30 and WSYDSTDO30.
PKA and Web Server support for AS/400 requires OS/400 V4R4M0 or newer. Note that there are no requirements on the operating system when using an AS/400 as e.g. database server.
In the AS/400 environment Document Templates can now be placed in any directory in the IFS (Integrated File System).
Websydian now uses a data area to indicate which CCSID should be used when Document Templates are converted from ASCII to EBCDIC.
The code for initializing the SessionID field in the Abstract.PageGenerator Session pattern has been moved from the Start initialize pre point to the End initialize post point in the SessionControl.Abstract.PageGenerator function. This has been done to ensure compatibility with the WebInsertPage and WebUpdatePage patterns.
This function has been extended so that it on a RPG platform uses the extra DocumentLength input parameter field to determine how many characters that are returned to the web server.
The Environment<*Returned status> field is now initialized to *Successful in the Read document line subroutine in the Page Generator function.
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 has 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.
The parameter list for the ReplaceString function has been appended with the CalculateLengthForValueSpace field. The ReplaceString function is no longer used due to changes in how the Page Generator function streams the generated output to the web server.
The Position field (now renamed to PositionWsyd) has been removed from the WorkFields and GridLoop variables and the MoreInstances field has been removed from the WorkFields variable. These fields are no longer used due to the internal restructuring of the ReplacementProcess pattern.
All meta functions used by the Websydian patterns have been scoped under the Meta function suite.
In order to prepare for stronger signing algorithms, the length of the WSYBASE/Signature signature field has been changed. In the Win/Java variants, the field is a varying length field whereas in the RPG variants, it has a length of 256.
The parameter list for the CRYPT.PGM run-time object has been changed accordingly.
The length of the DocumentName, DocumentPath, IniCharacterValue, IniDefaultCharacterValue, IniKey, and IniSection fields has been increased to 200 and the ErrorMessage field to 256 on the AS/400 platform.
On the Windows and Java platforms, these fields are set to varying length.
The Position field has been renamed to PositionWsyd and the MoreIinstances field has been renamed to MoreInstances.
All known errors in Websydian version 2.5 has been corrected in the new version 3.0.
This function has been fixed so that it now formats fields in the same way as the Event Handler function does. In this way, datetime fields are now converted correctly when the PageGeneratorWithErrorList function parses input parameters.
The MultipleInputGrid pattern has been fixed so that status field are generated correctly when they occur as multiple input fields.
A bug that caused the fields in the DisableHtmlCharacterConversion variable to be ignored has been fixed.
The Event Handler function Generate submit button as link option causes the event to be generated as a link rather than a submit button. In Websydian 2.5 this option did not work properly for grid events. This has now been fixed.
The Quantity field in the Shopping Cart module is now validated to ensure that users can not enter negative quantity values.
The Quantity field has been removed from the OmitGridFields variable of the WebCart.Services.WebListOwned function pattern.
Most likely, no changes will be necessary when upgrading a Websydian model from version 2.5 to version 3.0. See the Upgrade Guide to Version 3.0 technical paper for the circumstances in which to do minor modifications when migrating a Websydian model from version 2.5 to 3.0.
Online documentation - Websydian v6.0