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

[Brent Putman]

With the caveat that my Webflow knowledge is still very neophyte-ish:


On 6/11/13 8:48 PM, Tom Zeller wrote:
> Do we want to map profile paths to flow definitions explicitly via
> configuration elements or implicitly via file system hierarchy ?

Just from my very limited playing around in the testbed thing, I offhand would say I prefer
explicit.  Mostly for the same reasons Scott already outlined.  That's what I did for the IdP part
of it at least.




>
> Mapping profile paths to flows explicitly would require a
> webflow:flow-location configuration element for every profile-to-flow
> mapping. By default, the flow-location id is mapped to the path info
> of the URL request string and the path is the path to the flow
> definition file. For example :
>
>  <webflow:flow-location id="SAML2/POST/SSO" path="/SAML2/sso-post-flow.xml" />
>  <webflow:flow-location id="SAML2/Redirect/SSO"
> path="/SAML2/sso-redirect-flow.xml" />


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.

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 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.  It's definitely not the case
trivially or by default - I played around with flow-location-pattern in my /test part of my
testbed.  That stuff still lives under /WEB-INF, and it finds it without complaint.

 

> 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.

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.