Some web flow experimentation

[Cantor, Scott]

After some progress integrating an Authentication subflow into Brent's
profile testbed, I've been able to notice a few things.

Subflows work as expected, with the end state of the subflow returned as
the result of the subflow-state in the parent flow.

Our error handling obviously isn't done yet, so a lot of this works
awkwardly while testing, but the model of pointing error events at a state
called "error" or "end" won't work, because that causes the error to
disappear and the subflow to return an event of "end" as the result. We
could use output attributes instead, to capture the event that led to the
end-state, but I think we were hoping to avoid input/attribute using flow
scope variables.

So if we want a subflow to actually return an error event, we have to
define an end-state with the id of the error event, so that it gets
propagated back up.

At least in my case, the simplest solution seemed to be:

<end-state id="proceed" />
    <end-state id="NoPotentialFlow" />
    <end-state id="RequestUnsupported" />

etc.

<global-transitions>
	<transition on="#{true}" to="#{currentEvent.id}" />
    </global-transitions>

It seems to work to explicitly override the global transition with custom
transitions, so "proceed" can dispatch to the next flow step in the usual
case until the last step, and then it can just fall into "proceed" as an
end-state.


Special error handling should be doable the same way, but a lot of the
time, the global transition to a like-named end-state could act as a sort
of exception throw out of the subflow.

But one thing we do have to do is define *every* possible error event as
an end-state, because otherwise it won't be able to end the subflow
properly. We might be able to factor that into some kind of abstract
parent flow for subflows to inherit from, not sure.

I checked in my work in progress into src/main/resources/flows in the
authn-impl module.

-- Scott