ICEfaces
  1. ICEfaces
  2. ICE-8276

Regression: The captureSubmit script is still added to forms where f:ajax has been disabled

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.0.BETA2
    • Fix Version/s: 3.1.0.RC1, 3.1
    • Component/s: Bridge, Framework
    • Labels:
      None
    • Environment:
      ICEfaces Core
    • Assignee Priority:
      P2

      Description

      As per ICE-6717, when disabling Ajax for a form:

          <f:ajax disabled="true">
              <h:form id="disabledForm">
                  <h:panelGrid columns="2">
                     ...

      the intent was to prevent the captureSubmit script that we automatically add to forms from being rendered and thus reverting to "stock" form submission (i.e. non-Ajax requests). What I am seeing is that the script is still being rendered but that the form also includes a list of disabled elements which indicates that the bridge should do a "normal" form submission rather than use our form submission code. So the current output looks something like this:

      <form action="/fajax/disabledForm.jsf" enctype="application/x-www-form-urlencoded" id="disabledForm" method="post" name="disabledForm">
      ....
          <script id="disabledForm:disabledForm_captureSubmit" type="text/javascript">ice.captureSubmit('disabledForm',false);ice.captureEnterKey('disabledForm');</script>
      ....
          <input disabled="true" id="disabledForm:ajaxDisabled" type="hidden" value=" disabledForm:cbaDisabledForm disabledForm:cblDisabledForm ">
      ....
      </form>


      The difference is subtle. What we want is for our script not to be rendered so that submits are done in a typical, non-Ajax fashion. What is happening is that our script is being rendered but includes a list of disabled components which indicate the components that should not trigger an Ajax request. The trick is that the final behaviour may look identical (a non-Ajax form submission).

      So it's possible that this may not actually be a regression. Instead, the issue may not have been detected in testing because we simply saw the non-Ajax request and weren't actively checking for the script being rendered.

        Activity

        Hide
        Deryk Sinotte added a comment -

        Assigning to Ted for the moment as he worked on the initial problem.

        Show
        Deryk Sinotte added a comment - Assigning to Ted for the moment as he worked on the initial problem.
        Hide
        Ted Goddard added a comment -

        Attempting to reconstruct as a test case does not appear to show the feature working – it may have been implemented without actual verification that the entire form was disabled. The UIForm component does not appear to be picking up the f:ajax behaviour.

        Show
        Ted Goddard added a comment - Attempting to reconstruct as a test case does not appear to show the feature working – it may have been implemented without actual verification that the entire form was disabled. The UIForm component does not appear to be picking up the f:ajax behaviour.
        Hide
        Ted Goddard added a comment -

        <f:ajax> is actually attached to an event. If not specified, a default event is used. In the case of <h:commandButton> and <h:commandLink> this default event is "action".

        <h:form> however has a null default event, and does not handle the "action" event.
        This can be resolved by making use of the click event as follows:

        <f:ajax event="click" disabled="true">
        <h:form id="disabledForm">
        ...
        </h:form>
        </f:ajax>

        This appears to have no side effects from the "click" event since ajax is disabled and JSF does not write any output based on the click event. There may be complex cases where different events need to be disabled and a different event from click (supported by HtmlForm) will need to be chosen.

        For HtmlForm we have:

        private static final Collection<String> EVENT_NAMES = Collections.unmodifiableCollection(Arrays.asList("click","dblclick","keydown","keypress","keyup","mousedown","mousemove","mouseout","mouseover","mouseup"));

        Show
        Ted Goddard added a comment - <f:ajax> is actually attached to an event. If not specified, a default event is used. In the case of <h:commandButton> and <h:commandLink> this default event is "action". <h:form> however has a null default event, and does not handle the "action" event. This can be resolved by making use of the click event as follows: <f:ajax event="click" disabled="true"> <h:form id="disabledForm"> ... </h:form> </f:ajax> This appears to have no side effects from the "click" event since ajax is disabled and JSF does not write any output based on the click event. There may be complex cases where different events need to be disabled and a different event from click (supported by HtmlForm) will need to be chosen. For HtmlForm we have: private static final Collection<String> EVENT_NAMES = Collections.unmodifiableCollection(Arrays.asList("click","dblclick","keydown","keypress","keyup","mousedown","mousemove","mouseout","mouseover","mouseup"));
        Hide
        Ted Goddard added a comment -

        click event has been added to fajax sample illustrating a wrapped form with no ICEfaces ice.captureSubmit() and no ajaxDisabled list. See disabledCommandButtons.jsf and disabledCommandLinks.jsf.

        Show
        Ted Goddard added a comment - click event has been added to fajax sample illustrating a wrapped form with no ICEfaces ice.captureSubmit() and no ajaxDisabled list. See disabledCommandButtons.jsf and disabledCommandLinks.jsf.

          People

          • Assignee:
            Ted Goddard
            Reporter:
            Deryk Sinotte
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: