ICEfaces
  1. ICEfaces
  2. ICE-5880

New icecore:singleSubmit tag to set singleSubmit default value for all input components in the form

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0-Beta2, 2.0.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      Sparkle Component Platform
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial, Compatibility/Configuration

      Description

      In ICEfaces 1.x, we have an <ice:form> component with a "partialSubmit=true/false" attribute that can be used to set the default partialSubmit behavior for all ice: components in the form, as a convenience vs. setting the individual partialSubmit attributes on each component.

      We need a solution to provide the same capability for the new Sparkle components. As we do not want to simply provide our own "ice:form" component in order to preserve 3rd party component compatibility, a likely alternative seems to be to provide a component that can be used as a sub-component of the standard JSF <h:form> component instead.

      e.g.

      <h:form>
         <ice:partialSubmit default="true">
         <ice:tabPane>
         ...
      </h:form>



        Issue Links

          Activity

          Hide
          Neil Griffin added a comment -

          First I think we need to talk about what "partial submit" meant in ICEfaces 1.x, and what "partial submit" means in ICEfaces 2.0.

          In ICEfaces 1.x, the term "partial submit" actually meant a FULL submit, with PARTIAL validation. All the EditableValueHolder fields in the form are serialized and submitted to the server via XmlHttpRequest. But only the fields that had been visited by the user were validated in the PROCESS_VALIDATIONS phase of the JSF lifecycle.

          In ICEfaces 2.0, the term "partial submit" actually means a PARTIAL submit with PARTIAL validation. For example, if you use the ICEfaces 2.0 JavaScript API and place include onblur="ice.se('onblur', this)" on an h:inputText, then the "se" means "Single Element" and so the XmlHttpRequest contains only the value of the h:inputText field. See http://wiki.icefaces.org/display/ICE/JavaScript+Client+API

          Now, in both ICEfaces 1.x and 2.0, triggering the XmlHttpRequest causes the ICEfaces Direct2DOM server-side DOM-diff engine to compute the differences, and sends back minimal page updates to the browser's DOM.

          In order to understand the requirement in ICEfaces 2.0, I think it will be helpful to review two different scenarios:

          1) ICEfaces 2.0 + h:form + icefaces-compat.jar

          Developers in this scenario are either a) experienced with the ICEfaces 1.8 component suite or b) migrating existing apps to ICEfaces 2.0. They're probably not worried about transitive dependencies like commons-beanutils, commons-collections, commons-digester, commons-fileupload, and commongs-logging. They're definitely going to use the compat components. Maybe they'll use Sparkle components, maybe not. They're probably willing to switch from ice:form to h:form, but they're used to "partial submit" meaning that all the fields are sent in the XmlHttpRequest, and not just one. They need a convenient way to turn this feature on for the h:form, that's all.

          2) ICEfaces 2.0 + h:form

          Developers in this scenario are likely creating new applications, and not migrating. Perhaps they will add Sparkle components, and perhaps components from another component suite too. They might indeed be worried about transitive dependencies, and so they would I think shy-away from including icefaces-compat.jar in their projects. Perhaps they want to use ICEpush. And maybe even use ICEpush to provide server-initiated updates for components from other suites.

          IDEAS:

          1. Currently in ICEfaces 2.0 I think the h:form is being "decorated" in the sense that a SystemEvent is used to do some rendering magic to get the form to be submitted via XmlHttpRequest rather than a full postback. Perhaps the presence of <ice:partialSubmit /> as a child of h:form would cause this type of decoration on all EditableValueHolder components that can support onblur.

          2. Another approach might be with JSF 2.0 Behaviors on individual components. See Dan Allen's blog here:
          http://java.dzone.com/articles/jsf-2-client-behaviors

          Using behaviors, instead of doing this:

          <h:inputText id="foo" onblur="ice.se('onblur', this)" required="true" value="#

          {modelBean.foo}" />

          We could do this:

          <h:inputText id="foo" required="true" value="#{modelBean.foo}

          ">
          <ice:partialSubmit />
          </h:inputText>

          And this could decorate the h:inputText with an onblur handler automatically in the rendered HTML.

          Whatever we do, I think it is important to be able to trigger ICEfaces 2.0 Direct2DOM rendering without writing any JavaScript in the Facelet view.

          Show
          Neil Griffin added a comment - First I think we need to talk about what "partial submit" meant in ICEfaces 1.x, and what "partial submit" means in ICEfaces 2.0. In ICEfaces 1.x, the term "partial submit" actually meant a FULL submit, with PARTIAL validation. All the EditableValueHolder fields in the form are serialized and submitted to the server via XmlHttpRequest. But only the fields that had been visited by the user were validated in the PROCESS_VALIDATIONS phase of the JSF lifecycle. In ICEfaces 2.0, the term "partial submit" actually means a PARTIAL submit with PARTIAL validation. For example, if you use the ICEfaces 2.0 JavaScript API and place include onblur="ice.se('onblur', this)" on an h:inputText, then the "se" means "Single Element" and so the XmlHttpRequest contains only the value of the h:inputText field. See http://wiki.icefaces.org/display/ICE/JavaScript+Client+API Now, in both ICEfaces 1.x and 2.0, triggering the XmlHttpRequest causes the ICEfaces Direct2DOM server-side DOM-diff engine to compute the differences, and sends back minimal page updates to the browser's DOM. In order to understand the requirement in ICEfaces 2.0, I think it will be helpful to review two different scenarios: 1) ICEfaces 2.0 + h:form + icefaces-compat.jar Developers in this scenario are either a) experienced with the ICEfaces 1.8 component suite or b) migrating existing apps to ICEfaces 2.0. They're probably not worried about transitive dependencies like commons-beanutils, commons-collections, commons-digester, commons-fileupload, and commongs-logging. They're definitely going to use the compat components. Maybe they'll use Sparkle components, maybe not. They're probably willing to switch from ice:form to h:form, but they're used to "partial submit" meaning that all the fields are sent in the XmlHttpRequest, and not just one. They need a convenient way to turn this feature on for the h:form, that's all. 2) ICEfaces 2.0 + h:form Developers in this scenario are likely creating new applications, and not migrating. Perhaps they will add Sparkle components, and perhaps components from another component suite too. They might indeed be worried about transitive dependencies, and so they would I think shy-away from including icefaces-compat.jar in their projects. Perhaps they want to use ICEpush. And maybe even use ICEpush to provide server-initiated updates for components from other suites. IDEAS: 1. Currently in ICEfaces 2.0 I think the h:form is being "decorated" in the sense that a SystemEvent is used to do some rendering magic to get the form to be submitted via XmlHttpRequest rather than a full postback. Perhaps the presence of <ice:partialSubmit /> as a child of h:form would cause this type of decoration on all EditableValueHolder components that can support onblur. 2. Another approach might be with JSF 2.0 Behaviors on individual components. See Dan Allen's blog here: http://java.dzone.com/articles/jsf-2-client-behaviors Using behaviors, instead of doing this: <h:inputText id="foo" onblur="ice.se('onblur', this)" required="true" value="# {modelBean.foo}" /> We could do this: <h:inputText id="foo" required="true" value="#{modelBean.foo} "> <ice:partialSubmit /> </h:inputText> And this could decorate the h:inputText with an onblur handler automatically in the rendered HTML. Whatever we do, I think it is important to be able to trigger ICEfaces 2.0 Direct2DOM rendering without writing any JavaScript in the Facelet view.
          Hide
          Ted Goddard added a comment -

          It may be possible to use event bubbling with onblur or onchange events to provide this feature for standard components.

          Show
          Ted Goddard added a comment - It may be possible to use event bubbling with onblur or onchange events to provide this feature for standard components.
          Hide
          Ted Goddard added a comment -

          As Deryk found in this reference, it may be difficult to bubble:

          http://www.quirksmode.org/blog/archives/2008/04/delegating_the.html

          Show
          Ted Goddard added a comment - As Deryk found in this reference, it may be difficult to bubble: http://www.quirksmode.org/blog/archives/2008/04/delegating_the.html
          Hide
          Ted Goddard added a comment -

          Example showing "onblur" equivalent working with bubbling.

          Show
          Ted Goddard added a comment - Example showing "onblur" equivalent working with bubbling.
          Hide
          Ted Goddard added a comment -

          It is possible to implement a bubbling form of "onblur" (attached HTML document). This will allow us to add partialSubmit onblur behavior in an efficient manner (without adding event handlers to each element).

          Show
          Ted Goddard added a comment - It is possible to implement a bubbling form of "onblur" (attached HTML document). This will allow us to add partialSubmit onblur behavior in an efficient manner (without adding event handlers to each element).
          Hide
          Ted Goddard added a comment -

          Initial ice:partialSubmit component checked in:

          <h:form id="form1" prependId="false">
          <ice:partialSubmit rendered="true" />

          Tested with a text field. Testing is required for all input types on all browsers.

          Show
          Ted Goddard added a comment - Initial ice:partialSubmit component checked in: <h:form id="form1" prependId="false"> <ice:partialSubmit rendered="true" /> Tested with a text field. Testing is required for all input types on all browsers.
          Hide
          Ted Goddard added a comment -

          Component is checked in. Create new JIRAs for specific bugs.

          Show
          Ted Goddard added a comment - Component is checked in. Create new JIRAs for specific bugs.
          Hide
          Ted Goddard added a comment -

          Should rename to ice:singleSubmit

          Show
          Ted Goddard added a comment - Should rename to ice:singleSubmit
          Hide
          Ken Fyten added a comment -

          Needs to be renamed to singleSubmit.

          Show
          Ken Fyten added a comment - Needs to be renamed to singleSubmit.
          Hide
          Ted Goddard added a comment -

          Tag renamed.

          Show
          Ted Goddard added a comment - Tag renamed.

            People

            • Assignee:
              Ted Goddard
              Reporter:
              Ken Fyten
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: