Examining the UPC Framework

Today I started looking into making changes to Microsoft's User Process Component Application Block. I am writing this blog entry so that I can remember what I have learnt...

The framework is as appears in the image here (from the UPC Application Block help).

As you can see, the UPC block centers around the idea of screen navigation. The coordinating class (in terms of the block) here is the Navigator. Developers provide the functionality for the Application (Your Application) the Controller (Your Controller) and the views (Your Views). The Navigator coordinates the transition between views.

One error on this diagram is the link between the Controller Base and the State. This is actually contained within the Navigator (i.e. the ControllerBase asks the Navigator for the State information). So the Navigator contains the state.

The navigator is loaded based on the information in the navigationGraph node in the Config file, or from the use of Open Tasks.

Goal: Remove the link from Your Views to Your Controllers.
Reason: Increase the reusability of Your Views, and the flexibility of Your Controllers.

Ideas:
Views have a specific purpose. Views can use and store information in State objects. A View which is accepting information from the user should store the supplied information in the State before propogating action requests.

Views can initiate actions (i.e. button clicks). Actions are received by a framework component and routed to the Controller, thereby avoiding the direct connection. The view has access to the Navigator (also not in the diagram), and so this can act as the Coordinator.

Concentrating on the Navigation Graph style for the moment:
Currently the graph has Nodes that have navigateTo links. These specify the destination view for a given action. For example:

<navigationgraph>
    <node view='Form1'>
        <navigateto navigatevalue='next' view='Form2'/>
    </node>

    <node view='Form2'>
        <navigateto navigatevalue='previous' view='Form1'>
        <navigateto navigatevalue='finish' view='Form3'/>
    </node>
</navigationgraph>

My thoughts so far suggest to replace navigateTo with a trigger node that contains one or more actions:

<navigationgraph>
    <node view='Form1'>
        <trigger value='next'>
            <navigateTo view='Form2' />
        </trigger>

    </node>
    <node view='Form2'>
        <trigger value='previous'>
            <navigateTo view='Form1'/>
        </trigger>

        <trigger value='finish'>
            <controllerAction name='updateDatabase' / >
            <navigateTo view='Form3' />
        </trigger>
    </node>

</navigationgraph>

The data for the 'updateDatabase' action would be taken from the tasks associated state information.

This allows the actions on the controller to be configured rather than hard coded.