myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Werner Punz (JIRA)" <...@myfaces.apache.org>
Subject [jira] Issue Comment Edited: (MYFACES-2585) ajax doesn't work if target contains script with CDATA
Date Sat, 06 Mar 2010 14:14:27 GMT

    [ 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.


Mime
View raw message