[
https://issues.apache.org/jira/browse/MYFACES-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12841224#action_12841224
]
Werner Punz edited comment on MYFACES-2585 at 3/4/10 1:25 PM:
--------------------------------------------------------------
Ok I raised this one to critical because it is almost a showstopper but
basically again caused by the spec as far as I can see it.
Ok this is a huge problem, but not on the javascript side, the problem lies in
the way JSF handles the update part
The example maps roughly to following return string
<?xml version="1.0" encoding="utf-8"?><partial-response><changes><update
id="myForm:myText"><![CDATA[<span id="myForm:myText"><input
id="myForm:j_id2076757786_7bc8cfb1" name="myForm:j_id2076757786_7bc8cfb1"
type="text" value="aaaaa" />
<script type="text/javascript"><!--
//<![CDATA[
alert("hello");
//]]>
//--></script></span>]]></update><update
id="javax.faces.ViewState"><![CDATA[wAKfV4bepmBnyfeFWNCSN/IhViyGgobTvdAEvn4nKBrg3X2hhH9sIxBOFwn10jm/kEIjlw3aaS7jiAxqIC4TXvmOedIbj9MG]]></update></changes></partial-response>
What we have here is a major problem on the protocol level which I cannot even
remotely fix on the javascript side alone.
the issue we face here is simply a CDATA block within a CDATA block which the
xhr object refuses to process due to not being a proper XML!
The problem lies clearly in the protocol, which states that the data in the
<update> must be passed upwards to the xhr response processing as CDATA block
(I have to double check the spec but thats as far as I recall that part.
Now this interferes with the fact that facelets expects
//<![CDATA[
//]]>
within the body of the script tag to avoid semantic javascript parsing for
constructs like alert("<script type... />");
Ok here would be my solution, but I have to double check if we are in sync with
the spec.
Our main goal in the javascripts was to be server compatible to mojarra
(which probably has the same problem)
So plain text processing like it is done here must be done for normal cases.
But since our PPR ResponseWriter has to double buffer anyway for insert, update
etc... we could do a double check for CDATA blocks in the generated html on the
response writer side and then simply BASE64 encode the entire <update> <insert>
content, and put a prefix marker in front of it.
the javascript while processing the single tags can do a quick check for the
marker at the beginning of the response string and then if present base64
unencode the entire string for further processing.
That way we would not loose server compatibility to Mojarra and still probably
would be in the spec.
(But as I said take it with a grain of salt I have to recheck the spec here)
was (Author: werpu):
Ok this is a huge problem, but not on the javascript side, the problem lies
in the way JSF handles the update part
The example maps roughly to following return string
<?xml version="1.0" encoding="utf-8"?><partial-response><changes><update
id="myForm:myText"><![CDATA[<span id="myForm:myText"><input
id="myForm:j_id2076757786_7bc8cfb1" name="myForm:j_id2076757786_7bc8cfb1"
type="text" value="aaaaa" />
<script type="text/javascript"><!--
//<![CDATA[
alert("hello");
//]]>
//--></script></span>]]></update><update
id="javax.faces.ViewState"><![CDATA[wAKfV4bepmBnyfeFWNCSN/IhViyGgobTvdAEvn4nKBrg3X2hhH9sIxBOFwn10jm/kEIjlw3aaS7jiAxqIC4TXvmOedIbj9MG]]></update></changes></partial-response>
As you can see the problem is in the syntax itself since the spec states that
the update block must be a CDATA block, but now we have a cdata within a CDATA
block which is a huge problem, we either can fix it on the facelets side, or on
the responsewriter side. Another option probably would be a script component
which filters the CDATA out...
> 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.
