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="#

">
<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.

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

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

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

Example showing "onblur" equivalent working with bubbling.

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.

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

Should rename to ice:singleSubmit

Needs to be renamed to singleSubmit.

Tag renamed.