Hello Volunteers,
David Scheinder obtained some help from a teammate of his to review the
XSD elements relating to faces flows. In the interest of transparency,
here is the email exchange that resulted. If you're interested in just
the substantive changes, I've tagged them with IMPORTANT:
>>>>> On Tue, 8 Jan 2013 15:01:15 -0800, Edward Burns <edward.burns_at_oracle.com> said:
EB> I've captured these in <
http://java.net/jira/browse/JAVASERVERFACES-2677>.
EB> Thank you very much.
>>>>> On Tue, 08 Jan 2013 13:29:07 -0700, Marta Hawkins wrote
MH> 1.minOccurs is 1 by default and maxOccurs is 1 by default, so there
MH> is no need to specify that. There are several places where it is
MH> specified.
EB> I'll fix that.
MH> 2.switch type:
MH> Why is navigation-case used here? It seems a bit overloaded. For
MH> example, navigation case can define redirect, which does not seem to
MH> apply here. Or to-view-id. Why not define a new type that represents
MH> a logical case statement? I guess reuse of XSD types takes
MH> precedence here.
IMPORTANT:
EB> Yes, the reason for the verbosity is a desire for reuse. I'll rework it
EB> to create a new type specifically for the purpose.
MH> The default-outcome is defined like this:
MH> <default-outcome>
MH> <from-outcome>foo</from-outcome>
MH> <default-outcome>
MH> It would be simpler to have:
MH> <default-outcome>foo</default-outcome>.
EB> I agree, I'll do that.
MH> The documentation for <from-outcome> is copied from navigation-rule
MH> and still mentions the "rule". Seems a bit odd in case of a switch.
EB> I'll do that.
MH> 3. Same comments about navigation-case apply to flow-return. There
MH> is no way to enforce "must contain exactly one <from-outcome>
MH> element" if navigation-case type is used directly.
IMPORTANT:
EB> I'll do that.
MH> 4. flow-call. Task flow reference is required. It is defined like this:
MH> <faces-flow-reference>
MH> <faces-flow-id>myFlow</faces-flow-id>
MH> </faces-flow-reference>
MH> faces-flow-id is not required though, so you could have a reference like this:
MH> <faces-flow-reference>
MH> <faces-flow-id/>
MH> </faces-flow-reference>
MH> I think it should be required, but it is defined as minOccurs="0"..
EB> I'll fix that.
MH> 5. method. Besides having no parameters (as Ed mentioned), it has a
MH> default-outcome defined as a string. This is nice and simple, so why
MH> not have the same definition for switch? It seems
MH> inconsistent.
EB> I'll fix that.
MH> Also, how would you define an outcome that is a String
MH> representation of method's return type?
EB> Isn't that the same problem for any other navigation case since we
EB> introduce the "return object and we'll call toString() on it" convention
EB> in JSF?
MH> 6. Documentation on the outbound parameter:
MH> The "value" element within an "outbound-parameter"
MH> must be an EL Expression whose "get" will be called when the "flow-call"
MH> containing this element is traversed to go to a new flow.
MH> Why only "get"? No literal values allowed?
EB> I'll correct that omission. Literal values are certainly allowed, as
EB> usual.
EB> Ed
EB> --
EB> | edward.burns_at_oracle.com | office: +1 407 458 0017
EB> | homepage: |
http://ridingthecrest.com/
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/