GenoPro Home
GenoPro Home  |  Get Started With My Genealogy Tree  |  Buy  |  Login  |  Privacy  |  Search  |  Site Map
 
Util.FormatPhrase() does not encode special HTML characters


https://support.genopro.com/Topic28343.aspx
Print Topic | Close Window

By genome - Wednesday, May 11, 2011
Whilst investigating a reported issue in the Narrative Report I found what appears to be a bug in the Report Generator's Util.FormatPhrase method. 

The GenoPro SDK states that WritePhrase() and Report.Write(Util.FormatPhrase()) are equivalent.

However it appears that the two methods differ in that Util.FormatPhrase appears not to encode special characters as per Util.HtmlEncode. I have attached files for a simple skin to demonstrate this.

<html><head><title>Tester</title></head><body>
<h1>Test to check Util.FormatPhrase versus Report.WritePhrase</h1>
<%[
Report.Write(Util.FormatPhrase("{0}", "This line was produced by Report.Write Util.FormatPhrase(...) and contains the following characters that should be html encoded > < & "));
Report.WriteLn(Report.TagBr);
Report.WritePhrase("{0}", "This line was produced by Report.WritePhrase(...) and contains the following characters that should be html encoded > < & ");
Report.WriteLn(Report.TagBr);
Report.WriteText("View page source in browser to check HTML encoding");
]%>
</body></html>


 Run the skin against any .gno and examine the page source of the HTML produced. e.g.

<html><head><title>Tester</title></head><body>
<h1>Test to check Util.FormatPhrase versus Report.WritePhrase</h1>
This line was produced by Report.Write Util.FormatPhrase(...) and contains the following characters that should be html encoded > < & <br />
This line was produced by Report.WritePhrase(...) and contains the following characters that should be html encoded &gt; &lt; &amp;&nbsp;<br />
View page source in browser to check HTML encoding
</body></html>


The characters '> < &' appear unencoded from FormatPhrase.
By GenoProSupport - Wednesday, May 11, 2011
Wow.  Thanks for reporting this bug.  What would you prefer?  Do you want the method Util.WritePhrase() to not encode the HTML or you prefer we change the documentation, or we create a new method?
By genome - Wednesday, May 11, 2011
GenoProSupport (11-May-2011)
What would you prefer?  Do you want the method Util.WritePhrase() to not encode the HTML or you prefer we change the documentation, or we create a new method?


Util.WritePhrase ??   I would like Util.FormatPhrase to work as documented i.e. it should encode special characters such as <,>,& and others  in a similar way to Util.HtmlEncode and Report.WritePhrase.  If some arguments are already encoded then of course the 'h' parameter suffix (e.g. {0h} can be used to override the encoding). 
By GenoProSupport - Thursday, May 12, 2011
Util.WritePhrase ??

My mistake, I meant Report.WritePhrase().  The SDK documentation is wrong: the method Report.WritePhrase(str) is a combination of Report.WriteText(UtilFormat.Phrase(str)) instead of Report.Write(UtilFormat.Phrase(str)).

I looked at the English Narrative Report and there are 27 occurrences of Report.WritePhrase() and 79 occurrences of Util.FormatPhrase(). I wonder how safe it is to change the behavior of Util.FormatPhrase() without negative side effects.

My question is: Could there be a case where Util.FormatPhrase() is neededwithout the HTML encoding, such as in a JavaScript message or something else?  If this is the case, then GenoPro should provide another method such as Util.FormatPhraseHtml()?

I also noticed many occurrences of Util.FormatPhrase(Dic(str)).  I could add a built in method  Util.FormatPhraseDic(str).  If the method Util.FormatPhraseDic(str) shall exist, should the method Util.FormatPhraseDicHtml(str) also exists?
By genome - Thursday, May 12, 2011
Yes, having examined the Narrative Report code further I agree that changing Util.FormatPhrase now would cause undesirable knock on effects to existing code. I must have realised in the past that Util.FormatPhrase does not encode HTML as many of the instances of use indicate this (e.g. subsequent calls to HtmlEncode on the result).  

In hindsight it is a shame that the uniformity between WritePhrase and FormatPhrase is not there.

It also means that the section in the SDK on the HTML argument also needs some clarification as clearly it does not apply to Util.FormatPhrase, only to WritePhrase/WritePhraseDic

As regards proposal for FormatPhraseHtml and FormatPhraseDicHtml I can live without these. I am happy to just wrap the call to Util.FormatPhrase with Util.HtmlEncode when required to achieve the required result.  The report has a number of 'Dic' variants eg. StrDicExt  providing backwards compatibility and StrDicMFU (male/female/undefined) and so a Dic variant to FormatPhrase would be of limited value.

I summary then perhaps the only action required is to correct the SDK documentation. One possible extension to the SDK interface would be to have an 'Encode HTML argument' as the converse to the documented 'HTML argument' so that for example I could include {0t} as an argument indicating that the 1st parameter should be HTML encoded.