Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Locked
12
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
12
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
 
|
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
|
On 10/03/2010, at 9:48 AM, Adam Heath wrote:
> [hidden email] 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 &. tooltip = encode(tooltip, modelFormField, context); Regards Scott |
smime.p7s (3K)
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
|
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
|
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: >> >>> [hidden email] 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? > 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. Regards Scott |
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
|
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
|
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
Administrator
|
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
|
In reply to this post by Adam Heath-2
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: >>>> >>>>> [hidden email] 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. Multiple encoding/decoding points just seems like it will add unnecessary complexity. |
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
|
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
|
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
Administrator
|
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
|
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
|
In reply to this post by Adam Heath-2
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: >>>>>> >>>>>>> [hidden email] 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. > 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. |
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
|
In reply to this post by Adrian Crum
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: >>>>>> >>>>>>> [hidden email] 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? |
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
Administrator
|
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
Administrator
|
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
|
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
Administrator
|
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
|
In reply to this post by Adam Heath-2
On 10/03/2010, at 12:00 PM, Adam Heath wrote:
> Scott Gray wrote: >> 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: >>>>>>>> >>>>>>>>> [hidden email] 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. > > There-in lies the problem. > > The model exists as plain objects. But then MacroFormRender starts. > This is stage one. It has to encode for freemarker to be able to > parse it. > > Stage two is when freemarker runs, and finally outputs html. > > Stage one is encoding the parameters as strings. It needs to be able > to allow freemarker to parse it, while getting the actual real value. > Freemarker is xml-like, so xml encoding should be used. Of course, > not doing any encoding at all in stage one would be better. > > In stage two, freemarker will parse the raw text, converting it > internally to objects in the macro call. The final called macro has > to then encode it properly for the final output, maybe html, maybe > csv, maybe xml/pdf or something. From http://freemarker.sourceforge.net/docs/dgui_template_exp.html#dgui_template_exp_direct_string "If the text itself contains the character used for the quoting (either " or ') or backslashes, you have to precede them with a backslash; this is called escaping. You can type any other character, including line breaks, in the text directly." |
Re: svn commit: r921421 - /ofbiz/trunk/framework/example
|
|
| Free forum by Nabble | Edit this page |