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