idpv3 and web flow : flow-location or flow-location-pattern ?
Cantor, Scott
cantor.2 at osu.edu
Tue Jun 11 21:54:15 EDT 2013
On 6/11/13 8:48 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>Do we want to map profile paths to flow definitions explicitly via
>configuration elements or implicitly via file system hierarchy ?
I think the former. We've never had a file system hierarchy before, and I
doubt we'd want to start.
>I ask because there may be minor implications for flow inheritance and
><bean-import />.
It's possible that could trump other considerations.
>Not sure if I am using explicitly and implicitly correctly.
I think it's either/both depending on which end you're on.
>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" />
Yes, in effect handler.xml in V2.
>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.
I wouldn't think they would be, which is one reason I'm not in love with
the idea. If it is, I might change my mind. But I'm pretty sure based on
my limited playing around, all that was relative to the class path. Maybe
it could be pointed to the conf tree, but even then, who wants deep trees
in conf/?
> 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.
Yes.
>Importing beans via <bean-import resource="common-flow-beans.xml" />
>in common-flow.xml will not work because "relative paths in the parent
>flow will become relative to the child flow". [1]
And I think it all gets very confusing.
>If we go with flow-location, then we have more control over
>inheritance paths, I think.
Which I favor.
-- Scott
More information about the dev
mailing list