Jacob Hookom wrote:
> From only reading:
>
> http://shale.apache.org/shale-remoting/index.html
>
> What happens if I call something like this:
>
> /dynamic/applicationScope/clear.jsf
>
> ?
Presuming you have mapped FacesServlet to *.jsf, that will resolve to a
"resource id" (in Shale Remoting terms) of
"/dynamic/applicationScope/clear" which of course would do nasty things
to your application scope variables. You can now configure
include/exclude patterns for all the processors -- there are reasonable
defaults on the classpath and webapp resources, but not yet yet on the
dynamic stuff ... your thought triggers a good scan for some default
excludes for the "/dynamic/*" pattern.
But this only works if you actually report back to the originating
project. Simply walking away from code who does things it shouldn't is
not living up to your responsibility to improve the overall open source
ecosystem.
Craig
>
>
>
> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
>