>>>>> On Mon, 25 Feb 2013 14:46:01 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
LU> Hi
LU> This mail is just to note some small details over the documentation of
LU> flowDocumentId. I'm still reading the latest draft, but since the time
LU> is getting short I'll send any observation I see as soon as I can find it.
LU> 1. In the javadoc of ActionListener.TO_FLOW_DOCUMENT_ID_ATTR_NAME it says
LU> this:
LU> "... The presence of this component attribute on an ActionSource component
LU> will cause the default ActionListener to interpret the value of the
LU> attribute as the "
LU> Note the phrase is incomplete.
Fixed.
LU> 2. The documentation of Application.getActionListener must be updated to
LU> reflect the intention of ActionListener.TO_FLOW_DOCUMENT_ID_ATTR_NAME. Note
LU> this part describes the steps done by the default ActionListener.
Ah yes. This is one of those places where the javadoc and the PDF
duplicate eachother. I'm going to remove the text in the javadoc and
make it refer to the PDF.
LU> 3. Just as an observation, it is curious that to-flow-document-id becomes
LU> a "hidden property" for h:commandButton, h:commandLink, f:viewAction and
LU> all UICommand components. The question is: shouldn't this attribute be
LU> defined at UICommand level?, or at least has a getter/setter on the
LU> affected components?. With the proposed changes now this is possible:
LU> <h:commandButton to-flow-document-id="flowDocument1" ...>
LU> No objections, but the convention used always has been something like this:
LU> <h:commandButton toFlowDocumentId="flowDocument1" ...>
Yes, I thought about that, but I wanted existing version of third party
component libraries to be able to use the feature without having to
revise their tags. This approach makes it possible to say:
<p:commandButton>
<f:attribute name="to-flow-document-id" value="unique" />
</p:commandButton>
and Cagatay doesn't have to add an attribute to his component.
Also, the unusual name was chosen to match the exactly corresponding
XML.
LU> 4. flowDocument concept is still not fully specified. The biggest
LU> problem is there is no mention about use the faces-config name
LU> document as a default for flowDocument and if it is not found use
LU> something derived from the flowId. For now the only mention is how
LU> to derive a flowDocumentId if is not present. Also, it is necessary
LU> to specify what happen if the flowDocumentId is not provided (the
LU> navigation algorithm should deal with this possibility when
LU> resolving the outcome). I hope this is work in progress.
The 22 Feb 2013 Draft has a section 11.4.3.1 "Defining Flows" that has
this text:
Flows are defined using the <flow-definition> element. This element
must have an id attribute which uniquely identifies the flow within
the scope of the Application Configuration Resource file in which the
element appears. To enable multiple flows with the same id to exist in
an application, the <faces-config><name> element is taken to be the
definingDocumentId of the flow. If no <name> element is specified, the
empty string is taken as the value for definingDocumentId.
LU> 5. In faces-config.xml for <navigation-case> it is obvious there was a
LU> change for <javaee:to-flow-document-id>, but it was not marked as a change.
The documentation for that element is indeed annotated with
class="changed_added_2_2". Maybe it's a CSS error somewhere.