[
https://issues.apache.org/jira/browse/MYFACES-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12841926#action_12841926
]
Werner Punz edited comment on MYFACES-2585 at 3/6/10 2:13 PM:
--------------------------------------------------------------
Ok Jim Driscoll cleared this up for me, he was implementing it for Mojarra as
CDATA escape pattern
I looked up the xml spec comments and it said that everything except ]]> is
allowed in a cdata block
so we can either drop the entire CDATA section or replace it with ![CDATA[
any pending ]]> must be replaced with something neutral section in case of an
open CDATA block
so a user cannot trigger the usecase per xml definition I mentioned. I think we
can live with the way mojarra does it,
and page authors have to be aware with its limitations.
In any case we have to fix the problem that users might issue nested CDATA
blocks since the spec clearly states in section:
13.4.4.1 Writing The Partial Response
Implementations must take care to properly handle nested CDATA sections when
writing the response.
Which we have not covered yet, I have already written a PPRResponseWriterImpl
which does some double buffering on issued CDATA blocks and supresses nested
CDATA, it also does a needed rewriting which catches the facelets //<![CDATA[
and ]]> //]]> cases and removes them to get a proper cdata block here.
I hope this is enough post processing to cover this problem so that it does not
become a problem for the component authors. I will commit this on monday, I
need to do some testcases and additional testing first before committing this,
since I change a vital part of the JSF2 PPR processing here.
I also did not push this code into our PPRResponseWriter, but went straight for
an impl class to get some separation of concerns and, since the spec clearly
states impls have to take care of that I think I am fine with it.
I hope the TCK wont choke on what I am going to do here.
was (Author: werpu):
Ok Jim Driscoll cleard this up for me, he was implementing it for Mojarra
as CDATA escape pattern
I looked up the xml spec comments and it said that everything except ]]> is
allowed in a cdata block
so we can either drop the entire CDATA section or replace it with ![CDATA[
any pending ]]> must be replaced with something neutral section in case of an
open CDATA block
so a user cannot trigger the usecase per xml definition I mentioned. I think we
can live with the way mojarra does it,
and page authors have to be aware with its limitations.
I will commit a patch on monday.
> ajax doesn't work if target contains script with CDATA
> ------------------------------------------------------
>
> Key: MYFACES-2585
> URL: https://issues.apache.org/jira/browse/MYFACES-2585
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Affects Versions: 2.0.0-beta-2
> Environment: Javascript, API, IMPL...
> Reporter: Ganesh Jung
> Priority: Critical
>
> This doesn't work:
> <h:inputText value="#{numberBean.myNumber}">
> <f:ajax render="test" />
> </h:inputText>
> <h:panelGroup id="test">
> <script type="text/javascript">
> //<![CDATA[
> alert("running");
> //]]>
> </script>
> <h:inputText value="#{numberBean.myNumber}" />
> </h:panelGroup>
> But this works fine:
> <h:inputText value="#{numberBean.myNumber}">
> <f:ajax render="test" />
> </h:inputText>
> <h:panelGroup id="test">
> <script type="text/javascript">
> alert("running");
> </script>
> <h:inputText value="#{numberBean.myNumber}" />
> </h:panelGroup>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
