Online documentation - Websydian v6.0

Users Guide | Patterns Reference | WebsydianExpress | Search
 

Implementing the WsyStructure Pattern

Introduction    Implementing     Other Uses    Parts

Define Inheritance and Basic Entities

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 AllFusion 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 AllFusion Plex documentation.

Replace Reference to Session Entity

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

Specify GetNodeDisplayName Derivation Function

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>

Specify Fields in Node List

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.

Call Page Generator from Select Event Handler

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 document

Call [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.

Create ExpandedLink Record for Root Node

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 creation

Call 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.

Inherit from Standard Layer and Declare Event Handlers

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.

Implement and Run the Structure Functionality

Before you can run the Structure frame set, you need to do the following: