Page Flow : Processes and Sub Processes

Topics: Web Client Software Factory
Oct 27, 2006 at 10:42 AM
When I first looked at UIP (quite some time ago) I liked the idea of configuration driven page flow but found the implementation to be restrictive and complicated if you wished to define chained or sub processes.

So rather than coping with it we set about writing our own!

My main issues with UIP were,

- Definition of Sub-Processes?
- Passing state from one process to another was very manual.
- The valid page to page flow was configured but the configuration showed no concept of why the transition between views occurred. i.e. the transition type/name/reason
- Navigation calls needed to know the resulting view rather than just the exit path from the current node restricting reuse of a view in another process.

I'm sure there were more but we have managed to clear up most of them.

How will this page flow implementation differ, if at all?

Stephen ...
Oct 27, 2006 at 5:21 PM
Hi Stephen,

Great feedback, thanks. We're trying to take what we've learned from UIP and use the new capabilities in Workflow Foundation to provide a good experience around page flow.

Our first priority is to make sure we have the model right for our implemented features, then continue to expand the scope. Within the constant tension of scope/budget/schedule we want to make sure we have a good grasp of feature priorities. All that is to say we appreciate your feedback - it helps.

Definition of sub-processes. This is a UIP feature we'd like to keep and are looking into this.

Passing of state. Are you refering to passing of state between a parent page flow and a child page flow? What is your ideal scenario from a developer's perspective?

Configuration, reason for transitions. This will be page flow provider specific. Have you looked at the configuration for the Windows Workflow Foundatation? The definition of events and transitions is rich, and I think it may have what you are looking for.

Navigation calls needed to know the resulting view... Yep, this is something we started with, but changed it (still improving it) to support the kind of model you want. Your code can either specify MoveNext, which allows the page flow provider to determine the next page based upon configuration information, or you can specify Navigate(eventname), where eventname is the reason you are transitioning (and not a request for a specific view).

Oct 30, 2006 at 8:32 AM

I've posted on the Next/Navigate thread already this morning so I'll try and keep this one more concise.

I haven't had much of a play with the Workflow Foundation yet but I will have a look ASAP.

Passing of State - In UIP there seemed to be a very manual process of passing pointers to workitem state (can't remember the details) so that the contents could be pushed and pulled from one process to another. If I remember correctly this wasn't just for sub processes but for chained processes also. In our framework we have implemented State on a process by process basis but with the Application having its state exposed as the Global or Application state which every process can access.

Suspending of Tasks - I'm just going to add this one in while I remember, but in UIP there was the need to suspend the current task to start another (sort of related to the above point) and it was this mechanism that was used to pass state in and out of a task(?). With our framework we went for a Stack based approach with the Application process consistently acting as the stack base.

Glad to see the Navigate call is now taking the eventname rather than the step you ultimately want to go to. That being the case, is this really a "Navigate" now? Will all your events result in Navigation or will some return control of flow to the current page?

Navigate doesn't hold as a valid method name for us because all our logic is held in dynamically loaded commands and therefore return of control to the page is as valid as a transition.

Stephen ...