Note: Calendar uses immediate=true

full

Clicking on calendar dates does up to apply request values, then render response
Typing 1 letter into input and bluring, does up to validations, then render
Clicking on calendar, after 1 letter, does up to apply request values, then render response

just-ice

Clicking on calendar dates does all phases.
Typing 1 letter into input and bluring, does up to validations, then render
Clicking on calendar, after 1 letter, does up to validations, then render

Not sure why, but the just-ice version works fine on tomcat 5 though. Build it using: ant clean tomcat5.x -Djust-ice="just-ice"

Ignoring the issue of the ice:inputText field and its validation, let's look at the ice:selectInputDate component itself.

• With full ICEfaces, clicking on a calendar date will do up to Apply Request Values phase.
• With just-ice.jar, clicking on a calendar date will do all phases.

• With full, the ice:commandLink that the calendar internally uses for each calendar day, queues an ActionEvent, which causes the internal JSF code that invokes any actionListener or action to call FacesContext.renderResponse(). This is correct.
• With just-ice.jar, no ActionEvent is queued, so FacesContext.renderResponse() is not called. This is incorrect.

SelectInputDateRenderer creates the HtmlCommandLink child components, and marks them transient, so that next render it can make new ones. It does this because it actually does the decode for the link itself, and does not want the HtmlCommandLinks to do the decode themselves. But, SelectInputDate[Renderer] does not invokeFacesContext.renderResponse() itself when immediate=true. It is relying on the HtmlCommandLink to do that, even though it has marked it transient, to not exist, and not decode. This is incorrect.

• With full, the transient components exist on decode. This is incorrect.
• With just-ice.jar, the transient components do not exist on decode. This is correct.

• With full, we set <state-manager>com.icesoft.faces.application.ViewRootStateManagerImpl</state-manager> in the faces-config.xml, which saves the whole component tree, which is why the transient components remain. This is non-standard.
• With just-ice.jar, the default StateManager only state saves the non-transient components, effectively clearing them away. This is correct.

The SingleCopyStateManagerImpl code appears to do the standard behaviour of only state saving non-transient components.

So, I believe that the child HtmlCommandLink components should be created once, not marked transient, but not allowed to decode, and SelectInputDate[Renderer] should call FacesContext.renderResponse() if immediate == true.

Aside from that, I believe that the core should use SingleCopyStateManagerImpl instead of ViewRootStateManagerImpl.

Further testing showed that the full ICEfaces version would do wither the full lifecycle, or just apply request values, depending on which links you clicked. So I brought it in line with UIInput standard behaviour, and just-ice behaviour, of doing all the phases, when immediate=true. This then fixed the regression as well.

TRUNK
Subversion 20968
icefaces\component\src\com\icesoft\faces\component\selectinputdate\SelectInputDateRenderer.java

icefaces-ee-1.8.2
Subversion 20970
icefaces\component\src\com\icesoft\faces\component\selectinputdate\SelectInputDateRenderer.java

Verified successfully on ICEfaces-ee-1.8.2 revision 20970
Verified on Tomcat 6 using FF3.5.8 and IE8

1)Type a letter in inputtext field & tabout
2)validation error is displayed (as expected)
3) now with validation error still on page, click on a date in calendar
Should this work? or is this not expected to work till the inputtext validation error is corrected.

Worked with Mandeep to amend the test case.