You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Xavier Brénuchon (JIRA)" <de...@myfaces.apache.org> on 2010/02/10 18:38:28 UTC
[jira] Created: (TRINIDAD-1719) ajax xml response is not valid in
some cases
ajax xml response is not valid in some cases
--------------------------------------------
Key: TRINIDAD-1719
URL: https://issues.apache.org/jira/browse/TRINIDAD-1719
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.13-core
Reporter: Xavier Brénuchon
Hello,
There is a probleme with ajax calls in trinidad 1.2.13 (not with 1.2.9).
For exemple : I want use a table with a sortable colomun. When I click on the column header, there is an ajax call.
But the xml response is not valid and the page made a repost.
The xml response is not valid because in my page (not in the table), I have, for exemple, a 'h:outputText' with accented character as value.
Indeed, this 'h:outputText' has written its value in the ajax xml output. (not in a '<fragment>', not in a CDATA section).
There is 2 problems :
First, this 'h:outputText' should not write to output, because it is not affected by the partial render (this 'h:outputText' is not in the table). (This first problem was present in trinidad 1.2.9)
Second, even if this accented value is written is the output stream and not in a cdata section, accented characters must be compatible with xml (&#x hexa; for exemple) (This problem is new in trinidad 1.2.13)
I looked at source code and I found where are bugs.
First the h:outputText is not ignored because a method must be uncommented :
PPRResponseWriter.java, ligne 219 :
/* Needed in JSF 1.2
@Override
public void writeText(Object text,
UIComponent component,
String propertyName) throws IOException
{
if (_isInsideTarget() && (text != null))
super.writeText(text, component, propertyName);
}
*/
This method must be uncomment, because for h:outputText, there is no test _isInsideTarget.
Second, In DispatchResponseConf.java, ligne 75, the content type is searched in RequestStateMap (a new class from 1.2.13) :
return (String) RequestStateMap.getInstance(context.getExternalContext()).get(__CONTENT_TYPE_KEY);
The problem is that the content type is not inserted in RequestStateMap, but always by the old way (1.2.9) ie request.setAttribut.
So trinidad don't finds content type (here :'text/xml') and uses the default HtmlResponseWriter and not XhtmlResponseWriter (see CoreRenderKit.java line 592)
So we must correct both where the content type is written :
DispatchRenderResponse.java, ligne 45 :
_request.setAttribute(DispatchResponseConfiguratorImpl.__CONTENT_TYPE_KEY, ct.getContentType());
and DispatchServletResponse.java, ligne 49 :
_request.setAttribute(DispatchResponseConfiguratorImpl.__CONTENT_TYPE_KEY, ct.getContentType());
Replace these two line with :
RequestStateMap.getInstance(_request).put(__CONTENT_TYPE_KEY, ct.getContentType());
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1719) ajax xml response is not valid in
some cases
Posted by "Xavier Brénuchon (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Xavier Brénuchon updated TRINIDAD-1719:
---------------------------------------
Status: Patch Available (was: Open)
> ajax xml response is not valid in some cases
> --------------------------------------------
>
> Key: TRINIDAD-1719
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1719
> Project: MyFaces Trinidad
> Issue Type: Bug
> Affects Versions: 1.2.13-core
> Reporter: Xavier Brénuchon
> Attachments: TRINIDAD_1719.patch
>
>
> Hello,
> There is a probleme with ajax calls in trinidad 1.2.13 (not with 1.2.9).
> For exemple : I want use a table with a sortable colomun. When I click on the column header, there is an ajax call.
> But the xml response is not valid and the page made a repost.
> The xml response is not valid because in my page (not in the table), I have, for exemple, a 'h:outputText' with accented character as value.
> Indeed, this 'h:outputText' has written its value in the ajax xml output. (not in a '<fragment>', not in a CDATA section).
> There is 2 problems :
> First, this 'h:outputText' should not write to output, because it is not affected by the partial render (this 'h:outputText' is not in the table). (This first problem was present in trinidad 1.2.9)
> Second, even if this accented value is written is the output stream and not in a cdata section, accented characters must be compatible with xml (&#x hexa; for exemple) (This problem is new in trinidad 1.2.13)
> I looked at source code and I found where are bugs.
> First the h:outputText is not ignored because a method must be uncommented :
> PPRResponseWriter.java, ligne 219 :
> /* Needed in JSF 1.2
> @Override
> public void writeText(Object text,
> UIComponent component,
> String propertyName) throws IOException
> {
> if (_isInsideTarget() && (text != null))
> super.writeText(text, component, propertyName);
> }
> */
> This method must be uncomment, because for h:outputText, there is no test _isInsideTarget.
> Second, In DispatchResponseConf.java, ligne 75, the content type is searched in RequestStateMap (a new class from 1.2.13) :
> return (String) RequestStateMap.getInstance(context.getExternalContext()).get(__CONTENT_TYPE_KEY);
> The problem is that the content type is not inserted in RequestStateMap, but always by the old way (1.2.9) ie request.setAttribut.
> So trinidad don't finds content type (here :'text/xml') and uses the default HtmlResponseWriter and not XhtmlResponseWriter (see CoreRenderKit.java line 592)
> So we must correct both where the content type is written :
> DispatchRenderResponse.java, ligne 45 :
> _request.setAttribute(DispatchResponseConfiguratorImpl.__CONTENT_TYPE_KEY, ct.getContentType());
>
> and DispatchServletResponse.java, ligne 49 :
> _request.setAttribute(DispatchResponseConfiguratorImpl.__CONTENT_TYPE_KEY, ct.getContentType());
> Replace these two line with :
> RequestStateMap.getInstance(_request).put(__CONTENT_TYPE_KEY, ct.getContentType());
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.