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

[Tom Zeller]

>> 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.
>
> As I mentioned in the note I just sent, it certainly works fine to use a
> flow-location along with a file:// URL base-path.
>
> Actually, what *didn't* work was a pattern like this with a file:// URL
> base-path:
>
> <webflow:flow-location-pattern value="/**/*-flow.xml"/>
>
> I didn't spend any time figuring out why, maybe with some tweaks that
> would work as well.

Thanks !

I will try to reproduce your findings and look for tweaks.

Honestly, I did not achieve full clue when I first read you note, it
took another  email.

>> 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.
>
> Ah, ok. That makes sense.

Flow definition inheritance seems similar to maven, where an effective
POM is created at runtime.

> That would then lead to my next question: Is
> there any advantage, do we gain anything, by trying to organize the
> abstract and concrete flows in some complicated directory structure?  If
> a single, simple flat directory containing the abstract and concreate
> and their associated beans files would simplify things, maybe that's the
> way to go - at least for all the artifacts related to a given
> protocol/standard, e.g. SAML vs CAS vs OpenID, etc. It's unlikely we'd
> share things across those any way.  As much as I like to organize things
> in directories (really, not kidding), perhaps the KISS principle applies
> here.

I think I agree with you, contrary to my expressed preference.

Mapping file system paths to request paths makes a kind of simple
sense to me, but for this project, which has a limited number of
request paths, the complexity of a deep directory structure is
probably not appropriate. So, to respond to your question : no,
nothing gained as far as I can tell.

Flat seems to be a popular design choice : flows/SAML1, flows/SAML2,
flows/CAS, flows/ZML (I just made that up).

It seems like path vs filename for flow definition naming. Come to
think of it, we should definitely choose filename and explicit
mapping. That is the model used elsewhere in the project.