Ken Paulsen wrote:
>
>
> 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.
Was anyone planning on filing a bug or RFE against Shale describing
whatever problems this causes you? Or are you guys just going to cut
and run and reinvent the pieces of remoting that you need?
> I hope shale slims down and becomes easier to use... I like the
> concept.
>>
Tell us what the problems are so we can address them.
<
http://issues.apache.org/struts>.
Craig
>> 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
>>
>
> ---------------------------------------------------------------------
> 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
>