Changed Component Templates

Most of the component templates that were created for the 2-tier version of these development guidelines have been upgraded to 3-tier by making changes to the trigger code but by keeping their basic structure intact. However, some component templates have required changes to their structure (the number of entities and their relationship to each other) in order to cater for the needs of the revised Presentation Application Model (PAM).

LIST_5

This type of presentation layer component requires a session service of Type 3. This deals with an entity structure in the BAM that is shown in figure 1:

Figure 1 - a ONE-to-MANY-to-ONE relationship in the BAM

In this structure there can be zero or more occurrences of the MANY entity for each pair of occurrences from entities ONE(A) and ONE(B). The different occurrences of MANY are usually sorted by something such as date or time.

This presentation layer component has an OUTER entity, which can be either of entity ONE(A) or ONE(B), and an INNER entity which is used to maintain occurrences of the MANY entity. This structure is as shown in figure 2:

Figure 2 - the structure of a LIST_5 component

Here the INNER entity is constructed as follows:

It contains all the details of the existing MANY entity.
It contains whatever fields from entity ONE(B) that need to be displayed.

In this type of component the OUTER and INNER entities are retrieved independently, so each will have their own DTD and session service. The OUTER entity will have the code #include STD:READ_SINGLE in its <read> trigger, while the INNER entity will have #include STD:READ_SEVERAL.

When this presentation layer component is displayed it will show a single occurrence of the OUTER entity plus all available occurrences of the INNER entity. As the INNER entity is a combination of entities MANY and ONE(B) it may be possible that some details are blank if there is no occurrence of MANY. If there are several occurrences of MANY then only the details from the first occurrence can be shown - the sort sequence contained in $ORDER_BY$ will determine which is the first occurrence in the hitlist.

NOTE: Entity ONE(A) in the session service must be defined as entity OUTER in the presentation layer component that uses this session service. If another presentation layer component requires entity ONE(B) to be the OUTER entity then this will require an additional session service of the same type with entities ONE(A) and ONE(B) reversed. This will also require a different PAM entity for INNER which defines the additional session service as its Object Service.

MULTI_4a

This type of presentation layer component requires a session service of Type 2. This deals with an entity structure in the BAM that is shown in figure 3:

Figure 3 - a ONE-to-MANY-to-ONE relationship in the BAM

In this structure the MANY entity consists of nothing more than a primary key which is a combination of the two foreign keys. If an occurrence of MANY exists for a particular combination of the two foreign keys then it indicates that a link exists between those occurrences of the two foreign entities - if no occurrence exists then there is no link.

Figure 4 - the structure of a MULTI_4a component

Here the INNER entity is constructed as follows:

The primary key combines the foreign key to entity ONE(A) with the foreign key to entity ONE(B).
It contains whatever fields from entity ONE(B) that need to be displayed.
It contains a checkbox called ACCESS_FLAG which indicates if an occurrence of entity MANY exists or not.

When this presentation layer component is displayed it will show a single occurrence of the OUTER entity plus all available occurrences of the INNER entity. On each INNER occurrence will be a checkbox which indicates if an occurrence of entity MANY exists or not for that combination of OUTER and INNER. The only action that the user can take before pressing the OK/SUBMIT button is to set the various checkboxes ON or OFF.

MULTI_4b

This is similar to the screen layout for MULTI_4a, but with the addition of a profile area, as shown in figure 5:

Figure 5 - the structure of a MULTI_4b component

The profile area allows different subsets of the INNER entity to be retrieved for maintenance.

MULTI_5

This type of presentation layer component requires a session service of Type 4. This deals with an entity structure in the BAM that is shown in figure 6:

Figure 6 - a ONE-to-MANY-to-ONE relationship (with dynamic list) in the BAM

The component is actually constructed using the structure shown in figure 7:

Figure 7 - the structure of a MULTI_5 component

Here entities MANY and LIST correspond to MANY and LIST(B) in the BAM. OUTER and INNER can correspond to either ONE(A) and ONE(B), or reversed as ONE(B) and ONE(A).

In this type of component the OUTER and MANY entities are retrieved independently, so each will have their own DTD and session service. The OUTER entity will have the code #include STD:READ_SINGLE in its <read> trigger, while the MANY entity will have #include STD:READ_SEVERAL. The DTD for MANY must include INNER and LIST in the relationship MANY-to-INNER-to-LIST as in this structure these three entities form a single unit and data for all three will be contained within the XML stream.

If two variations of this component are required, one with entity ONE(A) as INNER and another with ONE(B) as INNER, then each variation must have its own DTD. As the DTD will be linked to the MANY entity this means that different variations of MANY must be defined in the PAM.

The ACTION BAR in the component structure will include an ADD button which will allow a new occurrence of INNER to be retrieved. This will cause the associated occurrences of LIST to be displayed with their ACCESS_FLAGs set to the <initial_setting> as defined in the Type 4 session service.

MULTI_5a

This is no longer required as it can be handled by a MULTI_5 component.

http://www.tonymarston.net