[ http://jira.jboss.com/jira/browse/JBSEAM-2549?page=all
]
Norman Richards updated JBSEAM-2549:
------------------------------------
Fix Version/s: 2.1.0.GA
(was: 2.1.0.A1)
> 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 Integration
> Environment: Seam 2.0.1CR, Richfaces 3.1.4CR4,
Jboss 4.2.x
> Reporter: Stuart Robertson
> Assigned To: Pete Muir
> Priority: Minor
> Fix For: 2.1.0.GA
>
>
> 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.su
n.com/jsf/facelets"
> xmlns:h="http://java.sun.co
m/jsf/html"
> xmlns:f="http://java.sun.co
m/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="#">*</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.atl
assian.com/software/jira
_______________________________________________
jbossseam-issues mailing list
jbossseam-issues lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbossseam-issu
es
|
