From only reading:
http://shale.apache.org/shale-remoting/index.html
What happens if I call something like this:
/dynamic/applicationScope/clear.jsf
?
Craig McClanahan wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> 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
>
>