The encodeEnd() method of MenuRenderer which makes use of FastStringWriter to embed the text node in the DOM does allow for a "multiple" select option.

Regex implementation checked in but not verified with multiple select cases. The previous intermediate-DOM based version could not be repaired due to the output differences between the original component and the intermediate DOM output.

Modified Test2.zip to include ampersand markup as well as changed the test logic to accept a selection of "3" (this allows the testing of changed input values that should not result in a page update).

Since the DOM parser version changes the order of value="" and selected="", it is essentially guaranteed to modify the TextNode for any interaction with the component, thereby forcing an update of that component.

Can see the issue with the following code:

<h:selectOneMenu id="testMenu"
value="#

">
<f:selectItem itemValue="1" itemLabel="One & One"/>
<f:selectItem itemValue="2" itemLabel="Two and Two"/>
</h:selectOneMenu>

Ideas to resolve:

• Use HTML DOM if available in JDK.
• Experiment with DOCtypes for DOM
• Add entity characters to DOM
• Use regular expression or other technique to replace entity chars in the string.

Also reverted on icefaces3/trunk: Committed revision 27993

Re-opened due to regressions.

Arran McCullough: Throws SAXParseExceptions with customer application.

All browsers and this doctype: <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

I think it might be related to them using & in the selectItem label.

— Ken Fyten:

I've reverted this commit on ossrepo/icefaces3/branches/icefaces-3.0.x-maintenance branch for EE 3 Beta release.

The problem was in the method I had thought, but the reason was completely different than I had anticipated. Basically, there was no omission in the select and option node processing code. Rather, for Mojarra, but not MyFaces, the h:selectOneMenu rendering does not follow the standard ResponseWriter APIs of opening and closing tags, which our DOMResponseWriter uses to build DOM nodes. Instead, they have a performance optimisation where they render into a String buffer, and then write that out as text. So what we have in our dom is a Text node, which does not allow for proper applyBrowserChanges processing.

We contemplated overriding the renderer to allow for proper dom adhering output, but that would have involved overriding a lot of renderer code, that would then need to be maintained. Instead, I thought of a solution whereby we parse the text node, derive the nodes, update the nodes with the typical applyBrowserChanges processing, and then update the actual dom with the new nodes. The idea beig that code path would only execute under very specific circumstances, and wouldn't affect anything else, and would be easy to make a regression test for, since we have the one for this jira.

One snag I ran into, was I had assumed that I would import the new nodes into our dom, and had that code functioning, but then the dom difference was between nodes and the always rendered text node. So I then printed out the nodes into a string, and updated the text node with that string. There was some effort in getting the whitespace to render properly and similarly.

There's still a lingering aspect, which I believe we can safely ignore. Our option node updating code outputs W3C compatible markup, which is <option selected="selected"> whereas Mojarra h:selectOneMenu rendering gives <option selected="true">. So in theory we can get false positives in our dom difference, and update more of the page than necessary. But the real bug is failing to update what has changed, so it's not a real problem.

trunk
27937

icefaces-3.0.x-maintenance
27938

Start off with seeing what's going on in:
org.icefaces.impl.context.DOMPartialViewContext.applyBrowserChanges(Map parameters, Document document)

Source code