Re: [Trinidad] Use of 'autoSub' event on client and AutoSubmitEvent on the server...

[Gabrielle Crawford]

Hi Pavitra,

I'm fine with any change that don't regress subforms. Basically the test 
cases should generally include the fields in 3 areas: subform A, subform 
B, and fields not in any subform, so for example in test 'a' below, you 
only mention one subform, I would test it like this:

a. valueChange inside subform A(autoSubmit=true) - should process 
subform A and fields not in any subform, but should not process fields 
in subform B.

Thanks,

Gab


Pavitra Subramaniam wrote:
On 1/14/2010 12:41 PM, Gabrielle Crawford wrote:

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.


Precisely. We are always queue-ing the AutoSubmitEvent for the 
InvokeApp phase when decoding the valueHolders within a subform. And 
we may be doing this, like you said, because a VCE is queued in a 
later phase than ARV (for non-immediate cases), it may be too late to 
figure out whether 'a' subform was submitted at the beginning of the 
validation phase, hence we are queue-ing this dummy event in the ARV 
phase.

And all the UIXSubform.queueEvent does is to store a Boolean.TRUE in 
the requestMap, indicating a subForm was submitted.

UIXSubForm.queueEvent():

    if (PhaseId.APPLY_REQUEST_VALUES.compareTo(event.getPhaseId()) < 0)
    {
      _storeSomethingSubmitted(FacesContext.getCurrentInstance());
      setSubmitted(true);
    }


But, it seems like UIXSubForm itself can check to see if the source of 
the event originated within itself by using the clientId and then set 
the request parameter value (subForm being a NamingContainer helps). 
There is no need to check for 'autoSub' event as well. This way we can

1. remove code from the following editable value renderers that call 
'detectAutoSubmit' (to queue this special event):

renderkit\core\xhtml\FormElementRenderer.java
                    \SelectManyShuttleRenderer.java
                    \SimpleInputFileRenderer.java
                    \SimpleSelectBooleanRadioRenderer.java
                    \SimpleSelectManyRenderer.java

detectAutoSubmit(context, component, clientId);

2. Remove the special 'autoSub' client event - we seem to always send 
it in the XHR POST /form submit regardless of whether we are really 
auto-submitting or not (See Page.js - TrPage._autoSubmit()) code.

3. Remove the FormElementRenderer$AutoSubmitEvent

4. Cleanup code in UIXSubForm.queueEvent and have special processing 
in processDecodes()

If you agree with the overall idea then I can work on a patch and 
testcases for the following:


a. valueChange inside subform (autoSubmit=true) - should submit the 
subform
b. valueChange outside subform (autoSubmit=true) - should not submit 
the subform
c. action inside subform - should submit the subform
d. action outside subform
  i. subform is non-default - should not submit the subform
  ii. subform is default - should submit the subform

I am assuming the usecase when both immediate and autoSubmit is true 
is irrelevant for this discussion.

Thanks
Pavitra

Thanks
Pavitra


Gab