On 10/03/2010, at 11:39 AM, Adam Heath 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. > > Each stage of the rendering pipline needs to allow it's caller to > encode things as input. Then, the stage has to decode these incoming > parameters for it's internal use, then encode them again for the next > stage.
Pipeline? What pipeline? We only have two things, a model and a renderer. The model should be concerned with encoding, it should deal with raw unencoded strings. The renderer should encode data just before it outputs it. > It's not just that each rendering stage has to encode for it's output. > But the incoming has to be encoded to pass whatever requirements are > nescessary for the stage. I still only consider there to be one stage: take the model and render it. The model doesn't have any output, it's a model. > If you are still having problems understanding what I am saying, then > ask, and I'll give a more concrete example. That would be great.
smime.p7s
Description: S/MIME cryptographic signature
