>>>>> On Fri, 08 Mar 2013 14:48:31 -0700, David Schneider <david.schneider_at_oracle.com> said:
DS> Here are a few items I found while reviewing the latest draft of the
DS> specification:
DS> * 7.4.2.2 & 7.5.1: Why are flow scoped beans instantiated at flow
DS> entry rather than at first reference? If all flow scoped beans are
DS> instantiated at flow entry, regardless of whether they ever get
DS> referenced by the flow, this could lead to a lot of unnecessary
DS> object creation and unnecessary memory footprint.
Thanks. The implementation matches your expectations. I have changed
the spec to match your expectations as well. The text now reads:
Make it so any @FlowScoped beans for this flow are able to be
activated when an EL expression that references them is evaluated.
DS> * 7.5.1: In the description of the first diagram suggest changing
DS> "task flow return nodes" to "faces flow return nodes".
Fixed.
DS> * 11.4.3: I'm concerned with the idea that all flows are discovered
DS> at application start-up and stored in an internal flow data
DS> structure. This could potentially introduce a lot of memory
DS> footprint overhead. One of the advantages of using a XML document
DS> name in the flowId is the flow definition can be discovered on the
DS> fly, it doesn't have to be already known. I suppose different
DS> FlowHandler implementations could implement various caching
DS> strategies in an effort to reduce memory use.
I don't see how the text in section 11.4.3 *requires* loading the full
flow definition into an internal data structure. I am loath to be so
specific about the implementation except to say that the flow instances
must be available via the FlowHandler.
DS> * 11.4.3.2: This paragraph states a flow definition must be in the
DS> jar's META-INF/faces-config.xml file. This seems overly
DS> restrictive. Wouldn't be better to allow the jar file to contain
DS> multiple flow definition documents with the faces-config.xml
DS> containing a reference to those documents?
I don't think it's overly restrictive for the performance boost we get
by limiting the scanning to just that name.
DS> * 11.4.3.3: Missing word "if". The passage "and such files exist"
DS> should be "and *if* such files exist".
Fixed.
DS> * 11.4.3.3: What is the convention for the value of definingDocumentId
DS> when a flow is implicitly defined by a directory? Is it the
DS> convention described in section 7.4.2.1?
Thanks for catching that. It is definitely the empty string. I've
fixed it.
Ed