idpv3 and web flow : flow-location or flow-location-pattern ?

[Tom Zeller]

> As Scott says, this seems to model more closely what we did in v2 in handler.xml.  It also avoids
> making (possibly deep) directory structure have semantic meaning, which seems semi-bad to me (again
> with limited experience with this).  Having the flow mapping explicit seems more natural to me
> personally.

Okay. My first thought was that I liked the, umm, implicit semantic
model. I do not have strong feelings about directories though, most of
the time.

> I also found the webflow:flow-registry/@base-path to be useful, so that the flow references can be
> relative to that.  I had not yet played around with externalized type of config there for putting
> this stuff outside the war, but it would be awesome if it were as simple as putting a file:// URL in
> base-path.

I really hope I figured out how to keep the flow definitions external
to the war and then moved on from that workspace, but I need to
revisit.

>> I think I prefer mapping implicitly via the file system and
>> flow-location-pattern, mainly because profile-to-flow mappings are
>> thus external to the war, if I understand correctly.
>
>
> Yeah, like Scott, I didn't really get this from reading the docs.

The "if I understand correctly" was "if I understand the web flow plan
for IdPv3 correctly", so not any Spring docs. I was being confusing
there.

>> If we go this
>> route, then importing parent beans in a child flow would look like
>>
>>  <bean-import resource="../../../abstract/common-flow-beans.xml" />
>>
>> which is not attractive or maybe even a good idea because of the ../s.
>
> Doesn't look attractive to me either.  But I'm not sure you actually need to do that.  From what
> I've seen so far, the beans defined/imported in an abstract parent flow are available in the child
> merely by virtue of making the concrete flow a child of the abstract flow (using flow/@parent).
> AFAICT you don't need to do any explicit importing of the parent's beans anywhere.  At least it's
> working that way in my testbed.

Yes, but remember that Web Flow inheritance is actually merging, and
resource paths are relative to the child, not the parent. In your
testbed, the parent and child flows are in the same directory,
somewhat masking the <bean-import /> merging behavior.

> As an aside, it wasn't clear to me until I wrote some diagnostic code that every flow gets its own
> application context, which is a child of the Spring MVC dispatcher servlet's application context.
> Their docs certainly don't make that very clear.  But the hierarchy seems pretty nice the way it
> works.  And re: the above, I *think* that each concrete flow gets its own copy of beans defined in
> the abstract parent - in other words I didn't see that the abstract parent beans were shared in any
> way amongst the contexts of its concrete child flows.  If you did want to have a bean shared across
> multiple flows, then you could define it in one of the higher contexts (e.g. the dispatcher servlet
> one or the webapp root context).  I did that in my testbed in fact.

Oh, I did not think of context hierarchy being related to flow
hierarchy, good point.