Some more info... if I switch Ed's code to text/html, the JS that
replaces the content is not recognized as XML (b/c it's not anymore)...
so nothing happens with the (now valid) response. So I guess AjaxZones
are broken for now unless there's work-a-round I haven't thought of.
In the mean time, fireAjaxRequest works as long as there aren't any
embedded CDATA sections -- such as those provided by JSF when rendering
any "Script" element (I still think this belongs at the component level,
not the writer level).
Thanks!
Ken Paulsen
ken.paulsen_at_sun.com
https://jsftemplating.dev.java.net
Ken Paulsen wrote:
>
> Hi Jacob,
>
> I remember when Ryan made this change b/c I had to fix my ViewHandler
> to work with it. I had tried both text/html and application/xhtml+xml
> on the page w/o success. However, after your email, I looked into
> this more and found that Ed's PartialTraversalViewRoot sets the
> content-type to text/xml, which ends up being sent to the browser as
> application/xhtml+xml. I experience the problem in both the RI
> ViewHandler and mine. I could override the content-type in my
> ViewHandler, but I don't think it's a good idea to blindly override
> this... for now I think I'll change Ed's code to not return text/xml.
>
> Thanks for the help!
>
> Ken
>
> Jacob Hookom wrote:
>> The issue can be bypassed a bit by telling the RI's ResponseWriter to
>> not use XHTML by passing 'text/html' to the RenderKit's constructor
>> within your ViewHandler. This will prevent the RI from forcing CDATA
>> blocks around the script it generates for commandLinks/etc.
>>
>> Although you are supposed to be able to 'escape' CDATA with ']]]]>'
>> for inner tails, it doesn't seem to be handled in the browsers. More
>> info on the problem here:
>>
>> http://weblogs.java.net/blog/jhook/archive/2006/12/ajax_responses.html
>>
>>
>>
>> Ken Paulsen wrote:
>>>
>>> Hi Ed (or anyone else that knows),
>>>
>>> Are AjaxZones currently broken? I get "mismatched tag" errors on
>>> the partial response sent back from the server. I am using the
>>> latest version of JSF (1.2_03-b06-FCS), which may be contributing to
>>> the problem. It appears that the CDATA tags around the
>>> DynaFacesZones.ajaxifyChildren(...) in the response is causing the
>>> problem.
>>>
>>> Below is a JSP w/ a single button in an AjaxZone that demonstrates
>>> the problem.
>>>
>>> Thanks,
>>>
>>> Ken Paulsen
>>> ken.paulsen_at_sun.com
>>> https://jsftemplating.dev.java.net
>>>
>>>
>>> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
>>> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
>>> <%@ taglib prefix="jsfExt"
>>> uri="http://java.sun.com/jsf/extensions/dynafaces" %>
>>>
>>> <f:view>
>>> <html>
>>> <head>
>>> <title>DynaFaces JSP Blank App</title>
>>> <jsfExt:scripts />
>>> </head>
>>> <body bgcolor="white">
>>>
>>> <h:form id="form">
>>>
>>> <h1>DynaFaces JSP Blank App</h1>
>>>
>>> <jsfExt:ajaxZone id="zone1">
>>> <h:commandButton value="ZONE Request FOO" />
>>> </jsfExt:ajaxZone>
>>>
>>> </h:form>
>>>
>>> </body>
>>> </html>
>>> </f:view>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_jsf-extensions.dev.java.net
>>> For additional commands, e-mail: dev-help_at_jsf-extensions.dev.java.net
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsf-extensions.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsf-extensions.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsf-extensions.dev.java.net
> For additional commands, e-mail: dev-help_at_jsf-extensions.dev.java.net
>