hi Ed,
On Thu, Dec 19, 2013 at 2:23 PM, Edward Burns <edward.burns_at_oracle.com>wrote:
> Hello Volunteers,
>
> Neil Griffin brought this old blog entry to my attention today:
> <http://hantsy.blogspot.com/2013/08/jsf-22-flow.html>. I think it is a
> decent summary of the Faces Flows feature, but it ends with this text:
>
> H> Personally, the new Faces Flow is neither good nor bad, but I am
> H> bitterly disappointed with it. JSF EG declares it is inspired by ADF
> H> Task Flow and Spring Web Flow, but it seems they just copied ADF Task
> H> Flow and made it standardized.
>
> Now, if Faces Flows does not represent enough of Spring Web Flow, that
> is only a function of the participation of the EG members representing
> Spring Web Flow.
Faces Flows does not need to represent, or look like Spring Web Flow. The
user is simply comparing ideas from his own experience with different
projects and that is important to do. The list of items at the end of the
blog post are features that Faces Flow can target in subsequent releases.
This is part of natural evolution.
For me however there are more fundamental questions that may have played a
role in the final conclusion even if not verbalized clearly.
Specifically the stated design goal of encapsulating the details of a flow
in my mind is not met. It's easier to explain by talking about Web Flow. I
recommend running a sample in addition to this very basic description. I'm
happy to provide further explanations.
In Web Flow there is a single flow definition artifact that encapsulates
all flow navigation rules. Those rules are enforced and cannot be bypassed.
From a client perspective that means a flow is represented by a single URL
throughout all steps of the flow (and any sub-flows). It also means a user
cannot just type a URL and jump into the middle of the flow. It would break
the defined navigation rules. This may seem radical at first but consider
that you'd never want to jump into the middle of a shopping cart checkout
process (a typical use case for using flows). This is quite different from
free browsing where the user should be able to jump to anywhere they want
to.
I found major differences in the way Faces Flow worked and raised them
before (see links below).
https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-03/message/29
https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/81
> Rossen, do you agree with Hantsy's impression that
> Faces Flows just copies ADF Task Flows and doesn't represent SWF? What
> does SWF have that Faces Flows could benefit from?
>
> H> 1. The elements of the flow definition are tedious and not clear as
> H> the Spring Web Flow.
>
> I'd like to understand how to make flows better here.
>
I would recommend comparing the experience of writing the same sample using
different projects. It's the only way to gain a better understanding and
it's what the user based his opinion on.
H> 2 The command action, especially, h:commandButton and h:commandLink
> H> became difficult to understand, the action value could be an implicit
> H> outcome, a flow name, a method call id, a flow call id etc.
>
> Yes, it's true. I wanted to make it very easy to adopt flows in an
> existing app.
>
> H> 3. The Java based flow definition(@FlowDefinition and FlowBuilder) is
> H> every ugly, just converts the xml tag. It is not fluent APIs at all.
>
> I welcome improvements. Does anyone else feel the same way, that the
> API needs to be more fluent?
>
> H> 4. The @FlowScoped bean does not work as the Seam 2 conversation
> H> bean.
>
> I see this statement on the Seam website: "Active development of Seam 3
> has been halted by Red Hat." Therefore, I don't know how important it
> is to do anyting about Hantsy's item 4.
>
The status of Seam aside, I think the feedback is what's important.
Rossen