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