Jacob Hookom wrote:
> 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.
Right, but in this case the <script> tag is coming from Ed's
"AjaxZoneRenderer" and the writer in JSF is throwing in the CDATA
stuff. I am not modifying anything before the response is written...
and don't want to start doing that if I can avoid it. I also don't want
to modify his renderer / or JSF (obviously)...
Anyway, after getting everything working, rebuilding the appserver in a
clean env. to try again... running into shale configuration problems...
I ended up modifying Ed's code to remove shale. The 30 lines of code
that project saved wasn't worth while... I can already ready resources
out of a .jar in my project anyway. I would like to work with Ed to
make the resource resolution code plugable so I can do this in a clean
way. I saw your bug filed to remove the shale dependency -- I agree
this is a good idea considering the overhead / configuration issues it
causes. I hope shale slims down and becomes easier to use... I like the
concept.
>
> 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.
Yep, I liked your blog's proposal. I hope "Dynamic Faces" moves in that
direction.
Ed, are you out there? What do you think?
Ken Paulsen
ken.paulsen_at_sun.com
https://jsftemplating.dev.java.net
>
> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
>