Webflow Style Conventions

[Cantor, Scott]

On 4/1/13 11:35 AM, "Marvin Addison" <marvin.addison at gmail.com> wrote:

>Interesting. I can see the benefit for the CLI use case, but I can
>imagine it may be awkward to configure the EventContext in the flow
>XML. I'm eager to see how this would look in terms of configuration.
>If it works out to be natural and allows expressive flows, then you've
>got a gem.

I don't think it's that bad, unless I'm way off in understanding the EL.
If the bean referencing works as documented, it could be something as
simple as this:

<evaluate expression="flowAdaptor.execute(flowRequestContext,
@CheckMandatoryIssuer)" />


We already are looking at something like this:

<evaluate expression="CheckMandatoryIssuer" />


I don't really see a radical difference, and I suspect there are more
tricks that can optimize it anyway.

>I have noted that there are two fairly different classes of flow actions:
>
>- The action performs a fair bit of logic that determines one of
>possibly multiple outcome events.
>- Simple action state that produces a single result, where the only
>natural outcome is "proceed" (or perhaps also an "error" event if an
>exception is thrown).

Agreed, but I don't think either of those are dependent on WebFlow per se.

>I've found that the latter maps much more naturally to a simple bean
>invocation using Spring EL. It keeps with your goal of removing SWF
>dependencies on core components and it has a natural style in terms of
>flow XML. Perhaps there's room in the conventions for both styles.

That I agree with, but it's actually a bit beyond anything I was changing.
We would have already had more complex flow transition logic in the XML in
the former case. That may or may not be desirable, but it isn't a change
I'm causing in my proposal.

The other thing I found was that there's no change at all to the handling
of HttpServlet objects in my proposal. The existing code in
AbstractProfileAction was already setting the request and response as
properties on the ProfileActionContext (the non-Spring context root we
defined). So nothing's changing there, my adaptor does the same thing.

-- Scott