[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2549) s:decorate + a4jsf tidy filter causes silent a4jsf failures

Stuart Robertson (JIRA) jira-events at lists.jboss.org
Tue Jan 29 03:20:09 EST 2008

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"

	<td class="name #{invalid?'errors':''}">
	    <s:label styleClass="label"><ui:insert name="label"/></s:label>
	    <s:span styleClass="required" rendered="#{required}">*</s:span>
	<td class="value #{invalid?'errors':''}">
	<td class="errorcolumn">
		<s:message styleClass="error errors"/> 

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


More information about the seam-issues mailing list