Leveraging the template pattern for data instances

A number of ways exist to leverage the Template Pattern when dealing with Data instances. A common example is when a Data class at the enterprise layer declares the class of a Work page as Work-Cover-. The Enterprise layer should not be aware of any applications within layers above it so should never declare a Work page a class using <Org>-<App>-Work.

When this is done a Work page of class <Org>-<App>-Work-XYZ would exist on the Clipboard. For simplicity, suppose case XYZ contains an enterprise-level field group property. The <Org>-<App> application has had no reason to extend the field group’s <Org>-<Data> page class to <Org>-<App>-<Data>. The <Org>-<App> application could do this if it needs to, but for this example, it would add unnecessary complexity.

Case XYZ asks its enterprise-level field group to perform an action, for example apply a data transform. The enterprise-level data transform does something, then wants to have the Work page do something as well, for example execute an activity or data transform. At the enterprise level that activity or data transform only needs to be defined, i.e., stubbed out; it does not need to execute any code. The application does not need to override that activity or data transform if not required. If it does, the code in that activity or data transform would be executed, perhaps updating the same case that had asked the enterprise-level field group to perform an action.

The solution provided in the mission contains an example that goes a step further by enforcing what rules can be overridden and which cannot. The example is the CreateOrUpdateLocation flow called twice from the Data-Portal AppConfigContainer Section; one Link for Hotels, another for Venues. The CreateOrUpdateLocation flow is launched in a modal dialog. The work pages behind modal dialog, D_RoomsRequestTempCase and D_BookEventTempCase, are declared temporary since they should not be persisted. What should be persisted is either a new or existing FSG-Data-Location, i.e., the base class for FSG-Data-Hotel and FSG-Data-Venue.

Below is the Work- CreateOrUpdateLocation templated screen flow. Because CreateOrUpdateLocation is a screen flow, it can only call another screen flow, here one named SaveLocation.

Unlike CreateOrUpdateLocation, the SaveLocation flow is non-Final meaning the FSG-Booking-Work-Event case type class and the FSG-Hotel-Work-RoomsRequest case type class are allowed to override it. The RoomsRequest case overrides the SaveLocation flow by specifying D_HotelSavable as the name of the Savable Data Page to use. The BookEvent case overrides the SaveLocation flow by specifying D_VenueSavable as the name of the Savable Data Page to use.

The table below shows the Template Pattern in action. The consumer of the CreateOrUpdateLocation is free to extend it to a new and different class that extends FSG-Data-Location. The consumer only needs to override the five low-complexity rules on the right.