Pavitra and I talked about this some more last night. It looks like the
AutoSubmitEvent is delivered so that the subforms know which subform, if
any triggered the post so that the subforms know whether to process
their children. However, the way that this is done seems overly
complicated, with the individual renderers decoding and queuing the
autosubmit event if their component was the triggering cause. Instead,
the Subform Renderers can grab the clientId of the posting component and
since the Subform is a NamingContainer, if the Subform's clientId is a
prefix of the submitted clientId, then this Subform is the submitting
subform.
-- Blake Sullivan
Gabrielle Crawford said the following On 1/14/2010 12:41 PM PT:
Pavitra Subramaniam wrote:
I also noticed the following comment in the inner class,
FormElementRenderer$AutoSubmitEvent,
/**
* Dummy class purely to get subforms to recognize that
* an event has occurred
*/
static private final class AutoSubmitEvent extends FacesEvent
{
...
}
Don't really know much about subforms, but would not queue-ing the
event cause subforms to not PPR-ed? I doubt it, and I can test this
usecase but thought I'd check.
Hmmm, I'm not sure the subform is even ppr-able, I don't think they
render any markup.
However subforms decide whether they are the 'submitted' subform based
on queued events, take a look at UIXSubformTemplate. Almost all events
are queued in the apply request values phase, even if they aren't
delivered until a later phase. An exception to this is the
valueChangeEvent, which isn't queued until the validate phase. So
maybe we're triggering the autosubmit event so that the subform sets
itself as the submitted subform during the apply request values phase.
Gab
