You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Pavitra Subramaniam (JIRA)" <de...@myfaces.apache.org> on 2011/01/06 23:36:46 UTC

[jira] Created: (TRINIDAD-2000) partial response writers should handle nesting of CDATA blocks.

partial response writers should handle nesting of CDATA blocks.
---------------------------------------------------------------

                 Key: TRINIDAD-2000
                 URL: https://issues.apache.org/jira/browse/TRINIDAD-2000
             Project: MyFaces Trinidad
          Issue Type: Bug
          Components: Components
    Affects Versions: 2.0.0.4-core 
            Reporter: Pavitra Subramaniam


The issue is with the use of <ui:debug> tag especially when it's placed inside a PPR-ed component (in Trinidad 2.x). The JSF UIDebug component encodes the script for this feature as follows [1] and this causes issues especially when rendering a partial page response as it's already inside another CDATA section.

This used to a problem in Mojarra as well, but I could not reproduce this with a vanilla JSF app. Turns out this issue had been resolved recently in JIRA issue 1463 [2]. The fix was made to the RI's response writer (HtmlResponseWriter) so when they write out a script or a style element they make a note of whether they are already inside a CDATA section and if so remove the (nested) CDATA block from [1].

But the above fix does nothing for a Trinidad application because we implement our own partial response writers. So this bug is to implement a similar fix.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (TRINIDAD-2000) partial response writers should handle nesting of CDATA blocks.

Posted by "Blake Sullivan (JIRA)" <de...@myfaces.apache.org>.
     [ https://issues.apache.org/jira/browse/TRINIDAD-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Blake Sullivan updated TRINIDAD-2000:
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 2.0.0-alpha-2
           Status: Resolved  (was: Patch Available)

Resolved in revision 1058396

Trinidad-2000 partial response writers should handle nesting of CDATA blocks.

Patch to fix cases where nested calls are made to startCDATA in the ResponseWriter (which will cause the CDATA block to be closed prematurely when the nested endCDATA is called) by ignoring all but the outermost CDATA block.

Also fixes places where Trinidad was outputting the start and end CDATA tokens in text to instead output them using startCDATA/endCDATA on the ResponseWriter


> partial response writers should handle nesting of CDATA blocks.
> ---------------------------------------------------------------
>
>                 Key: TRINIDAD-2000
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-2000
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>          Components: Components
>    Affects Versions: 2.0.0.4-core 
>            Reporter: Pavitra Subramaniam
>             Fix For: 2.0.0-alpha-2
>
>         Attachments: jira-2000-II.patch, uiDebugInJSF.zip, uiDebugInTrin.zip
>
>
> The issue is with the use of <ui:debug> tag especially when it's placed inside a PPR-ed component (in Trinidad 2.x). The JSF UIDebug component encodes the script for this feature as follows [1] and this causes issues especially when rendering a partial page response as it's already inside another CDATA section.
> This used to a problem in Mojarra as well, but I could not reproduce this with a vanilla JSF app. Turns out this issue had been resolved recently in JIRA issue 1463 [2]. The fix was made to the RI's response writer (HtmlResponseWriter) so when they write out a script or a style element they make a note of whether they are already inside a CDATA section and if so remove the (nested) CDATA block from [1].
> But the above fix does nothing for a Trinidad application because we implement our own partial response writers. So this bug is to implement a similar fix.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (TRINIDAD-2000) partial response writers should handle nesting of CDATA blocks.

Posted by "Pavitra Subramaniam (JIRA)" <de...@myfaces.apache.org>.
    [ https://issues.apache.org/jira/browse/TRINIDAD-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981016#action_12981016 ] 

Pavitra Subramaniam commented on TRINIDAD-2000:
-----------------------------------------------

The uploaded patch also contains a new xhtml page to test Facelets tags in Trinidad (in particular it tests the ui:debug facelets tag) 

> partial response writers should handle nesting of CDATA blocks.
> ---------------------------------------------------------------
>
>                 Key: TRINIDAD-2000
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-2000
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>          Components: Components
>    Affects Versions: 2.0.0.4-core 
>            Reporter: Pavitra Subramaniam
>         Attachments: jira-2000-II.patch, uiDebugInJSF.zip, uiDebugInTrin.zip
>
>
> The issue is with the use of <ui:debug> tag especially when it's placed inside a PPR-ed component (in Trinidad 2.x). The JSF UIDebug component encodes the script for this feature as follows [1] and this causes issues especially when rendering a partial page response as it's already inside another CDATA section.
> This used to a problem in Mojarra as well, but I could not reproduce this with a vanilla JSF app. Turns out this issue had been resolved recently in JIRA issue 1463 [2]. The fix was made to the RI's response writer (HtmlResponseWriter) so when they write out a script or a style element they make a note of whether they are already inside a CDATA section and if so remove the (nested) CDATA block from [1].
> But the above fix does nothing for a Trinidad application because we implement our own partial response writers. So this bug is to implement a similar fix.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (TRINIDAD-2000) partial response writers should handle nesting of CDATA blocks.

Posted by "Pavitra Subramaniam (JIRA)" <de...@myfaces.apache.org>.
     [ https://issues.apache.org/jira/browse/TRINIDAD-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pavitra Subramaniam updated TRINIDAD-2000:
------------------------------------------

    Status: Patch Available  (was: Open)

> partial response writers should handle nesting of CDATA blocks.
> ---------------------------------------------------------------
>
>                 Key: TRINIDAD-2000
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-2000
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>          Components: Components
>    Affects Versions: 2.0.0.4-core 
>            Reporter: Pavitra Subramaniam
>         Attachments: uiDebugInJSF.zip, uiDebugInTrin.zip
>
>
> The issue is with the use of <ui:debug> tag especially when it's placed inside a PPR-ed component (in Trinidad 2.x). The JSF UIDebug component encodes the script for this feature as follows [1] and this causes issues especially when rendering a partial page response as it's already inside another CDATA section.
> This used to a problem in Mojarra as well, but I could not reproduce this with a vanilla JSF app. Turns out this issue had been resolved recently in JIRA issue 1463 [2]. The fix was made to the RI's response writer (HtmlResponseWriter) so when they write out a script or a style element they make a note of whether they are already inside a CDATA section and if so remove the (nested) CDATA block from [1].
> But the above fix does nothing for a Trinidad application because we implement our own partial response writers. So this bug is to implement a similar fix.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.