2:20 a.m.
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