s:decorate + a4jsf tidy filter causes silent a4jsf failures ----------------------------------------------------------- Key: JBSEAM-2549 URL: http://jira.jboss.com/jira/browse/JBSEAM-2549 Project: JBoss Seam Issue Type: Bug Components: JSF Controls Environment: Seam 2.0.1CR, Richfaces 3.1.4CR4, Jboss 4.2.x Reporter: Stuart Robertson In short, the tidy filter can cause ajax behaviors to silently fail in a manner that is nearly impossible to troubleshoot. This occurs if the tidy filter silently removes markup that it determines isn't valid html, meaning that the browser client receives less markup than the component tree actually renders. Here's how I ran into this, and how you can reproduce. First, create a s:decorate-suitable file that renders an input control as a series of columns: <ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xmlns:s="http://jboss.com/products/seam/taglib"> <td class="name #{invalid?'errors':''}"> <s:label styleClass="label"><ui:insert name="label"/></s:label> <s:span styleClass="required" rendered="#{required}">*</s:span> </td> <td class="value #{invalid?'errors':''}"> <s:validateAll> <ui:insert/> </s:validateAll> </td> <td class="errorcolumn"> <s:message styleClass="error errors"/> </td> </ui:composition> Now include this in a table which is referenced in a reRender attribute. Expected behavior would be that the above would come back in the output, and be inserted into the dom client-side. In fact, the above doesn't get included in the ajax response at all. Why? Here's what the default configuration of the a4jsf filter does: 02:56:34,824 DEBUG [SeamPhaseListener] committing transaction after phase: RENDER_RESPONSE 6 02:56:34,837 DEBUG [BaseXMLFilter] Process response to well-formed XML for AJAX XMLHttpRequest parser 02:56:34,837 DEBUG [ConfigurableXMLFilter] default tidy parser properties loaded 02:56:34,838 DEBUG [TidyParser] Print output as XML 02:56:34,844 DEBUG [TidyParser] Message for HTML parsing : missing <!DOCTYPE> declaration 02:56:34,844 DEBUG [TidyParser] Message for HTML parsing : inserting missing 'title' element 02:56:34,845 DEBUG [TidyParser] Message for HTML parsing : missing <tbody> 02:56:34,850 DEBUG [TidyParser] Message for HTML parsing : missing <tbody> 02:56:34,850 DEBUG [TidyParser] Message for HTML parsing : <div> isn't allowed in <tr> elements 02:56:34,850 DEBUG [TidyParser] Message for HTML parsing : missing </div> before <td> ... and so on. TidyParser happily trims out invalid html. Which is fine I guess, but nothing makes it clear that this is what is happening. Suddenly the richfaces ajax magic stops working... Absolutely maddening (this kept me busy for about a day, I'm embarrassed to say). A few suggestions. One is to think of how Seam/Ajax4Jsf can communicate to a developer when a destructive parser is responsible for removing markup from a rendered view. One suggestion would be to add something to the xml response, a flag or something, indicating that tidy removed content. Another would be to write out a message to INFO when the TidyParser removed markup. I'm not sure I understand why TIDY is enabled by default (as in this is how seamgen-produced projects are setup). This same markup is presented to the browser directly when not sent via an ajax update, and given that most seam projects are using facelets, the markup is at the very least well formed. I can see how TIDY may be useful at a certain point in development, but to have it on by default, where it can silently break ajax functionality and also eat up resources in production... hmm. Another issue this highlights is that s:decorate seems to be needlessly limited. Why must it wrap content in a div? DecorateRenderBase renders a div in all cases, which is a shame. It means we can't decorate input controls as I attempted above without causing Tidy to (correctly?) point out that divs can't come between a <tr> and it's <td>. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira