There has been a request to allow a workflow to explicitly set the advance level of a View independently of the main Advance Level Control in the top-level View. This override advance level would then propagate down to all children Views until the next advance level override is encountered.
In the current design, the advance level information is actually stored at the UIManager level and not in the Views themselves. This was done to ensure that the current advance level was consistent between all of the Views being displayed.
In order to support this design change, the advance level information will need to be moved into the BaseView class and out of the UIManager. The new api would be:
- setLocalAdvanceLevels(…)
- unsetLocalAdvanceLevels()
- localAdvanceLevels(…) const
This information could be store in the View Configuration and therefore would be persistent across runs. If these methods are called on the top-level view and if it is displaying the Advance UI controls, they would get updated appropriately.
The next step is how this information would get propagated down to the View display hierarchy. One approach would be to add a method to return the current advance level which is either localAdvanceLevel (if set) or its parent’s advanceLevel via recursion. A more efficient approach might be to change the updateUI API to include a version that takes in the advanceLevel to be used as shown below:
- updateUI() - updates the View (and its children) using its localAdvanceLevel if set or don’t filter by advance level if not.
- updateUI(int readLevel, int writeLevel) - update the View (and its children) using its localAdvanceLevel if set or using the advance levels passed in if not.