Common approach to building client side human services and associated problems
The most common approach to building client side human services (CSHS) is to directly place script or server call steps¬†in the service diagram. The script steps usually perform the following:
- script step A: initialize CSHS variables,
- script step B: respond to a specific control event and update CSHS variables,
- script step C: process server call step,
- script step D:¬†respond to a specific control event and update CSHS variables,
It is important to note that the contents of the above script steps are not part of an object, but are standalone and do not share any common functions.
Such simplicity may be inviting to apply and not much consideration is required to start development, but it will only work when there are no more then a few steps required to implement a CSHS. For real world applications, sooner or later such an approach will result in an implementation which no one can understand and maintain, especially if a CSHS was implemented by more than one developer. For example:
Each of the yellow script steps above¬†contains a code fragment; when the number of¬†script steps¬†in a CSHS becomes large, it is practically impossible to update either one without affecting every other script step. When performing updates,¬†a developer must first review each script step, remember what it does and how it must be changed, implement the changes and test them. Adding new steps may also be difficult because the real estate may simply not be available, as in the above example.
The end result is thus time consuming and extremely error prone to maintain.
Could there be a better approach to building client side human services?
A possible better approach to building CSHS is to apply some kind of a model-view-presenter design pattern. We already have a model (CSHS variables) and a view (coach), the only thing missing is a presenter. While¬†a CSHS is itself a kind of a presenter, it is not object-oriented, and an experienced developer would prefer to have at least the presenter as an object and not as a diagram.¬†In what follows we will specify a better design compared to the commonly used one. An important design consideration¬†is that loading CSHS from saved context must be supported.
The design pattern consists of the following main tasks:
- CSHS diagram design pattern definition,
- presenter definition,
- mapping of diagram steps and presenter functions.
The first task¬†is to define a common design pattern for¬†CSHS diagrams:
The above diagram contains the following design elements:
- the “init” script step will initialize the presenter,
- the “refresh” script step will mostly deal with updating the visibility of view elements,
- control event handlers handle button clicks and similar¬†(e.g. handleButton1, handleButton2),
- all control handlers which don’t complete the task are placed one below another, flow from right to left and are joined with the “refresh” step – see the green arrow,
- control handlers which complete the task should flow from left to right towards the “End” event, as per the red arrow.
The third task is to map diagram steps and presenter functions:¬†
Definition of the “refresh” script step:
¬†An example of control handler script step:
The step name should¬†reflect the presenter’s function used.
What is the experience with the explained approach?
The experience with the explained approach is that it brings the following benefits:
- Increased CSHS diagram readability,
- adding additional¬†diagram steps does not require a developer to rearange existing steps – simply add new steps below existing steps,
- if it is necessary for a view to respond to control handlers or data changes, this may be handled in the “refresh” step, in addition to the code already in other steps,
- the entire, or most of the, CSHS code is available in one location, making it easy to comprehend, maintain and test,
- if a particular control handler’s path should save the context of a CSHS (the wire leading to the “ToRefresh” gateway has the “Save execution context” option enabled), the suggested approach supports this requirement – the restored CSHS will continue directly to the “init” step where the presenter object will be recreated,
- increased reliability of client side human services.
It is possible to define the presenter object directly in the CSHS “tw” context variable, where it can be used the same way as explained:
Such an approach does not change the default security exposure of CSHS, but it is unpredictable in a sense that, while it may be working in BPM 188.8.131.52 and BAW 184.108.40.206, this may change in future releases. So I have opened a RFE requesting for the current behavior to remain the same in future releases, or that some other approach is suggested:
Please make sure to vote for the feature request.
Author: Aleksander Kovańć