A test case has been checked into the repository

repo/support/iraptor/1000/332

Further analysis is required on this. I have a hunch that the form in this case
could be replaced by any component tag (that supports children) or html tag
(that supports children). But that's just a comment on the work-around and I
don't think we've made it close to the solution or even the real problem.

I think the problem is:

h:outputText instances are rendered as text nodes, text nodes do not support ids
when there is no surrounding naming container, there is no id on the h:outputText
the update is being sent to the browser, in this case it should be a "body swap"
the bridge is failing to apply the change for some reason

I think our first step is to verify that the domupdate is being sent to the
browser, and is a body swap.

I guess, the following tastcase is not checked in to the repository:
repo/support/iraptor/1000/332

I ran the testcase, and I identified that ICEFaces properly pushing the data
to the client whether form has been used or not, and sending proper DOM
updates, but browser does not seem to be applying it. The following DOM update
being sent by the ICEFaces, when no form is used in the JSF page.

1 ^<P id="icesoftXhtmlID12">Wed Mar 15 09:50:59 MST 2006<br></P>
1 ^<P id="icesoftXhtmlID12">Wed Mar 15 09:51:00 MST 2006<br></P>
1 ^<P id="icesoftXhtmlID12">Wed Mar 15 09:51:01 MST 2006<br></P>
1 ^<P id="icesoftXhtmlID12">Wed Mar 15 09:51:02 MST 2006<br></P>

So I am assining this bug to Mircea.

Right now ICEFaces relies on the presence of forms in JSF templates.

Add to known issues.

Assign to Mircea, target v1.1. This seems like a duplicate of 454 to me.

Lower priority, out of scope for v1.1. release.

JSF Standard Behavior:

1. All JavaServer Faces pages are represented by a tree of components, called a view. The view tag represents the root of the view.
2. All JavaServer Faces component tags must be inside of a view tag, which is defined in the core tag library.
3. The form tag represents an input form component, which allows the user to input some data and submit it to the server, usually by clicking a button. 4. All UI component tags that represent editable components (such as text fields and menus) must be nested inside the form tag.

So, 1st question, do ICEfaces 2.0 components conform to the above spec., or do all ICEfaces comps. need to be in a form regardless?
2nd question is what happens with none-editable components such as tabSet, that do have a selectedIndex value?

The limitations outlined above (input and action components must be included in a form) are recognized as standard within JSF. As such, ICEfaces complies with this standard.