|
|
Introduction Implementing Other Uses Parts
Applying the basics of the WsyStructure pattern is done similarly to applying the BSTRUCTURE/_Structure pattern.
Example:
| MyNodeStructure | is a ENT | WsyStructure |
Follow the steps described in the To define the basic entities section in the Implementing _Structure help page of the CA Plex documentation. To implement the Windows GUI portion of the _Structure pattern, see the To define a basic user interface section in the Implementing _Structure help page of the CA Plex documentation.
All references to the SessionControl.Data.Session entity need to be replaced with references to the implemented Session entity:
Example:
| MyNodeStructure | replaces ENT ...by ENT |
SessionControl.Data.Session MySessionManagement.Data.Session |
The ExpandedLink entity has a derived NodeDisplayName field which is assigned a value by the GetNodeDisplayName function scoped under the field. The action diagram logic of this function must be specified, i.e. to retrieve a value for the NodeDisplayName field.
The simplest way to implement such a display value is to specify one or more description or name fields from the Node entity as virtual fields on the ExpandedLink entity. The virtual fields will then be present in the Fetch view and they can now be specified as input to the derivation function.
Example:
| MyStructure.Data.ExpandedLink | refers to ENT ...for QLF ...virtual FLD |
MyStructure.Data.Node Child MyNodeName |
| GetNodeDisplayName | input FLD | MyNodeName |
Be aware that the Node entity may be replaced with another entity.
The fully scoped name of the derivation function in the example would be MyStructure.Fields.NodeDisplayName.GetNodeDisplayName (the derivation function already receives the NodeDisplayName field as dual input).
Only one line of action diagram code is needed to set the value of the NodeDisplayName field by the GetNodeDisplayName function:
Cast MyStructure.Fields.NodeDisplayName>, Input<MyNodeName>
The NodeList Page Generator function displays the sub-node records of the selected node. The listing is based on the Link.ByParentChild view which by default contains only the key of the Node entity.
Again, virtualization may be used to retrieve the relevant description fields from the Node entity. Now, all fields can be omitted from the grid except the (virtual) fields that need to be displayed in the list:
Example:
| MyStructure.Data.Link | refers to ENT ...for QLF ...virtual FLD |
MyStructure.Data.Node Child MyNodeName |
| MyStructure.Web.NodeList | local VW ...for VAR ...omits FLD ......for QLF |
MyStructure.Data.Link.ByParentChild OmitGridFields MyNodeName Child |
Be aware that the Node entity may be replaced with another entity.
If virtual fields are defined as specified above, the other Link.ByChildParent view should be set to containing only real attributes as this view will not need the virtualization.
When a Node is selected (from either the Menu list or the Node list), two different actions are possible. Either the Node has sub-Nodes and in this case, the list of sub-Nodes should be displayed. Or, the Node is a leaf-Node and another page should be shown instead.
If the type of Node is specified as an attribute on the Node entity (or the Entity replaced), a look-up in the database will be needed to solve out which Page Generator to be called.
The code must be specified in the GenerateDetails Event Handler function as it is the function reloading the two frames.
Example: (pseudo code)
Action diagram: MyStructure.Web.StructureFrameSet.GenerateDetails
Edit point: 0 call to build of documentCall [Function to look up type of Node record]
If [Node has sub-Nodes[
Go sub Build node list
Else
Call [Other Page Generator]
A Build node list subroutine has been specified which will call the NodeList Page Generator function with the correct parameters.
In order for the Menu list to be generated correctly, it is necessary to create a record in the ExpandedLink table representing the Root Node in the structure. Such a record must be created for each new Session being started up in the application.
One possible place to put the action diagram code implementing this creation is in the 0 After session creation edit point in the Data.Session.Update.CreateSession function of the implemented Session Management entity.
Example:
Action diagram: MySessionManagement.Data.Session.Update.CreateSession
Edit point: 0 After session creationCall MyStructure.Data.ExpandedLink.Update.InsertRow
Map with the key field(s) of the root Node record and with the SessionID returned from the Session.Update.InsertRow function. Map the DisplayLevel parameter with *Zero and specify a blank reference for the Link key field(s) as well.
The specified call can also be applied elsewhere as long as it done before the user enters the Structure frame set.
Often, a standard abstract Page Generator and an abstract Event Handler function have been defined that all implemented Page Generators and Event Handlers in the model inherit from. If this is the case, this inheritance should also be specified for the Page Generator and Event Handler functions scoped under the Web function suite under the implemented Structure pattern.
In the same way, each of the inherited Event Handlers must be declared by calls-triples from the Dispatcher function.
Remark that the Web.MenuList.Next and the two Position Event Handlers are set to implement No.
Before you can run the Structure frame set, you need to do the following:
Online documentation - Websydian v6.1