On 10/03/2010, at 11:37 AM, Adrian Crum wrote: > Scott Gray wrote: >> On 10/03/2010, at 11:03 AM, Adam Heath wrote: >>> Scott Gray wrote: >>>> On 10/03/2010, at 10:35 AM, Adam Heath wrote: >>>> >>>>> Scott Gray wrote: >>>>>> On 10/03/2010, at 9:48 AM, Adam Heath wrote: >>>>>> >>>>>>> [email protected] wrote: >>>>>>>> Author: jleroux >>>>>>>> Date: Wed Mar 10 16:12:30 2010 >>>>>>>> New Revision: 921421 >>>>>>>> >>>>>>>> URL: http://svn.apache.org/viewvc?rev=921421&view=rev >>>>>>>> Log: >>>>>>>> You can't use double quote in tooltips. I tried to find a quick way to >>>>>>>> allow this in MacroFormRenderer.appendTooltip() but gave up, too >>>>>>>> narrow need. >>>>>>>> >>>>>>>> Modified: >>>>>>>> ofbiz/trunk/framework/example/config/ExampleUiLabels.xml >>>>>>>> >>>>>>>> Modified: ofbiz/trunk/framework/example/config/ExampleUiLabels.xml >>>>>>>> URL: >>>>>>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/config/ExampleUiLabels.xml?rev=921421&r1=921420&r2=921421&view=diff >>>>>>>> ============================================================================== >>>>>>>> --- ofbiz/trunk/framework/example/config/ExampleUiLabels.xml (original) >>>>>>>> +++ ofbiz/trunk/framework/example/config/ExampleUiLabels.xml Wed Mar >>>>>>>> 10 16:12:30 2010 >>>>>>>> @@ -97,7 +97,7 @@ >>>>>>>> </property> >>>>>>>> <property key="ExampleDateField10Tooltip"> >>>>>>>> <value xml:lang="en">Same as above, uses the nowTimestamp >>>>>>>> variable (always available in the form context) to set the default >>>>>>>> value to now</value> >>>>>>>> - <value xml:lang="fr">La même chose mais la variable >>>>>>>> nowTimestamp (toujours disponible dans context) est utilisée pour >>>>>>>> affecter la valeur par défaut à "maintenant"</value> >>>>>>>> + <value xml:lang="fr">La même chose mais la variable >>>>>>>> nowTimestamp (toujours disponible dans context) est utilisée pour >>>>>>>> affecter la valeur par défaut à 'maintenant'</value> >>>>>>>> <value xml:lang="it">Lo stesso di sopra, usare la variabile >>>>>>>> nowTimestamp (sempre disponibile nel contesto della form) per >>>>>>>> impostare il valore di default ad adesso</value> >>>>>>>> <value xml:lang="zh">åŒä¸Šï¼Œä½¿ç”¨nowTimstampå˜é‡(在表å•ä¸ >>>>>>>> 总是å¯ç”¨çš„)æ¥æŠŠç¼ºçœå€¼è®¾ç½®ä¸ºçŽ°åœ¨</value> >>>>>>>> </property> >>>>>>> tooltip.replaceAll("\"", """), also handling any other weird html >>>>>>> characters, like < or > or &. >>>>>> It would probably be easiest to just encode the tooltip string before >>>>>> generating the macro call. There are examples of that all over. >>>>>> tooltip = encode(tooltip, modelFormField, context); >>>>> That's what I mean, I went and looked at the method he referenced, to >>>>> know what the variable name was. >>>>> >>>>> I also looked at the macro files themselves, and they will work if >>>>> passed this encoded string value. >>>>> >>>>> However, from a perfectionist standpoint, it doesn't sit well with me. >>>>> What happens if these macros use a string from a map, that is already >>>>> encoded, then try to double-encode it? >>>> It shouldn't be encoded until it is about to be rendered, >>>> ModelFormField.getEntry(...) encodes early and it is a PITA. A late as >>>> possible encoding strategy is definitely the way to go. >>>> >>>>> Ideally, MacroFormRenderer is calling freemarker. So it should use >>>>> freemarker encodings of special characters. Freemarker should then >>>>> decode said special markup, so that the macros it ends up calling can >>>>> do what they need for it. >>>> Agreed, allowing freemarker to do the encoding would certainly be easier >>>> but until we get rid of ALL of the earlier encodings we'll end up with >>>> double encoding. Also any encoding that takes place outside of the >>>> renderer methods, like in ModelFormField, requires us to update all the >>>> other form renderers before we can remove them. >>> Finall output encoding is not the same as encoding when it leaves your >>> control. >>> >>> A -> B -> C -> D >>> >>> A needs to encode it's output to get around any issues that B has. >>> Then B needs decode it's input, and then encode it's output as it >>> passes to C. And so on, and so on. >>> >>> The real problem here is using strings to pass data around. It should >>> be passed as part of the context. >> You've lost me, IMO each renderer should be responsible for handling the >> encoding required of the output it's generating. >> Multiple encoding/decoding points just seems like it will add unnecessary >> complexity. > > Stronger data typing is much easier to use in the long run. The problem with > passing data around in Strings is you don't know what the String contains. Is > it plain text? HTML? XML? Encoded? Decoded?
All raw data being passed around should be plain text, encode it when you pass it out to the response. I still don't see the need for any complexity.
smime.p7s
Description: S/MIME cryptographic signature
