|
|
Ever wanted to remove/hide/disable the update button or any other buttons (event) from some of your users. Now this is possible using the new Authorized events feature of WebsydianExpress v3.0.4.
With Authorized events, you are now able to add roles to specific events (buttons), thereby identifying which roles are allowed to access specific features (like the update) inside your business process.
For further information on how to achieve this, read the document "Authorized Events".
In WebsydianExpress 3.0, a change to the inheritance for the functions used by WSYUTIL/WebEditDialog had changed the WSYAPI/WebEditDialogForProcess pattern so that e.g. the Delete, Insert, and Update eventhandlers would call WSYUTIL/WebEditDialog.WebEditSuite.GridPage instead of calling WSYAPI/WebEditDialogForProcess.WebEditSuite.GridPage.
This inheritance has been removed in version 3.0.4.
If you have generated and built any functions that inherits from the WebEditDialogForProcess pattern at level 3.0, you must regenerate and build these functions after updating the Websydian pattern libraries to 6.1.4 (and WebsydianExpress to 3.0.4).
The %LEN scriptmarker, which can be used to limit the number of characters that is shown for the following replacement marker was not evaluated correctly.
If you want to use the %LEN scriptmarker in a PageGenerator, you must regenerate and build the PageGenerator function.
In all previous versions, the DocumentTemplateGenerator function inherited from the scoping PageGenerator function. This inheritance made it possible to retrieve information from the PageGenerator so that the template could be generated.
This inheritance had the unfortunate side-effect that every time you scoped anything under the PageGenerator, a corresponding "ghost object" would be created under the DocumentTemplateGenerator function.
Due to improvements in Plex's meta statements it is now possible to retrieve the necessary information without having to have the inheritance - so to get rid of the "ghost objects", this inheritance has been removed in this version.
This means that if you have made local modifications to functions inheriting from DocumentTemplateGenerator, you must check whether the changes still work.
There are three major issues to check - as these issues already have been handled in the abstract DocumentTemplateGenerator function, you only have to check your local modifications.
For two of the issues, you will see that the meta variable WSYBASE/+PageGenerator is used. The abstract DocumentTemplateGenerator sets this to the PageGenerator that scopes the DocumentTemplateGenerator. You can use this anywhere in the DocumentTemplateGenerator when you want a meta variable that refers to the PageGenerator.
Take a copy of a local model before upgrading - any necessary changes to the code is far easier when you can see how it looked before the update.
One of the most common tasks of the DocumentTemplateGenerator functions is to process fields found in a local variable. As long as DocumentTemplateGenerator inherited from the PageGenerator, the variables were available in the DocumentTemplateGenerator and could be processed directly.
After removing the inheritance, the variables are no longer present in the DocumentTemplateGenerator - so the meta code processing the fields must be changed so that the variables of the PageGenerator are accessed.
If you have this issue, you will get error messages in the Plex message log when opening the DocumentTemplateGenerator function as variables that no longer exists in the function is referenced.
Note that the meta code shown in these examples can be used with any variables - not just WsyDetails and OmitDetailsFields.
The meta code:
+For Each Field WsyDetails
...meta code handling the fields in WsyDetails
Must be converted to:
+++Define Field: FIELDS/+Variable
+++Define Variable: WSYBASE/WsyDetails
+For Each Variable .Local, Field: WSYBASE/+PageGenerator
+++Set Value To Current Field: FIELDS/+Variable
+If EQ Field: FIELDS/+Variable, Variable: WSYBASE/WsyDetails
+For Each Field
...meta code handling the fields in WsyDetails
In many cases you will find structures like this:
+For Each Field WsyDetails
+++Undefine Field: WSYBASE/+FieldIsHidden
+++Set Value To Current Field: WSYBASE/+FieldName
+For Each Field OmitDetailsFields
+++Set Value To Current Field: WSYBASE/+FieldName2
+If EQ Field: WSYBASE/+FieldName, Field: WSYBASE/+FieldName2
+++Define Field: WSYBASE/+FieldIsHidden
This meta code goes through all the fields in WsyDetails, for each field it is checked whether the field is in OmitDetailsFields - if it is, the meta variable +FieldIsHidden is defined.
This must be converted to:
+++Define Variable: WSYBASE/OmitDetailsFields
+++Define Variable: WSYBASE/WsyDetails
+++Define Field: FIELDS/+Variable
+For Each Variable .Local, Field: WSYBASE/+PageGenerator
+++Set Value To Current Field: FIELDS/+Variable
+If EQ Field: FIELDS/+Variable, Variable: WSYBASE/WsyDetails
+For Each Field
+++Undefine Field: WSYBASE/+FieldIsHidden
+++Set Value To Current Field: WSYBASE/+FieldName
+For Each Variable .Local, Field: WSYBASE/+PageGenerator
+++Set Value To Current Field: FIELDS/+Variable
+If EQ Field: FIELDS/+Variable, Variable: WSYBASE/OmitDetailsFields
+For Each Field
+++Set Value To Current Field: WSYBASE/+FieldName2
+If EQ Field: WSYBASE/+FieldName, Field: WSYBASE/+FieldName2
+++Define Field: WSYBASE/+FieldIsHidden
If you look closely at this, you will see that this is just two separate cases of the previous example - first the conversion for WsyDetails is performed - then the conversion for OmitDetailsFields.
When the DocumentTemplateGenerator inherited directly from the PageGenerator function, the inheritance meant that it could access the function options that were specified for the PageGenerator.
As the inheritance has been removed, the DocumentTemplateGenerator only has the options that have been set specifically for the DocumentTemplateGenerator (to override options from the page generator or as options that only relates to the DocumentTemplateGenerator).
If your code checks for function options that belong to the PageGenerator, you must enclose the code in a meta loop that specifies a meta variable that refers to the PageGenerator as the current object.
As the meta code doesn't generate any warnings if the options are missing, you must inspect your local modifications to the DocumentTemplateGenerator to check if any function options are retrieved from the PageGenerator.
You must check all "+For Each Property FNC option NME" statements.
This code checks for the function option "Generate Start And End" - but the changes are the same for all options.
+++Define Field: WSYBASE/+GenerateStartAndEnd
+++Define Name: WSYBASE/Generate start and end
+++Define Field: FIELDS/+Name
+For Each Property FNC option NME
+++Set Value To Current Field: FIELDS/+Name, .Target
+If EQ Field: FIELDS/+Name, Name: WSYBASE/Generate start and end
...Handle function option
It must be changed to:
+++Define Field: WSYBASE/+GenerateStartAndEnd
+++Define Name: WSYBASE/Generate start and end
+++Define Field: FIELDS/+Name
+For Defined Value Field: WSYBASE/+PageGenerator
+For Each Property FNC option NME
+++Set Value To Current Field: FIELDS/+Name, .Target
+If EQ Field: FIELDS/+Name, Name: WSYBASE/Generate start and end
...Handle function option
The addition of the +For Defined Value Field: WSYBASE/+PageGenerator statement ensures that the option is retrieved from the PageGenerator instead of from the DocumentTemplateGenerator.
If you have made your own local modification to the DocumentTemplateGenerator functions, you might be using fields that have been added to the PageGenerator instead of to the DocumentTemplateGenerator.
The fix is simply to add the field to the variable specified in the error message. In rare cases the variable itself might be missing - you fix this by adding the variable to the DocumentTemplateGenerator followed by adding the fields to the variable.
You will receive an error message in the Plex log when opening the action diagram for the DocumentTemplateGenerator if you have this issue.
This information is only concerns the WinC (MSXML) version of TransacXML and Windows variants of WebsydianExpress
As of this version, Websydian TransacXML and WebsydianExpress will use the MSXML 6.0 parser instead of the MSXML 4.0 parser.
We change to MSXML 6.0 as this is a Microsoft recommendation - and because we see more and more servers where only MSXML 6.0 is installed.
This change will have no effect on your application and you do not have to regenerate/rebuild anything.
The change is done simply by replacing WsydXml11.dll with the one delivered as part of the upgrade objects for WebsydianExpress this is done by following the upgrade guides on how to upgrade to WebsydianExpress v3.0.4.
Before doing so, remember to check whether you have MSXML 6.0 installed.
You can do so by going to Control Panel→Add or remove programs, and check whether you find the MSXML 6.0 parser in the list.
Please visit the Microsoft site for details on downloading and installing MS XML v6.0
This only concerns Java applications deployed as a servlet (the J2EEProxy feature).
Note that this means that it is relevant for the standard installation of WebsydianExpress for Java.
Two new options have been introduced for the j2eeProxy property file (Follow the link for further explanation of the properties).
Online documentation - WebsydianExpress v3.0