>>>>> On Mon, 14 Jan 2013 13:41:17 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
LU> I have checked PRD documentation and I have noticed some pending
LU> points that it could be good to keep in mind. This is important
LU> feedback, and in my opinion these points needs to be solved.
LU> ------------------------------------------------------------------------
LU> Faces Flow
LU> ------------------------------------------------------------------------
LU> - It seems there are still some examples using the old syntax inside .xhtml
LU> files and there are people who still believes that syntax is valid, but
LU> in the spec documentation there are only two ways to define a flow: using
LU> xml file and using @FlowDefinition.
Yes, not just some, but *all* of the examples that use XML defined flows
still use the Facelets syntax. Until I close JAVASERVERFACES-2580 to
that's how it will be. I've been keeping the tag handlers up to date
with respect to the XSD, so it will be trivial to change the examples
once 2580 is closed.
LU> - In JSF 2.2 section 7.5.1, it says something like this:
LU> "... When the application containing these flows is deployed, the
LU> runtime discovers the flow definitions and adds them to the internal
LU> flow data structure. One flow is defined in flow-b-flow.xml. The
LU> other flow is defined in FlowA.java, an @Named bean with the
LU> @FlowDefinition annotation. ..."
LU> That's ok, but I think it is not clear that flow-b-flow.xml is a xml
LU> file that has a <faces-config> definition inside (note I'm
LU> speculating here). I suppose that file should allow only a subset
LU> of <faces-config> (navigation rules, managed beans definitions maybe
LU> components/renderers?), or maybe it is open to define anything that
LU> can be defined in a faces-config (which I doubt it).
I wasn't planning on requiring any kind of constraint to what kinds of
XML can be contained in such files. I have added this text.
This is an XML file conforming to the Application Configuration
Resources syntax described in Section 11.4 "Application Configuration
Resources".
I also added text at the top of 11.4 that refers to the complete XSD
(and the XSDDoc generated HTML documentation) which is now bundled with
the javadocs.
LU> And how @FlowDefinition works? the documentation doesn't
LU> say anything, so I just can't say anything. In my opinion, this part has
LU> sense but it requires some clarifications first.
I will flesh out that javadoc, but here is an example that currently
runs in our mojarra tests:
public class FlowA implements Serializable {
private static final long serialVersionUID = -7623501087369765218L;
public FlowA() {
}
@Produces @FlowDefinition
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) {
String flowId = "flow-a";
flowBuilder.id("", flowId);
flowBuilder.viewNode(flowId, "/" + flowId + "/" + flowId + ".xhtml").markAsStartNode();
flowBuilder.returnNode("taskFlowReturn1").
fromOutcome("#{flow_a_Bean.returnValue}");
flowBuilder.methodCallNode("outcome-from-method").expression("#{flow_a_Bean.methodWithOutcome}").defaultOutcome("taskFlowReturn1");
flowBuilder.methodCallNode("outcome-from-markup").expression("#{flow_a_Bean.voidMethod}").defaultOutcome("taskFlowReturn1");
return flowBuilder.getFlow();
}
}
LU> - In JSF 2.2 section 11.4.3.1, it talks about "Packaging Faces Flows
LU> in JAR Files". Take a look at these lines:
LU> "... Any flow nodes included in the jar must be located within sub entries
LU> of the META-INF/flows/<flowName> JAR entry, where <flowName> is a JAR
LU> directory entry whose name is identical to that of a flow id in the
LU> corresponding faces-config.xml file. ..."
LU> What is a "flow node"? is it a real view that JSF can load? does that
LU> means that the vdl should be able to load files under
LU> META-INF/flows/<flowName> like if they were in a webapp directory?.
In the non-normative example in section 7.5, I added the text, "the
different kinds of nodes mentioned in the preceding discussion are
defined in the javadoc for class javax.faces.flow.FlowHandler."
In section 11.4.3.1, I changed "flow nodes" to "view nodes". Yes, it is
a real JSF Facelets view.
LU> Note according to the previous answers, it should be some changes or
LU> clarification about how ResourceHandler.createViewResource() works.
EXCELLENT CATCH Leonardo. Thank you. I've fixed that. It will be in
the next javadocs published to
<
http://jsf-spec.java.net/SNAPSHOT/javadoc/>.
LU> ------------------------------------------------------------------------
LU> View Actions
LU> ------------------------------------------------------------------------
LU> - The changes previously proposed are still pending, so any snapshot to
LU> check how they should looks like is welcome.
Thank you for reminding me.
On 14 Decmeber 2013, Leonardo Uribe wrote:
LU> I would suggest a method in ViewMetadata that do the check for
LU> execute full lifecycle or avoid renderResponse() call, and the
LU> implementation by default
[...]
LU> In conclusion, one way or another what matters here is allow
LU> f:viewAction to be used without a dependency of f:viewParam, so any
LU> solution that goes into that direction is ok.
I did add ViewMetadata.getViewActions(), for parity with
ViewMetadata.getViewParameters(). However, I also added
boolean ViewMetadata.hasMetadata(UIViewRoot root) and modified 2.2.1 to
simply call that method instead of all that other complicated logic.
I'm running the full test suite with these changes and will commit them
if it works.
ACTION: Leonardo, I'll resume working through your feedback tomorrow.
Please do not reply to this message, but instead to the one I will send
that will include this text as well as my responses to the remainder of
this message and the thread.
Thanks for your patience and diligence.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
[1] http://java.net/jira/browse/JAVASERVERFACES-2580