Does ICEfaces 2 really work?

According to the documentation, it should be the easiest product in the world to use:

Simply add the icefaces.jar to the application and we have Direct-to-Dom (D2D) rendering applied to the page.

But even their most basic tutorial Getting Started with ICEfaces 2 doesn't appear to work. I downloaded the code at the bottom of the page, built it into a WAR and deployed it to both Tomcat 6.0.32 and Tomcat 7.0.14. The first thing I noticed was that for some reason the composite component didn't work:

/job-applicant.xhtml @39,78 The following attribute(s) are required, but no values have been supplied for them: id.

But that feels more like a JSF issue (JSF 2 Composite component required attribute throws exception), so I resolved that by removing the required on the ID attribute (though there is still a required="true" on value that doesn't seem to have a problem). Anyway, now the app deploys. And as stated, it uses an AJAX call when you click the Clear button that ends up getting the full DOM for the form in the response XML. The next step is to add the icefaces.jar and it is supposed to add the Direct-to-DOM functionality that will ensure only the differences are sent in the response:

ICEfaces 2 renders component markup to a server-side DOM (Document Object Model) that reflects the current client view. Each time the JSF lifecycle runs a DOM comparison is done and, if there are any changes, a concise set of page updates are sent back to the client to be applied to the page. We call this Direct-to-DOM or D2D rendering.

However, I get the full form as a response, plus some additional lines of ICEfaces stuff like this:

<input name="ice.window" type="hidden" value="epgo74zmvc" />
<input name="ice.view" type="hidden" value="vs4ik661" />

So clearly, ICEfaces is doing something, but NOT what it promised. It is actually LONGER than the plain AJAX response. So ignoring the fact that it is actually a larger response, I moved on to the next promise:

With Direct-to-DOM rendering, we no longer need the f:ajax tag nested in our "Clear" button

Sounds straight forward right? In the example on the page, they just move the EL expression for the listener from the f:ajax tag to the h:commandButton tag. The problem there is that the method signatures are different. This is supposed to be the Getting Started tutorial, but it doesn't care to actually walk you through the steps. Anyway, I can fix that, by modifying the method signature of the clearForm method in the backing bean so that its argument is now and ActionEve开发者_开发技巧nt instead of AjaxBehaviorEvent. Doing that, ICEfaces does actually replace what would be a full page action with an AJAX action, which is pretty incredible, but I still have a sour taste in my mouth. Does anyone have any idea why the D2D doesn't seem to work? Am I doing something wrong? Should I still try to use ICEfaces?

---

Why do you assume that this is functioning incorrectly?

What is happening is that you get the whole form as a response so that the server side view and control state can be refreshed during the JSF lifecycle. What is really happening when you call a partial update of a form with an ajax tag is that it will only render DOM updates to the specified components.

AJAX really is at play here, but it needs to send the entire DOM or else logic on the server side could be looking at stale data.

This isn't just ICEFaces, this is JSF. In fact, this is fundamentally similar to even how ASP.NET works as well. See this link to understand the JSF lifecycle.

http://balusc.blogspot.com/2006/09/debug-jsf-lifecycle.html

I am sorry if this isn't what you expect out of the technology.

---

After ICEfaces has done its DOM comparison, it needs to send the update. To tell the client-side part of the bridge where to put the updated content, ICEfaces needs to specify some known ID of an ancestor DOM node. The server-side renderer only knows ID's of the JSF components, both autogenerated ID's and manually specified. It can't address a raw HTML tag. So my best guess for your observation of the fat update is that you're using a lot of HTML tags.

Another thing about D2D and ICEfaces bridge is that it can't add or remove a child element. It can only replace an ID-addressable tag completely. So if you, i.e. add a new row to the table, the whole table will be updated.

My knowledge is based on the ICEfaces 1.8.2 though.