[
https://issues.apache.org/jira/browse/MYFACES-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842476#action_12842476
]
Werner Punz edited comment on MYFACES-2585 at 3/7/10 8:38 PM:
--------------------------------------------------------------
Ok sounds like I was a little bit too much focused on other things, back to
square one, what Driscoll proposed
]]> can be escaped by the construct of <![CDATA[]]]]><![CDATA[>]]>, if the spec
allows multiple CDATA blocks within update and delete we are set on this
solution + removing the //]]> and //<![CDATA[ it has the advantage that no
further client processing is needed and all can be resolved on the server back
double buffering and stacking double buffers, depending on the nesting depth of
the issued cdata...
And yes Jan I agree here, nested CDATA is a user error, but that does not mean
we should not escape it, if the user does CDATA nesting he has to live with the
result, escaping the CDATA depending on the nesting depth in my opinion if we
can do it that way due to the spec is the only viable and correct solution.
But I have to add to that that within the ppr cycle the content already is in a
CDATA block which means we get a deeper nesting depth than the original user
intented to have.
was (Author: werpu):
Ok sounds like I was a little bit too much focused on other things, back to
square one, what Driscoll proposed
]]> can be escaped by the construct of <![CDATA[]]]]><![CDATA[>]]>, if the spec
allows multiple CDATA blocks within update and delete we are set on this
solution + removing the //]]> and //<![CDATA[ it has the advantage that no
further client processing is needed and all can be resolved on the server back
double buffering and stacking double buffers, depending on the nesting depth of
the issued cdata...
And yes Jan I agree here, nested CDATA is a user error, but that does not mean
we should not escape it, if the user does CDATA nesting he has to live with the
result, escaping the CDATA depending on the nesting depth in my opinion if we
can do it that way due to the spec is the only viable and correct solution.
> 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.
