The current mechanism for this in ICEfaces 1.8 is the use of icefaces.jar vs just-ice.jar. just-ice.jar contains a modified faces-config.xml so that ICEfaces Renderers are not applied for h: components. Additionally, the ICEfaces Servlet dispatch stack marks ICEfaces requests for attention by other parts of the code.

With JSF 2.0, initial page rendering and Ajax interaction are handled directly by JSF, making the above two techniques difficult to apply; moreover, though, it is awkward to specify ICEfaces page handling on a per-request or per-application basis.

There are several cases where finer granularity in the application is needed:

All pages use ICEfaces and D2D Rendering. This should be the default.

Some pages use ICEfaces and some do not. A configuration parameter should turn ICEfaces off globally and a configuration component on the ICEfaces pages can enable and configure ICEfaces for specific pages. For simplicity, the component should not require containment of the entire page as a child; it just activates D2D Rendering and ICEfaces Ajax behaviors for h: components on the page.

Some parts of an ICEfaces page should use a DOM diff, some should not. Specifying execution and render subtrees is orthogonal to this and is already handled by JSF 2.0. This configuration must must apply to a contained subtree. It should be possible to decide at runtime whether the DOM diff is used or whether the raw output of the components is used for the Ajax edit list. (For instance, if a data table is known to change substantially, there is no benefit to the diff and the complete updated table should be used as a replacement.)

Some parts of the page should use D2D Rendering, some should not. For this case, ICEfaces would be turned off globally, but would be configured for DOM diff for a specified subtree. It should be possible to implement through ResponseWriter delegation.

There are two natural mechanisms for applying configuration to a subtree.

A containing component:

<ice:region domdiff="aggressive|replacements|off" ajaxhandlers="true">
<h:inputText>
...
</ice:region>

Or a marker component:

<h:panelGroup>
<ice:region domdiff="off" />
<h:dataTable>
...

</h:panelGroup>

<ice:configuration/> may be a more appealing tag name for the case of a full-page page marker component (it could serve for the above two cases as well).

It may be reasonable to allow either behavior for a single component: if the component has children, it applies to its subtree; if the component has no children, it applies to the parent's subtree. Some application developers or tooling environments may prefer specifying this behavior with an attribute: apply="children|parent". Differently named components could also be created for the two cases.

The container component has the advantage of being applicable to all types of components. The disadvantage is that container components introduce more complexity when viewed in tools at design time and are more tedious to use when hand-coding pages (because the closing tag must be kept track of).

The marker component has the advantage of being easy to insert into the page, but may require an auxiliary component to be applied to a region (such as a panelGroup).

This JIRA discusses a general feature. An ice:config tag has been added in

http://jira.icefaces.org/browse/ICE-4552