Neil Griffin added a comment - 03/Sep/10 3:02 PM 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.