Postby Sesztak » Mon Jul 18, 2016 4:30 am
dear JS-Support,
We have done what you advised, please, find our results as follows:
just for your kind information:
-1st problem -I do not know if that will be a problem or not in the future BUT definitely problem with manual replace case:
even if we not using any extended ASCII characters in type names (Class and Property names) we have found a several hundreds '\x' in our YOURAPPLICATIONAME.js file:
why ? because we use a lot of extended ASCII characters in the Content of Buttons, TextBlocks, in Headers of TabItems etc.
Generally speaking in the 'Text' part of UI Controls
For e.g.: <TabItem Header="Tranzakciók">
So, if we change all '\x' to '$' in our YOURAPPLICATIONAME.js file we got scambled texts in the UI,
for example: 'Tranzakciók' change to 'Tranzakci$f3k'
Please, confirm, that your bugfix will not modify the UI part of texts (like button Content).
-2nd problem: if make a test class at WCF Server + an interface and an methode implementation using this type:
[Serializable()]
[DataContract(IsReference = true)]
public class TéstClássWithExtendedASCIIchars
{
[DataMember]
public int SomeTestProperty { get; set; }
[DataMember]
public int GetNumbersOfPokémon { get; set; }
[DataMember]
public string GetNameOfRésumé { get; set; }
// self reference test :
[DataMember]
public List<TéstClássWithExtendedASCIIchars> ChildrenList { get; set; }
}
interface:
[OperationContract]
TéstClássWithExtendedASCIIchars TestMetodWithCustomTypesWithExtenedASCIIcharsInName(TéstClássWithExtendedASCIIchars parameter);
implementation:
public TéstClássWithExtendedASCIIchars TestMetodWithCustomTypesWithExtenedASCIIcharsInName(TéstClássWithExtendedASCIIchars parameter)
{
return new TéstClássWithExtendedASCIIchars() { SomeTestProperty = parameter.SomeTestProperty + 1 };
}
+Update the WCF ServiceReference at Client side, rebuild the project,
+change all '\x' to '$' in our YOURAPPLICATIONAME.js
+host the web page + WCF service in IIS 10.
We have got client side exception at CSHTML5 in client side browser when we try to call the function using this type:
"System.ServiceModel.FaultException: Hiba a(z) „TestMetodWithCustomTypesWithExtenedASCIIcharsInName” művelet kérelemüzenet-törzsének deszerializálása során.", something like in English: FaultException during deserialization of request message body.
-3rd case: Last, but not least some very good news:
if we try to initialize the object of extended ascii chars in type and props name:
it works if we change all '\x' to '$' in our YOURAPPLICATIONAME.js file as you advised.
Let me emphasize:
--3a: object initialization: works,
--3b: object xml serialization (with the purpose to send to server): works only in Simulator as '\x' to '$' change destroy the serialized XML format,
--3c: webSocketService1.Send(serializedXML); works correctly only in Simulator az serializedXML string content will be destroyed because of above mentioned point 3b.
--I have no idea / I have no clue what is the meaning of '\x' and '$' in JavaScript.
Sample client side related source codes:
object initialization -ok !:
Kassza_WCFServiceLib.TéstClássWithExtendedASCIIchars _TéstClássWithExtendedASCIIchars =
new Kassza_WCFServiceLib.TéstClássWithExtendedASCIIchars()
{
GetNameOfRésumé = "Résumé Péter öüóőúéáűí", // GetNameOfRésumé = "Résumé Péter öüóőúéáűí", "Resume Peter no extended ascii chars"
GetNumbersOfPokémon = 14,
SomeTestProperty = -13,
ChildrenList = new List<Kassza_WCFServiceLib.TéstClássWithExtendedASCIIchars>()
{ new Kassza_WCFServiceLib.TéstClássWithExtendedASCIIchars() {
ChildrenList =null,
GetNameOfRésumé="Subé Béatrice",
GetNumbersOfPokémon =7,
SomeTestProperty= -6} }
};
object xml serialization: ok only in Simulator ! :
string serializedXML = KasszaWEB_Kliens.XmlSerialization.Serialize(_TéstClássWithExtendedASCIIchars);
websocket send: ok only in Simulator !:
webSocketService1.Send(serializedXML);
So, to summarize 1-3 point:
S1./ if you plan to change ALL chars from '\x' to '$' simply: very bad result: it has more disadvantages, than benefits.
If you plan to change ONLY in Class, Property names AND leave other label like titles like button-textbox Content, tabitem headers untouched: it should be ok.
S2./ WCF related deserialization problem: I do not know it is coming from the type mismatch of Server - Client object versions (because we changed / modified the client object version) or not,
all what we did: warn to you the present state.
S3./, WebSocket based solution: I hope accoding S1 point it will work.
Waiting for your kind reply or if you have any question, just mention.
I hope it helps,
Best Regards,
Péter