Porting steps:

DOMContext calls should first be ordered so that the elimination step is clear:

Element table = domContext.createElement(HTML.TABLE_ELEM);
Element calendarDiv = domContext.createElement(HTML.DIV_ELEM);
calendarDiv
.setAttribute(HTML.ID_ATTR, clientId + CALENDAR_POPUP);

table.setAttribute(HTML.ID_ATTR, clientId + CALENDAR_TABLE);

Element positionDiv = domContext.createElement(HTML.DIV_ELEM);
positionDiv.appendChild(table);
calendarDiv.appendChild(positionDiv);
root.appendChild(calendarDiv);

should be replaced with:

Element calendarDiv = domContext.createElement(HTML.DIV_ELEM);
calendarDiv.setAttribute(HTML.ID_ATTR, clientId + CALENDAR_POPUP);

Element positionDiv = domContext.createElement(HTML.DIV_ELEM);

Element table = domContext.createElement(HTML.TABLE_ELEM);
table.setAttribute(HTML.ID_ATTR, clientId + CALENDAR_TABLE);

positionDiv.appendChild(table);

calendarDiv.appendChild(positionDiv);
root.appendChild(calendarDiv);

All setAttribute() calls to an element immediately follow the associated createElement(), and no other calls to DOMContext are permitted until the setAttribute calls are complete.
No further reference to an element is permitted after appendChild(element) is called.

The component should be tested once re-ordering is complete and no behavioural changes should be observed.

This allows the next step in the transformation:

writer.startElement(HTML.DIV_ELEM, component); //calendarDiv
writer.writeAttribute(HTML.ID_ATTR, clientId + CALENDAR_POPUP, null);

writer.startElement(HTML.DIV_ELEM, component); //positionDiv

writer.startElement(HTML.TABLE_ELEM, component); //table
writer.writeAttribute(HTML.ID_ATTR, clientId + CALENDAR_TABLE, null);

writer.endElement(HTML.TABLE_ELEM); //table

writer.endElement(HTML.DIV_ELEM); //positionDiv
writer.endElement(HTML.DIV_ELEM); //calendarDiv

The DOM element variable names should be added as comments to assist with the endElement() arguments. Once the component is ported, the comments may be removed.

For regression testing, we could capture the current output of rendering each component, with varying property values, to the dom, then serialising that dom sub-tree to xml / html. Then, after changing the component we could similarly capture the response writer output, and then compare that to the original output, to detect regressions.

This is becoming critical to the ice: components working correctly when embedded in ace: components or <f:ajax> tags that use partial tree rendering.

When using partial tree rendering, we might be able to side-step this issue by creating a ind of DOMContext that works on just the partial sub tree, without a greater dom.

Tentatively scheduled for 3.4.

First step is to audit the compat components to see which still use this rendering technique.

See Document5.txt.

This is no longer relevant since the Compat components are not supported in ICEfaces 4.