[
https://issues.apache.org/jira/browse/MYFACES-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12841868#action_12841868
]
Werner Punz edited comment on MYFACES-2585 at 3/5/10 2:20 PM:
--------------------------------------------------------------
First of all I am in the middle of coding the both approaches, it comes down to
add a PPRResponseWriterImpl which starts a double buffering responseWriter ad
the after the opening of CDATA at insert, update and eval
and then at the closing of the tag it flushes the double buffer encodet (either
sting stripped or base64 encoded)
into the original writer before calling the super.<whatever> to close the
operation
as for your issues, I am aware of the problem, for the marker I would put a
clear identifier in front of it, something along the lines
JSF_RESPONSES_BASE64: which must come at the absolute front of the section.
As for debugging yes that is a sideissue unfortunately, we could make the
encoding optional via context params and switch to the semi broken solution in
case someone wants to debug it.
another option would be simply to use another encoding scheme with more
readability, like URLEncode/Decode to cover this case!
Or even simpler add for the < And > characters pseudo escapes like &JSF_LT;
and &JSF_GT; which are not in the html standard and un likely to be rendered
ever by a user. that way readability is kept intact.
was (Author: werpu):
First of all I am in the middle of coding the both approaches, it comes
down to add a PPRResponseWriterImpl which starts a double buffering
responseWriter ad the after the opening of CDATA at insert, update and eval
and then at the closing of the tag it flushes the double buffer encodet (either
sting stripped or base64 encoded)
into the original writer before calling the super.<whatever> to close the
operation
as for your issues, I am aware of the problem, for the marker I would put a
clear identifier in front of it, something along the lines
JSF_RESPONSES_BASE64: which must come at the absolute front of the section.
As for debugging yes that is a sideissue unfortunately, we could make the
encoding optional via context params and switch to the semi broken solution in
case someone wants to debug it.
another option would be simply to use another encoding scheme with more
readability, like URLEncode/Decode to cover this case!
> 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.
