I've played around with using ]]]]> in the response to escape nested
CDATA sections before throwing them into the <async-response>-- it
works, but as you process each rendered section, in JavaScript, you'll
need to do: chunk.replace(']]]]>',']]>'), or strip the CDATA sections up
front.
In any case, I do think that the best solution would be to move towards
a packet-like convention, removing any formatting overhead and
compressing the resulting response.
Ken Paulsen wrote:
>
> 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
>>
>
> ---------------------------------------------------------------------
> 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
>
>