To Simon Lessard - Usecase required for ER request

Question

Simon,
I received a notification for ER 7355435 I filed on your behalf posted long time ago in [ER] Add a way to decorate the current PageFlow
For some reason I didn't receive the follow up notification from the bug database and eventually today it got true. What we need is a usecase that you are trying to implement and that could not be done through MDS customization. Just in case you are monitoring this, can you provide this information?
thanks
Frank

Answer 1

Hi Frank,
What a strange (but nice) coincidence, I just came back to this forum today after a one month break.
As for the usecase, here goes. Our application requires that some task flows support a navigation history feature spanning over multiple task flows. To implement this, we have:
1. A container task flow (let call it the history task flow) using a single fragment containing a navigation bar (back/forward buttons) as well as a dynamic region for all task flows over which the history must span (let say task flow 1 and task flow 2, that we're going to call client task flows).
2. The framework define some base managed bean classes to interact with the history (let say history controller)
3. The client task flows MUST support an input parameter of type TaskFlowState representing a state that may have been pushed on the history's stack.
4. The task flow's first activity must be a router determining if a state was passed, if it's the case, then call the history controller's restore method, returning the activityId of what the next activity should be (often a view activity).
5. Within the client task flows, whenever the developer wants it, he can push an entry on the history stack by calling the history controller's addEntry method as a method call activity that will push the entry in the stack stored in the history task flow's page flow scope.
6. Whenever the back/forward button are pressed, the history task flow evaluate the TaskFlowId for which the entry was saved, set it as the new current TaskFlowId for the dynamic region, extract the state from the entry and pass it as the task flow's input parameter
The point 4. is where the ER would be useful. Currently, the user task flows have to define a transition from the restore activity to every activityIds that restore can produce (effectively all activity ids after the addEntry method call activities). If there was a way to apply an atomic transient (request scoped) decoration/alteration to the task flow, then the restoration logic could dynamically route to the right acitivtyId without forcing user task flows to define those extra transitions that add useless complexity to task flow.
As for a MDS customization to do that, I think it could be feasible if really well thought about. The customization would have to be on an always apply CustomizationClass basis and would have to be systematically created for every client task flows. Although a bit complex, it would achieve the same goal of reducing the apparent complexity of the client task flows.
Does that make any sense?
Regards,
~ Simon