[
https://issues.apache.org/jira/browse/TRINIDAD-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12873948#action_12873948
]
Paul Mander commented on TRINIDAD-1073:
---------------------------------------
Thanks Naveen,
You posted an alternative solution also that reduces the amount of parsing by
just addressing the text input contents. I've included this here for
completeness:
In XMLRequest.js
TrRequestQueue.prototype._getPostbackContent = function(actionForm, params)
current.push(input.value);
}
else
{
//FIX:start
// encoding only characters entered in text box
if(input.type == "text"){
formParams[input.name] =
encodeCharacters(input.value);
}else{
//FIX:end
formParams[input.name] = input.value;
//FIX:start
}
//FIX:start
}
This addresses any performance issues with javascript string concatination:
http://www.softwaresecretweapons.com/jspwiki/javascriptstringconcatenation
However, I don't think this fix can be accepted by Trinidad as it subsequently
breaks all the other app servers that appear to be working ok. I still think
this is a WebSphere issue even though they refuse to fix it. But unfortunately
we wont be able to tell from the js what the app server is unless we either
have a configuration setting or there is some conditional includes based on the
app server vendor and version (as this will likely be a problem only in WAS 6.x)
> Character encoding problem with PPR on IBM WebSphere 6.0
> --------------------------------------------------------
>
> Key: TRINIDAD-1073
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1073
> Project: MyFaces Trinidad
> Issue Type: Bug
> Affects Versions: 1.0.7-core
> Environment: MyFaces 1.1.5
> IBM WebSphere 6.0
> Windows XP SP2
> Reporter: Vadim Dmitriev
>
> Input fields updated via PPR replace cyrillic characters with question marks.
> There is no encoding problems if update is performed with ordinary form
> submit.
> Simple testcase:
> create JSF page with tr:showDetailHeader containing tr:inputText. Type some
> cyrillic characters in the input field. Close/open detailheader. As a result
> cyrillic chars in the inputText will be replaced with question marks.
> There is no problem with encoding whatsoever if that showDetailHeader is
> updated by ordinary update (navigation from/to that page, for example).
> This problem is specific to WebSphere 6.0 (maybe 6.1 too, never had a chance
> to check it). I tried the same testcase on OC4J 10.3.3.2 and everything went
> fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.