You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Andrew Zeneski <an...@hotwaxmedia.com> on 2009/04/23 07:32:08 UTC

  Codes

I think this is due to the new HTML security, but now we have these  
"&#160;" codes floating all over the place. I'm not sure what the best  
solution for this is, but I thought I would check in a change like this:

Index: config/CommonUiLabels.xml
===================================================================
--- config/CommonUiLabels.xml	(revision 767649)
+++ config/CommonUiLabels.xml	(working copy)
@@ -1997,7 +1997,7 @@
          <value xml:lang="zh_CN">电子邮件</value>
      </property>
      <property key="CommonEmptyHeader">
-        <value xml:lang="en">&amp;#160;</value>
+        <value xml:lang="en"> </value>
      </property>
      <property key="CommonEnabled">
          <value xml:lang="ar">شغال</value>

Any thoughts???


Andrew


Re:   Codes

Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks Adrian!

Jacques

From: "Adrian Crum" <ad...@yahoo.com>
>
> Okay, the Label Manager issue is fixed in revision 768123.
>
> -Adrian
>
> --- On Thu, 4/23/09, Adrian Crum <ad...@hlmksw.com> wrote:
>
>> From: Adrian Crum <ad...@hlmksw.com>
>> Subject: Re: &#160; Codes
>> To: dev@ofbiz.apache.org
>> Date: Thursday, April 23, 2009, 1:23 PM
>> In the XML property files, the text to be displayed is not
>> an element's attribute, it's the element's
>> value.
>>
>> I would work on this, but it seems the label manager is
>> broken. All I get is an error message.
>>
>> -Adrian
>>
>> David E Jones wrote:
>> >
>> > Yes, it should. I haven't looked into this enough
>> to know what the issue is with that... it could be that the
>> label parsing code is calling trim() or something on the
>> label text coming in so these get turned into an empty
>> String... and if so changing that might be the easiest/best
>> way to handle this for labels.
>> >
>> > For the widgets using a plain space (as opposed to an
>> empty String) is probably the best way to go. Someone was
>> just writing about how an empty attribute is the same as not
>> specifying the attribute at all, and that IS actually how
>> XML parsing is supposed to be (ie that's what the spec
>> says), ie on the Element.getAttribute() method it will never
>> return null (there is no distinction between null and an
>> empty String).
>> >
>> > -David
>> >
>> >
>> > On Apr 23, 2009, at 1:33 PM, Andrew Zeneski wrote:
>> >
>> >> Fair enough, then in this case this specific field
>> CommonEmptyHeader should be just a single space. The label
>> manager should define its own special label which is not
>> used anywhere else.
>> >>
>> >> Andrew
>> >>
>> >> On Apr 23, 2009, at 2:42 PM, David E Jones wrote:
>> >>
>> >>>
>> >>> Yes, one of the "guidelines" (or
>> maybe a better term is best practice) is to not have HTML in
>> translation labels. There are a few reasons for this that
>> have come up over time:
>> >>>
>> >>> 1. ability to use labels in non-webapp
>> contexts
>> >>> 2. be able to externally format/style the
>> labels, perhaps differently in different places
>> >>> 3. avoid HTML in labels interfering with other
>> HTML/CSS in the page
>> >>>
>> >>> Anyway, there was an effort a while back to
>> remove HTML from the labels for some of these reasons, and
>> when doing the output encoding it seemed best to encode all
>> characters from labels to encourage this practice.
>> >>>
>> >>> -David
>> >>>
>> >>>
>> >>> On Apr 23, 2009, at 12:28 PM, Adrian Crum
>> wrote:
>> >>>
>> >>>> Why would we want to put HTML in the UI
>> labels?
>> >>>>
>> >>>> -Adrian
>> >>>>
>> >>>> Andrew Zeneski wrote:
>> >>>>> Here is a patch which does exactly
>> this, and appears to work with just a little testing.
>> I'm just not sure of the total impact it will cause.
>> >>>>> On Apr 23, 2009, at 1:44 PM, Andrew
>> Zeneski wrote:
>> >>>>>> Well there is an option which
>> might be viable. We could simply wrap all values in the
>> uiLabelMap using StringUtil.wrapString(). This will allow
>> HTML characters in the UI labels again and shouldn't be
>> too much of a security risk, as only developers have access
>> to these strings.
>> >>>>>>
>> >>>>>> Thoughts?
>> >>>>>>
>> >>>>>> Andrew
>> >>>>>>
>> >>>>>> On Apr 23, 2009, at 10:56 AM,
>> Adrian Crum wrote:
>> >>>>>>
>> >>>>>>> I agree. We should look into
>> the widget code and the label manager code to get these
>> issues fixed properly.
>> >>>>>>>
>> >>>>>>> -Adrian
>> >>>>>>>
>> >>>>>>> Scott Gray wrote:
>> >>>>>>>> That's probably
>> something we can fix in the widget code isn't it?  If
>> the title attribute is missing then use the field name
>> otherwise render whatever is specified in the title even if
>> it is just an empty string.
>> >>>>>>>> Regards
>> >>>>>>>> Scott
>> >>>>>>>> HotWax Media
>> >>>>>>>> http://www.hotwaxmedia.com
>> <http://www.hotwaxmedia.com/>
>> >>>>>>>> On 23/04/2009, at 8:53 PM,
>> Jacopo Cappellato wrote:
>> >>>>>>>>> I think it is related
>> to the situation where you want to specify an empty content
>> for the "title" attribute in form widgets. if
>> title element is missing or is set to title=""
>> then the widgets render it with the name of the field or
>> simialr.
>> >>>>>>>>>
>> >>>>>>>>> Jacopo
>> >>>>>>>>>
>> >>>>>>>>> On Apr 23, 2009, at
>> 10:43 AM, Scott Gray wrote:
>> >>>>>>>>>
>> >>>>>>>>>> I can't
>> remember the reason for adding the CommonEmptyHeader label
>> but I'm wondering if we should consider removing it and
>> find another solution to whatever problem it solved?
>> >>>>>>>>>>
>> >>>>>>>>>> Regards
>> >>>>>>>>>> Scott
>> >>>>>>>>>>
>> >>>>>>>>>> HotWax Media
>> >>>>>>>>>>
>> http://www.hotwaxmedia.com
>> >>>>>>>>>>
>> >>>>>>>>>> On 23/04/2009, at
>> 8:25 PM, Jacques Le Roux wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> Hi Andrew,
>> >>>>>>>>>>>
>> >>>>>>>>>>> From:
>> "Andrew Zeneski"
>> <andrew.zeneski@hotwaxmedia.com
>> <ma...@hotwaxmedia.com>>
>> >>>>>>>>>>>> I think
>> this is due to the new HTML security, but now we have these
>> "&#160;" codes floating all over the place.
>> I'm not sure what the best  solution for this is, but I
>> thought I would check in a change like this:
>> >>>>>>>>>>>
>> >>>>>>>>>>> This is not as
>> simple. I agree it's a quick fix for the issue at hand.
>> But this is due to Labels Manager. If you put a sole space
>> (ie > < ) then if you do some modifications with
>> Labels Manager in this file and then save in the file you
>> will get
>> >>>>>>>>>>> <property
>> key="CommonEmptyHeader">
>> >>>>>>>>>>> <value
>> xml:lang="en"/>
>> >>>>>>>>>>>
>> </property>
>> >>>>>>>>>>>
>> >>>>>>>>>>> In order to
>> cope with this I tried to write directly at
>> SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String
>> "&#160;" which should be ok. But I guess I
>> would have to change the format passed to
>> UtilXml.writeXmlDocument some lines below since else it
>> write "&amp;#160;" and not
>> "&#160;" as intended. Not sure it's
>> possible though. And I have no time to look at it right now.
>> >>>>>>>>>>>
>> >>>>>>>>>>> So I made the
>> change you proposed at r767845  and  r767848  for R9.04
>> >>>>>>>>>>> And we will
>> have to deal with that in a complete way since else we will
>> find an even worst trouble later (as soon someone will use
>> Labels Manager to save changes in this file)
>> >>>>>>>>>>>
>> >>>>>>>>>>> Jacques
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> I had some
>> zele here (ok not only here ;o)
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Index:
>> config/CommonUiLabels.xml
>> >>>>>>>>>>>>
>> ===================================================================
>>
>> >>>>>>>>>>>> ---
>> config/CommonUiLabels.xml (revision 767649)
>> >>>>>>>>>>>> +++
>> config/CommonUiLabels.xml (working copy)
>> >>>>>>>>>>>> @@ -1997,7
>> +1997,7 @@
>> >>>>>>>>>>>>
>> <value
>> xml:lang="zh_CN">电子邮件</value>
>> >>>>>>>>>>>>
>> </property>
>> >>>>>>>>>>>>
>> <property key="CommonEmptyHeader">
>> >>>>>>>>>>>> -
>> <value
>> xml:lang="en">&amp;#160;</value>
>> >>>>>>>>>>>> +
>> <value xml:lang="en"> </value>
>> >>>>>>>>>>>>
>> </property>
>> >>>>>>>>>>>>
>> <property key="CommonEnabled">
>> >>>>>>>>>>>>
>> <value xml:lang="ar">شغال</value>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Any
>> thoughts???
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Andrew
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>
>> >>>
>> >>
>> >
>> >
>
>
>
> 



Re:   Codes

Posted by Adrian Crum <ad...@yahoo.com>.
Okay, the Label Manager issue is fixed in revision 768123.

-Adrian

--- On Thu, 4/23/09, Adrian Crum <ad...@hlmksw.com> wrote:

> From: Adrian Crum <ad...@hlmksw.com>
> Subject: Re: &#160; Codes
> To: dev@ofbiz.apache.org
> Date: Thursday, April 23, 2009, 1:23 PM
> In the XML property files, the text to be displayed is not
> an element's attribute, it's the element's
> value.
> 
> I would work on this, but it seems the label manager is
> broken. All I get is an error message.
> 
> -Adrian
> 
> David E Jones wrote:
> > 
> > Yes, it should. I haven't looked into this enough
> to know what the issue is with that... it could be that the
> label parsing code is calling trim() or something on the
> label text coming in so these get turned into an empty
> String... and if so changing that might be the easiest/best
> way to handle this for labels.
> > 
> > For the widgets using a plain space (as opposed to an
> empty String) is probably the best way to go. Someone was
> just writing about how an empty attribute is the same as not
> specifying the attribute at all, and that IS actually how
> XML parsing is supposed to be (ie that's what the spec
> says), ie on the Element.getAttribute() method it will never
> return null (there is no distinction between null and an
> empty String).
> > 
> > -David
> > 
> > 
> > On Apr 23, 2009, at 1:33 PM, Andrew Zeneski wrote:
> > 
> >> Fair enough, then in this case this specific field
> CommonEmptyHeader should be just a single space. The label
> manager should define its own special label which is not
> used anywhere else.
> >> 
> >> Andrew
> >> 
> >> On Apr 23, 2009, at 2:42 PM, David E Jones wrote:
> >> 
> >>> 
> >>> Yes, one of the "guidelines" (or
> maybe a better term is best practice) is to not have HTML in
> translation labels. There are a few reasons for this that
> have come up over time:
> >>> 
> >>> 1. ability to use labels in non-webapp
> contexts
> >>> 2. be able to externally format/style the
> labels, perhaps differently in different places
> >>> 3. avoid HTML in labels interfering with other
> HTML/CSS in the page
> >>> 
> >>> Anyway, there was an effort a while back to
> remove HTML from the labels for some of these reasons, and
> when doing the output encoding it seemed best to encode all
> characters from labels to encourage this practice.
> >>> 
> >>> -David
> >>> 
> >>> 
> >>> On Apr 23, 2009, at 12:28 PM, Adrian Crum
> wrote:
> >>> 
> >>>> Why would we want to put HTML in the UI
> labels?
> >>>> 
> >>>> -Adrian
> >>>> 
> >>>> Andrew Zeneski wrote:
> >>>>> Here is a patch which does exactly
> this, and appears to work with just a little testing.
> I'm just not sure of the total impact it will cause.
> >>>>> On Apr 23, 2009, at 1:44 PM, Andrew
> Zeneski wrote:
> >>>>>> Well there is an option which
> might be viable. We could simply wrap all values in the
> uiLabelMap using StringUtil.wrapString(). This will allow
> HTML characters in the UI labels again and shouldn't be
> too much of a security risk, as only developers have access
> to these strings.
> >>>>>> 
> >>>>>> Thoughts?
> >>>>>> 
> >>>>>> Andrew
> >>>>>> 
> >>>>>> On Apr 23, 2009, at 10:56 AM,
> Adrian Crum wrote:
> >>>>>> 
> >>>>>>> I agree. We should look into
> the widget code and the label manager code to get these
> issues fixed properly.
> >>>>>>> 
> >>>>>>> -Adrian
> >>>>>>> 
> >>>>>>> Scott Gray wrote:
> >>>>>>>> That's probably
> something we can fix in the widget code isn't it?  If
> the title attribute is missing then use the field name
> otherwise render whatever is specified in the title even if
> it is just an empty string.
> >>>>>>>> Regards
> >>>>>>>> Scott
> >>>>>>>> HotWax Media
> >>>>>>>> http://www.hotwaxmedia.com
> <http://www.hotwaxmedia.com/>
> >>>>>>>> On 23/04/2009, at 8:53 PM,
> Jacopo Cappellato wrote:
> >>>>>>>>> I think it is related
> to the situation where you want to specify an empty content
> for the "title" attribute in form widgets. if
> title element is missing or is set to title=""
> then the widgets render it with the name of the field or
> simialr.
> >>>>>>>>> 
> >>>>>>>>> Jacopo
> >>>>>>>>> 
> >>>>>>>>> On Apr 23, 2009, at
> 10:43 AM, Scott Gray wrote:
> >>>>>>>>> 
> >>>>>>>>>> I can't
> remember the reason for adding the CommonEmptyHeader label
> but I'm wondering if we should consider removing it and
> find another solution to whatever problem it solved?
> >>>>>>>>>> 
> >>>>>>>>>> Regards
> >>>>>>>>>> Scott
> >>>>>>>>>> 
> >>>>>>>>>> HotWax Media
> >>>>>>>>>>
> http://www.hotwaxmedia.com
> >>>>>>>>>> 
> >>>>>>>>>> On 23/04/2009, at
> 8:25 PM, Jacques Le Roux wrote:
> >>>>>>>>>> 
> >>>>>>>>>>> Hi Andrew,
> >>>>>>>>>>> 
> >>>>>>>>>>> From:
> "Andrew Zeneski"
> <andrew.zeneski@hotwaxmedia.com
> <ma...@hotwaxmedia.com>>
> >>>>>>>>>>>> I think
> this is due to the new HTML security, but now we have these 
> "&#160;" codes floating all over the place.
> I'm not sure what the best  solution for this is, but I
> thought I would check in a change like this:
> >>>>>>>>>>> 
> >>>>>>>>>>> This is not as
> simple. I agree it's a quick fix for the issue at hand.
> But this is due to Labels Manager. If you put a sole space
> (ie > < ) then if you do some modifications with
> Labels Manager in this file and then save in the file you
> will get
> >>>>>>>>>>> <property
> key="CommonEmptyHeader">
> >>>>>>>>>>> <value
> xml:lang="en"/>
> >>>>>>>>>>>
> </property>
> >>>>>>>>>>> 
> >>>>>>>>>>> In order to
> cope with this I tried to write directly at
> SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String
> "&#160;" which should be ok. But I guess I
> would have to change the format passed to
> UtilXml.writeXmlDocument some lines below since else it
> write "&amp;#160;" and not
> "&#160;" as intended. Not sure it's
> possible though. And I have no time to look at it right now.
> >>>>>>>>>>> 
> >>>>>>>>>>> So I made the
> change you proposed at r767845  and  r767848  for R9.04
> >>>>>>>>>>> And we will
> have to deal with that in a complete way since else we will
> find an even worst trouble later (as soon someone will use
> Labels Manager to save changes in this file)
> >>>>>>>>>>> 
> >>>>>>>>>>> Jacques
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> I had some
> zele here (ok not only here ;o)
> >>>>>>>>>>> 
> >>>>>>>>>>>> Index:
> config/CommonUiLabels.xml
> >>>>>>>>>>>>
> ===================================================================
> 
> >>>>>>>>>>>> ---
> config/CommonUiLabels.xml (revision 767649)
> >>>>>>>>>>>> +++
> config/CommonUiLabels.xml (working copy)
> >>>>>>>>>>>> @@ -1997,7
> +1997,7 @@
> >>>>>>>>>>>>  
> <value
> xml:lang="zh_CN">电子邮件</value>
> >>>>>>>>>>>>
> </property>
> >>>>>>>>>>>>
> <property key="CommonEmptyHeader">
> >>>>>>>>>>>> -       
> <value
> xml:lang="en">&amp;#160;</value>
> >>>>>>>>>>>> +       
> <value xml:lang="en"> </value>
> >>>>>>>>>>>>
> </property>
> >>>>>>>>>>>>
> <property key="CommonEnabled">
> >>>>>>>>>>>>  
> <value xml:lang="ar">شغال</value>
> >>>>>>>>>>>> 
> >>>>>>>>>>>> Any
> thoughts???
> >>>>>>>>>>>> 
> >>>>>>>>>>>> 
> >>>>>>>>>>>> Andrew
> >>>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>> 
> >>>>>> 
> >>> 
> >> 
> > 
> >


      

Re:   Codes

Posted by Adrian Crum <ad...@hlmksw.com>.
In the XML property files, the text to be displayed is not an element's 
attribute, it's the element's value.

I would work on this, but it seems the label manager is broken. All I 
get is an error message.

-Adrian

David E Jones wrote:
> 
> Yes, it should. I haven't looked into this enough to know what the issue 
> is with that... it could be that the label parsing code is calling 
> trim() or something on the label text coming in so these get turned into 
> an empty String... and if so changing that might be the easiest/best way 
> to handle this for labels.
> 
> For the widgets using a plain space (as opposed to an empty String) is 
> probably the best way to go. Someone was just writing about how an empty 
> attribute is the same as not specifying the attribute at all, and that 
> IS actually how XML parsing is supposed to be (ie that's what the spec 
> says), ie on the Element.getAttribute() method it will never return null 
> (there is no distinction between null and an empty String).
> 
> -David
> 
> 
> On Apr 23, 2009, at 1:33 PM, Andrew Zeneski wrote:
> 
>> Fair enough, then in this case this specific field CommonEmptyHeader 
>> should be just a single space. The label manager should define its own 
>> special label which is not used anywhere else.
>>
>> Andrew
>>
>> On Apr 23, 2009, at 2:42 PM, David E Jones wrote:
>>
>>>
>>> Yes, one of the "guidelines" (or maybe a better term is best 
>>> practice) is to not have HTML in translation labels. There are a few 
>>> reasons for this that have come up over time:
>>>
>>> 1. ability to use labels in non-webapp contexts
>>> 2. be able to externally format/style the labels, perhaps differently 
>>> in different places
>>> 3. avoid HTML in labels interfering with other HTML/CSS in the page
>>>
>>> Anyway, there was an effort a while back to remove HTML from the 
>>> labels for some of these reasons, and when doing the output encoding 
>>> it seemed best to encode all characters from labels to encourage this 
>>> practice.
>>>
>>> -David
>>>
>>>
>>> On Apr 23, 2009, at 12:28 PM, Adrian Crum wrote:
>>>
>>>> Why would we want to put HTML in the UI labels?
>>>>
>>>> -Adrian
>>>>
>>>> Andrew Zeneski wrote:
>>>>> Here is a patch which does exactly this, and appears to work with 
>>>>> just a little testing. I'm just not sure of the total impact it 
>>>>> will cause.
>>>>> On Apr 23, 2009, at 1:44 PM, Andrew Zeneski wrote:
>>>>>> Well there is an option which might be viable. We could simply 
>>>>>> wrap all values in the uiLabelMap using StringUtil.wrapString(). 
>>>>>> This will allow HTML characters in the UI labels again and 
>>>>>> shouldn't be too much of a security risk, as only developers have 
>>>>>> access to these strings.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>>> On Apr 23, 2009, at 10:56 AM, Adrian Crum wrote:
>>>>>>
>>>>>>> I agree. We should look into the widget code and the label 
>>>>>>> manager code to get these issues fixed properly.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> Scott Gray wrote:
>>>>>>>> That's probably something we can fix in the widget code isn't 
>>>>>>>> it?  If the title attribute is missing then use the field name 
>>>>>>>> otherwise render whatever is specified in the title even if it 
>>>>>>>> is just an empty string.
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>> HotWax Media
>>>>>>>> http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/>
>>>>>>>> On 23/04/2009, at 8:53 PM, Jacopo Cappellato wrote:
>>>>>>>>> I think it is related to the situation where you want to 
>>>>>>>>> specify an empty content for the "title" attribute in form 
>>>>>>>>> widgets. if title element is missing or is set to title="" then 
>>>>>>>>> the widgets render it with the name of the field or simialr.
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> On Apr 23, 2009, at 10:43 AM, Scott Gray wrote:
>>>>>>>>>
>>>>>>>>>> I can't remember the reason for adding the CommonEmptyHeader 
>>>>>>>>>> label but I'm wondering if we should consider removing it and 
>>>>>>>>>> find another solution to whatever problem it solved?
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Scott
>>>>>>>>>>
>>>>>>>>>> HotWax Media
>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>
>>>>>>>>>> On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Andrew,
>>>>>>>>>>>
>>>>>>>>>>> From: "Andrew Zeneski" <andrew.zeneski@hotwaxmedia.com 
>>>>>>>>>>> <ma...@hotwaxmedia.com>>
>>>>>>>>>>>> I think this is due to the new HTML security, but now we 
>>>>>>>>>>>> have these  "&#160;" codes floating all over the place. I'm 
>>>>>>>>>>>> not sure what the best  solution for this is, but I thought 
>>>>>>>>>>>> I would check in a change like this:
>>>>>>>>>>>
>>>>>>>>>>> This is not as simple. I agree it's a quick fix for the issue 
>>>>>>>>>>> at hand. But this is due to Labels Manager. If you put a sole 
>>>>>>>>>>> space (ie > < ) then if you do some modifications with Labels 
>>>>>>>>>>> Manager in this file and then save in the file you will get
>>>>>>>>>>> <property key="CommonEmptyHeader">
>>>>>>>>>>> <value xml:lang="en"/>
>>>>>>>>>>> </property>
>>>>>>>>>>>
>>>>>>>>>>> In order to cope with this I tried to write directly at 
>>>>>>>>>>> SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String 
>>>>>>>>>>> "&#160;" which should be ok. But I guess I would have to 
>>>>>>>>>>> change the format passed to UtilXml.writeXmlDocument some 
>>>>>>>>>>> lines below since else it write "&amp;#160;" and not "&#160;" 
>>>>>>>>>>> as intended. Not sure it's possible though. And I have no 
>>>>>>>>>>> time to look at it right now.
>>>>>>>>>>>
>>>>>>>>>>> So I made the change you proposed at r767845  and  r767848  
>>>>>>>>>>> for R9.04
>>>>>>>>>>> And we will have to deal with that in a complete way since 
>>>>>>>>>>> else we will find an even worst trouble later (as soon 
>>>>>>>>>>> someone will use Labels Manager to save changes in this file)
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I had some zele here (ok not only here ;o)
>>>>>>>>>>>
>>>>>>>>>>>> Index: config/CommonUiLabels.xml
>>>>>>>>>>>> =================================================================== 
>>>>>>>>>>>>
>>>>>>>>>>>> --- config/CommonUiLabels.xml (revision 767649)
>>>>>>>>>>>> +++ config/CommonUiLabels.xml (working copy)
>>>>>>>>>>>> @@ -1997,7 +1997,7 @@
>>>>>>>>>>>>   <value xml:lang="zh_CN">电子邮件</value>
>>>>>>>>>>>> </property>
>>>>>>>>>>>> <property key="CommonEmptyHeader">
>>>>>>>>>>>> -        <value xml:lang="en">&amp;#160;</value>
>>>>>>>>>>>> +        <value xml:lang="en"> </value>
>>>>>>>>>>>> </property>
>>>>>>>>>>>> <property key="CommonEnabled">
>>>>>>>>>>>>   <value xml:lang="ar">شغال</value>
>>>>>>>>>>>>
>>>>>>>>>>>> Any thoughts???
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Andrew
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>
>>
> 
> 

Re:   Codes

Posted by David E Jones <da...@hotwaxmedia.com>.
Yes, it should. I haven't looked into this enough to know what the  
issue is with that... it could be that the label parsing code is  
calling trim() or something on the label text coming in so these get  
turned into an empty String... and if so changing that might be the  
easiest/best way to handle this for labels.

For the widgets using a plain space (as opposed to an empty String) is  
probably the best way to go. Someone was just writing about how an  
empty attribute is the same as not specifying the attribute at all,  
and that IS actually how XML parsing is supposed to be (ie that's what  
the spec says), ie on the Element.getAttribute() method it will never  
return null (there is no distinction between null and an empty String).

-David


On Apr 23, 2009, at 1:33 PM, Andrew Zeneski wrote:

> Fair enough, then in this case this specific field CommonEmptyHeader  
> should be just a single space. The label manager should define its  
> own special label which is not used anywhere else.
>
> Andrew
>
> On Apr 23, 2009, at 2:42 PM, David E Jones wrote:
>
>>
>> Yes, one of the "guidelines" (or maybe a better term is best  
>> practice) is to not have HTML in translation labels. There are a  
>> few reasons for this that have come up over time:
>>
>> 1. ability to use labels in non-webapp contexts
>> 2. be able to externally format/style the labels, perhaps  
>> differently in different places
>> 3. avoid HTML in labels interfering with other HTML/CSS in the page
>>
>> Anyway, there was an effort a while back to remove HTML from the  
>> labels for some of these reasons, and when doing the output  
>> encoding it seemed best to encode all characters from labels to  
>> encourage this practice.
>>
>> -David
>>
>>
>> On Apr 23, 2009, at 12:28 PM, Adrian Crum wrote:
>>
>>> Why would we want to put HTML in the UI labels?
>>>
>>> -Adrian
>>>
>>> Andrew Zeneski wrote:
>>>> Here is a patch which does exactly this, and appears to work with  
>>>> just a little testing. I'm just not sure of the total impact it  
>>>> will cause.
>>>> On Apr 23, 2009, at 1:44 PM, Andrew Zeneski wrote:
>>>>> Well there is an option which might be viable. We could simply  
>>>>> wrap all values in the uiLabelMap using StringUtil.wrapString().  
>>>>> This will allow HTML characters in the UI labels again and  
>>>>> shouldn't be too much of a security risk, as only developers  
>>>>> have access to these strings.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Andrew
>>>>>
>>>>> On Apr 23, 2009, at 10:56 AM, Adrian Crum wrote:
>>>>>
>>>>>> I agree. We should look into the widget code and the label  
>>>>>> manager code to get these issues fixed properly.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> Scott Gray wrote:
>>>>>>> That's probably something we can fix in the widget code isn't  
>>>>>>> it?  If the title attribute is missing then use the field name  
>>>>>>> otherwise render whatever is specified in the title even if it  
>>>>>>> is just an empty string.
>>>>>>> Regards
>>>>>>> Scott
>>>>>>> HotWax Media
>>>>>>> http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/>
>>>>>>> On 23/04/2009, at 8:53 PM, Jacopo Cappellato wrote:
>>>>>>>> I think it is related to the situation where you want to  
>>>>>>>> specify an empty content for the "title" attribute in form  
>>>>>>>> widgets. if title element is missing or is set to title=""  
>>>>>>>> then the widgets render it with the name of the field or  
>>>>>>>> simialr.
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>> On Apr 23, 2009, at 10:43 AM, Scott Gray wrote:
>>>>>>>>
>>>>>>>>> I can't remember the reason for adding the CommonEmptyHeader  
>>>>>>>>> label but I'm wondering if we should consider removing it  
>>>>>>>>> and find another solution to whatever problem it solved?
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>> HotWax Media
>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>
>>>>>>>>> On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote:
>>>>>>>>>
>>>>>>>>>> Hi Andrew,
>>>>>>>>>>
>>>>>>>>>> From: "Andrew Zeneski" <andrew.zeneski@hotwaxmedia.com <mailto:andrew.zeneski@hotwaxmedia.com 
>>>>>>>>>> >>
>>>>>>>>>>> I think this is due to the new HTML security, but now we  
>>>>>>>>>>> have these  "&#160;" codes floating all over the place.  
>>>>>>>>>>> I'm not sure what the best  solution for this is, but I  
>>>>>>>>>>> thought I would check in a change like this:
>>>>>>>>>>
>>>>>>>>>> This is not as simple. I agree it's a quick fix for the  
>>>>>>>>>> issue at hand. But this is due to Labels Manager. If you  
>>>>>>>>>> put a sole space (ie > < ) then if you do some  
>>>>>>>>>> modifications with Labels Manager in this file and then  
>>>>>>>>>> save in the file you will get
>>>>>>>>>> <property key="CommonEmptyHeader">
>>>>>>>>>> <value xml:lang="en"/>
>>>>>>>>>> </property>
>>>>>>>>>>
>>>>>>>>>> In order to cope with this I tried to write directly at  
>>>>>>>>>> SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String  
>>>>>>>>>> "&#160;" which should be ok. But I guess I would have to  
>>>>>>>>>> change the format passed to UtilXml.writeXmlDocument some  
>>>>>>>>>> lines below since else it write "&amp;#160;" and not  
>>>>>>>>>> "&#160;" as intended. Not sure it's possible though. And I  
>>>>>>>>>> have no time to look at it right now.
>>>>>>>>>>
>>>>>>>>>> So I made the change you proposed at r767845  and  r767848   
>>>>>>>>>> for R9.04
>>>>>>>>>> And we will have to deal with that in a complete way since  
>>>>>>>>>> else we will find an even worst trouble later (as soon  
>>>>>>>>>> someone will use Labels Manager to save changes in this file)
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I had some zele here (ok not only here ;o)
>>>>>>>>>>
>>>>>>>>>>> Index: config/CommonUiLabels.xml
>>>>>>>>>>> = 
>>>>>>>>>>> = 
>>>>>>>>>>> = 
>>>>>>>>>>> = 
>>>>>>>>>>> = 
>>>>>>>>>>> = 
>>>>>>>>>>> = 
>>>>>>>>>>> ============================================================
>>>>>>>>>>> --- config/CommonUiLabels.xml (revision 767649)
>>>>>>>>>>> +++ config/CommonUiLabels.xml (working copy)
>>>>>>>>>>> @@ -1997,7 +1997,7 @@
>>>>>>>>>>>   <value xml:lang="zh_CN">电子邮件</value>
>>>>>>>>>>> </property>
>>>>>>>>>>> <property key="CommonEmptyHeader">
>>>>>>>>>>> -        <value xml:lang="en">&amp;#160;</value>
>>>>>>>>>>> +        <value xml:lang="en"> </value>
>>>>>>>>>>> </property>
>>>>>>>>>>> <property key="CommonEnabled">
>>>>>>>>>>>   <value xml:lang="ar">شغال</value>
>>>>>>>>>>>
>>>>>>>>>>> Any thoughts???
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Andrew
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>
>>
>


Re:   Codes

Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
Fair enough, then in this case this specific field CommonEmptyHeader  
should be just a single space. The label manager should define its own  
special label which is not used anywhere else.

Andrew

On Apr 23, 2009, at 2:42 PM, David E Jones wrote:

>
> Yes, one of the "guidelines" (or maybe a better term is best  
> practice) is to not have HTML in translation labels. There are a few  
> reasons for this that have come up over time:
>
> 1. ability to use labels in non-webapp contexts
> 2. be able to externally format/style the labels, perhaps  
> differently in different places
> 3. avoid HTML in labels interfering with other HTML/CSS in the page
>
> Anyway, there was an effort a while back to remove HTML from the  
> labels for some of these reasons, and when doing the output encoding  
> it seemed best to encode all characters from labels to encourage  
> this practice.
>
> -David
>
>
> On Apr 23, 2009, at 12:28 PM, Adrian Crum wrote:
>
>> Why would we want to put HTML in the UI labels?
>>
>> -Adrian
>>
>> Andrew Zeneski wrote:
>>> Here is a patch which does exactly this, and appears to work with  
>>> just a little testing. I'm just not sure of the total impact it  
>>> will cause.
>>> On Apr 23, 2009, at 1:44 PM, Andrew Zeneski wrote:
>>>> Well there is an option which might be viable. We could simply  
>>>> wrap all values in the uiLabelMap using StringUtil.wrapString().  
>>>> This will allow HTML characters in the UI labels again and  
>>>> shouldn't be too much of a security risk, as only developers have  
>>>> access to these strings.
>>>>
>>>> Thoughts?
>>>>
>>>> Andrew
>>>>
>>>> On Apr 23, 2009, at 10:56 AM, Adrian Crum wrote:
>>>>
>>>>> I agree. We should look into the widget code and the label  
>>>>> manager code to get these issues fixed properly.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> Scott Gray wrote:
>>>>>> That's probably something we can fix in the widget code isn't  
>>>>>> it?  If the title attribute is missing then use the field name  
>>>>>> otherwise render whatever is specified in the title even if it  
>>>>>> is just an empty string.
>>>>>> Regards
>>>>>> Scott
>>>>>> HotWax Media
>>>>>> http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/>
>>>>>> On 23/04/2009, at 8:53 PM, Jacopo Cappellato wrote:
>>>>>>> I think it is related to the situation where you want to  
>>>>>>> specify an empty content for the "title" attribute in form  
>>>>>>> widgets. if title element is missing or is set to title=""  
>>>>>>> then the widgets render it with the name of the field or  
>>>>>>> simialr.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> On Apr 23, 2009, at 10:43 AM, Scott Gray wrote:
>>>>>>>
>>>>>>>> I can't remember the reason for adding the CommonEmptyHeader  
>>>>>>>> label but I'm wondering if we should consider removing it and  
>>>>>>>> find another solution to whatever problem it solved?
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> HotWax Media
>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>
>>>>>>>> On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote:
>>>>>>>>
>>>>>>>>> Hi Andrew,
>>>>>>>>>
>>>>>>>>> From: "Andrew Zeneski" <andrew.zeneski@hotwaxmedia.com <mailto:andrew.zeneski@hotwaxmedia.com 
>>>>>>>>> >>
>>>>>>>>>> I think this is due to the new HTML security, but now we  
>>>>>>>>>> have these  "&#160;" codes floating all over the place. I'm  
>>>>>>>>>> not sure what the best  solution for this is, but I thought  
>>>>>>>>>> I would check in a change like this:
>>>>>>>>>
>>>>>>>>> This is not as simple. I agree it's a quick fix for the  
>>>>>>>>> issue at hand. But this is due to Labels Manager. If you put  
>>>>>>>>> a sole space (ie > < ) then if you do some modifications  
>>>>>>>>> with Labels Manager in this file and then save in the file  
>>>>>>>>> you will get
>>>>>>>>> <property key="CommonEmptyHeader">
>>>>>>>>>  <value xml:lang="en"/>
>>>>>>>>> </property>
>>>>>>>>>
>>>>>>>>> In order to cope with this I tried to write directly at  
>>>>>>>>> SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String  
>>>>>>>>> "&#160;" which should be ok. But I guess I would have to  
>>>>>>>>> change the format passed to UtilXml.writeXmlDocument some  
>>>>>>>>> lines below since else it write "&amp;#160;" and not  
>>>>>>>>> "&#160;" as intended. Not sure it's possible though. And I  
>>>>>>>>> have no time to look at it right now.
>>>>>>>>>
>>>>>>>>> So I made the change you proposed at r767845  and  r767848   
>>>>>>>>> for R9.04
>>>>>>>>> And we will have to deal with that in a complete way since  
>>>>>>>>> else we will find an even worst trouble later (as soon  
>>>>>>>>> someone will use Labels Manager to save changes in this file)
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I had some zele here (ok not only here ;o)
>>>>>>>>>
>>>>>>>>>> Index: config/CommonUiLabels.xml
>>>>>>>>>> = 
>>>>>>>>>> = 
>>>>>>>>>> = 
>>>>>>>>>> = 
>>>>>>>>>> = 
>>>>>>>>>> = 
>>>>>>>>>> =============================================================
>>>>>>>>>> --- config/CommonUiLabels.xml (revision 767649)
>>>>>>>>>> +++ config/CommonUiLabels.xml (working copy)
>>>>>>>>>> @@ -1997,7 +1997,7 @@
>>>>>>>>>>    <value xml:lang="zh_CN">电子邮件</value>
>>>>>>>>>> </property>
>>>>>>>>>> <property key="CommonEmptyHeader">
>>>>>>>>>> -        <value xml:lang="en">&amp;#160;</value>
>>>>>>>>>> +        <value xml:lang="en"> </value>
>>>>>>>>>> </property>
>>>>>>>>>> <property key="CommonEnabled">
>>>>>>>>>>    <value xml:lang="ar">شغال</value>
>>>>>>>>>>
>>>>>>>>>> Any thoughts???
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Andrew
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>


Re:   Codes

Posted by David E Jones <da...@hotwaxmedia.com>.
Yes, one of the "guidelines" (or maybe a better term is best practice)  
is to not have HTML in translation labels. There are a few reasons for  
this that have come up over time:

1. ability to use labels in non-webapp contexts
2. be able to externally format/style the labels, perhaps differently  
in different places
3. avoid HTML in labels interfering with other HTML/CSS in the page

Anyway, there was an effort a while back to remove HTML from the  
labels for some of these reasons, and when doing the output encoding  
it seemed best to encode all characters from labels to encourage this  
practice.

-David


On Apr 23, 2009, at 12:28 PM, Adrian Crum wrote:

> Why would we want to put HTML in the UI labels?
>
> -Adrian
>
> Andrew Zeneski wrote:
>> Here is a patch which does exactly this, and appears to work with  
>> just a little testing. I'm just not sure of the total impact it  
>> will cause.
>> On Apr 23, 2009, at 1:44 PM, Andrew Zeneski wrote:
>>> Well there is an option which might be viable. We could simply  
>>> wrap all values in the uiLabelMap using StringUtil.wrapString().  
>>> This will allow HTML characters in the UI labels again and  
>>> shouldn't be too much of a security risk, as only developers have  
>>> access to these strings.
>>>
>>> Thoughts?
>>>
>>> Andrew
>>>
>>> On Apr 23, 2009, at 10:56 AM, Adrian Crum wrote:
>>>
>>>> I agree. We should look into the widget code and the label  
>>>> manager code to get these issues fixed properly.
>>>>
>>>> -Adrian
>>>>
>>>> Scott Gray wrote:
>>>>> That's probably something we can fix in the widget code isn't  
>>>>> it?  If the title attribute is missing then use the field name  
>>>>> otherwise render whatever is specified in the title even if it  
>>>>> is just an empty string.
>>>>> Regards
>>>>> Scott
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/>
>>>>> On 23/04/2009, at 8:53 PM, Jacopo Cappellato wrote:
>>>>>> I think it is related to the situation where you want to  
>>>>>> specify an empty content for the "title" attribute in form  
>>>>>> widgets. if title element is missing or is set to title="" then  
>>>>>> the widgets render it with the name of the field or simialr.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Apr 23, 2009, at 10:43 AM, Scott Gray wrote:
>>>>>>
>>>>>>> I can't remember the reason for adding the CommonEmptyHeader  
>>>>>>> label but I'm wondering if we should consider removing it and  
>>>>>>> find another solution to whatever problem it solved?
>>>>>>>
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>> HotWax Media
>>>>>>> http://www.hotwaxmedia.com
>>>>>>>
>>>>>>> On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote:
>>>>>>>
>>>>>>>> Hi Andrew,
>>>>>>>>
>>>>>>>> From: "Andrew Zeneski" <andrew.zeneski@hotwaxmedia.com <mailto:andrew.zeneski@hotwaxmedia.com 
>>>>>>>> >>
>>>>>>>>> I think this is due to the new HTML security, but now we  
>>>>>>>>> have these  "&#160;" codes floating all over the place. I'm  
>>>>>>>>> not sure what the best  solution for this is, but I thought  
>>>>>>>>> I would check in a change like this:
>>>>>>>>
>>>>>>>> This is not as simple. I agree it's a quick fix for the issue  
>>>>>>>> at hand. But this is due to Labels Manager. If you put a sole  
>>>>>>>> space (ie > < ) then if you do some modifications with Labels  
>>>>>>>> Manager in this file and then save in the file you will get
>>>>>>>> <property key="CommonEmptyHeader">
>>>>>>>>   <value xml:lang="en"/>
>>>>>>>> </property>
>>>>>>>>
>>>>>>>> In order to cope with this I tried to write directly at  
>>>>>>>> SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String  
>>>>>>>> "&#160;" which should be ok. But I guess I would have to  
>>>>>>>> change the format passed to UtilXml.writeXmlDocument some  
>>>>>>>> lines below since else it write "&amp;#160;" and not "&#160;"  
>>>>>>>> as intended. Not sure it's possible though. And I have no  
>>>>>>>> time to look at it right now.
>>>>>>>>
>>>>>>>> So I made the change you proposed at r767845  and  r767848   
>>>>>>>> for R9.04
>>>>>>>> And we will have to deal with that in a complete way since  
>>>>>>>> else we will find an even worst trouble later (as soon  
>>>>>>>> someone will use Labels Manager to save changes in this file)
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>> I had some zele here (ok not only here ;o)
>>>>>>>>
>>>>>>>>> Index: config/CommonUiLabels.xml
>>>>>>>>> = 
>>>>>>>>> = 
>>>>>>>>> = 
>>>>>>>>> = 
>>>>>>>>> = 
>>>>>>>>> ==============================================================
>>>>>>>>> --- config/CommonUiLabels.xml (revision 767649)
>>>>>>>>> +++ config/CommonUiLabels.xml (working copy)
>>>>>>>>> @@ -1997,7 +1997,7 @@
>>>>>>>>>     <value xml:lang="zh_CN">电子邮件</value>
>>>>>>>>> </property>
>>>>>>>>> <property key="CommonEmptyHeader">
>>>>>>>>> -        <value xml:lang="en">&amp;#160;</value>
>>>>>>>>> +        <value xml:lang="en"> </value>
>>>>>>>>> </property>
>>>>>>>>> <property key="CommonEnabled">
>>>>>>>>>     <value xml:lang="ar">شغال</value>
>>>>>>>>>
>>>>>>>>> Any thoughts???
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Andrew
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>


Re:   Codes

Posted by Adrian Crum <ad...@hlmksw.com>.
Why would we want to put HTML in the UI labels?

-Adrian

Andrew Zeneski wrote:
> Here is a patch which does exactly this, and appears to work with just a 
> little testing. I'm just not sure of the total impact it will cause.
> 
> 
> 
> On Apr 23, 2009, at 1:44 PM, Andrew Zeneski wrote:
> 
>> Well there is an option which might be viable. We could simply wrap 
>> all values in the uiLabelMap using StringUtil.wrapString(). This will 
>> allow HTML characters in the UI labels again and shouldn't be too much 
>> of a security risk, as only developers have access to these strings.
>>
>> Thoughts?
>>
>> Andrew
>>
>> On Apr 23, 2009, at 10:56 AM, Adrian Crum wrote:
>>
>>> I agree. We should look into the widget code and the label manager 
>>> code to get these issues fixed properly.
>>>
>>> -Adrian
>>>
>>> Scott Gray wrote:
>>>> That's probably something we can fix in the widget code isn't it?  
>>>> If the title attribute is missing then use the field name otherwise 
>>>> render whatever is specified in the title even if it is just an 
>>>> empty string.
>>>> Regards
>>>> Scott
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/>
>>>> On 23/04/2009, at 8:53 PM, Jacopo Cappellato wrote:
>>>>> I think it is related to the situation where you want to specify an 
>>>>> empty content for the "title" attribute in form widgets. if title 
>>>>> element is missing or is set to title="" then the widgets render it 
>>>>> with the name of the field or simialr.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Apr 23, 2009, at 10:43 AM, Scott Gray wrote:
>>>>>
>>>>>> I can't remember the reason for adding the CommonEmptyHeader label 
>>>>>> but I'm wondering if we should consider removing it and find 
>>>>>> another solution to whatever problem it solved?
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>> HotWax Media
>>>>>> http://www.hotwaxmedia.com
>>>>>>
>>>>>> On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote:
>>>>>>
>>>>>>> Hi Andrew,
>>>>>>>
>>>>>>> From: "Andrew Zeneski" <andrew.zeneski@hotwaxmedia.com 
>>>>>>> <ma...@hotwaxmedia.com>>
>>>>>>>> I think this is due to the new HTML security, but now we have 
>>>>>>>> these  "&#160;" codes floating all over the place. I'm not sure 
>>>>>>>> what the best  solution for this is, but I thought I would check 
>>>>>>>> in a change like this:
>>>>>>>
>>>>>>> This is not as simple. I agree it's a quick fix for the issue at 
>>>>>>> hand. But this is due to Labels Manager. If you put a sole space 
>>>>>>> (ie > < ) then if you do some modifications with Labels Manager 
>>>>>>> in this file and then save in the file you will get
>>>>>>> <property key="CommonEmptyHeader">
>>>>>>>    <value xml:lang="en"/>
>>>>>>> </property>
>>>>>>>
>>>>>>> In order to cope with this I tried to write directly at 
>>>>>>> SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String "&#160;" 
>>>>>>> which should be ok. But I guess I would have to change the format 
>>>>>>> passed to UtilXml.writeXmlDocument some lines below since else it 
>>>>>>> write "&amp;#160;" and not "&#160;" as intended. Not sure it's 
>>>>>>> possible though. And I have no time to look at it right now.
>>>>>>>
>>>>>>> So I made the change you proposed at r767845  and  r767848  for 
>>>>>>> R9.04
>>>>>>> And we will have to deal with that in a complete way since else 
>>>>>>> we will find an even worst trouble later (as soon someone will 
>>>>>>> use Labels Manager to save changes in this file)
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> I had some zele here (ok not only here ;o)
>>>>>>>
>>>>>>>> Index: config/CommonUiLabels.xml
>>>>>>>> ===================================================================
>>>>>>>> --- config/CommonUiLabels.xml (revision 767649)
>>>>>>>> +++ config/CommonUiLabels.xml (working copy)
>>>>>>>> @@ -1997,7 +1997,7 @@
>>>>>>>>      <value xml:lang="zh_CN">电子邮件</value>
>>>>>>>>  </property>
>>>>>>>>  <property key="CommonEmptyHeader">
>>>>>>>> -        <value xml:lang="en">&amp;#160;</value>
>>>>>>>> +        <value xml:lang="en"> </value>
>>>>>>>>  </property>
>>>>>>>>  <property key="CommonEnabled">
>>>>>>>>      <value xml:lang="ar">شغال</value>
>>>>>>>>
>>>>>>>> Any thoughts???
>>>>>>>>
>>>>>>>>
>>>>>>>> Andrew
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
> 

Re:   Codes

Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
FYI the patch is here, not in the email...

https://issues.apache.org/jira/browse/OFBIZ-2349

Andrew

On Apr 23, 2009, at 2:12 PM, Andrew Zeneski wrote:

> Here is a patch which does exactly this, and appears to work with  
> just a little testing. I'm just not sure of the total impact it will  
> cause.
>
>
>
> On Apr 23, 2009, at 1:44 PM, Andrew Zeneski wrote:
>
>> Well there is an option which might be viable. We could simply wrap  
>> all values in the uiLabelMap using StringUtil.wrapString(). This  
>> will allow HTML characters in the UI labels again and shouldn't be  
>> too much of a security risk, as only developers have access to  
>> these strings.
>>
>> Thoughts?
>>
>> Andrew
>>
>> On Apr 23, 2009, at 10:56 AM, Adrian Crum wrote:
>>
>>> I agree. We should look into the widget code and the label manager  
>>> code to get these issues fixed properly.
>>>
>>> -Adrian
>>>
>>> Scott Gray wrote:
>>>> That's probably something we can fix in the widget code isn't  
>>>> it?  If the title attribute is missing then use the field name  
>>>> otherwise render whatever is specified in the title even if it is  
>>>> just an empty string.
>>>> Regards
>>>> Scott
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/>
>>>> On 23/04/2009, at 8:53 PM, Jacopo Cappellato wrote:
>>>>> I think it is related to the situation where you want to specify  
>>>>> an empty content for the "title" attribute in form widgets. if  
>>>>> title element is missing or is set to title="" then the widgets  
>>>>> render it with the name of the field or simialr.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Apr 23, 2009, at 10:43 AM, Scott Gray wrote:
>>>>>
>>>>>> I can't remember the reason for adding the CommonEmptyHeader  
>>>>>> label but I'm wondering if we should consider removing it and  
>>>>>> find another solution to whatever problem it solved?
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>> HotWax Media
>>>>>> http://www.hotwaxmedia.com
>>>>>>
>>>>>> On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote:
>>>>>>
>>>>>>> Hi Andrew,
>>>>>>>
>>>>>>> From: "Andrew Zeneski" <andrew.zeneski@hotwaxmedia.com <mailto:andrew.zeneski@hotwaxmedia.com 
>>>>>>> >>
>>>>>>>> I think this is due to the new HTML security, but now we have  
>>>>>>>> these  "&#160;" codes floating all over the place. I'm not  
>>>>>>>> sure what the best  solution for this is, but I thought I  
>>>>>>>> would check in a change like this:
>>>>>>>
>>>>>>> This is not as simple. I agree it's a quick fix for the issue  
>>>>>>> at hand. But this is due to Labels Manager. If you put a sole  
>>>>>>> space (ie > < ) then if you do some modifications with Labels  
>>>>>>> Manager in this file and then save in the file you will get
>>>>>>> <property key="CommonEmptyHeader">
>>>>>>>   <value xml:lang="en"/>
>>>>>>> </property>
>>>>>>>
>>>>>>> In order to cope with this I tried to write directly at  
>>>>>>> SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String  
>>>>>>> "&#160;" which should be ok. But I guess I would have to  
>>>>>>> change the format passed to UtilXml.writeXmlDocument some  
>>>>>>> lines below since else it write "&amp;#160;" and not "&#160;"  
>>>>>>> as intended. Not sure it's possible though. And I have no time  
>>>>>>> to look at it right now.
>>>>>>>
>>>>>>> So I made the change you proposed at r767845  and  r767848   
>>>>>>> for R9.04
>>>>>>> And we will have to deal with that in a complete way since  
>>>>>>> else we will find an even worst trouble later (as soon someone  
>>>>>>> will use Labels Manager to save changes in this file)
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> I had some zele here (ok not only here ;o)
>>>>>>>
>>>>>>>> Index: config/CommonUiLabels.xml
>>>>>>>> = 
>>>>>>>> = 
>>>>>>>> = 
>>>>>>>> = 
>>>>>>>> ===============================================================
>>>>>>>> --- config/CommonUiLabels.xml (revision 767649)
>>>>>>>> +++ config/CommonUiLabels.xml (working copy)
>>>>>>>> @@ -1997,7 +1997,7 @@
>>>>>>>>     <value xml:lang="zh_CN">电子邮件</value>
>>>>>>>> </property>
>>>>>>>> <property key="CommonEmptyHeader">
>>>>>>>> -        <value xml:lang="en">&amp;#160;</value>
>>>>>>>> +        <value xml:lang="en"> </value>
>>>>>>>> </property>
>>>>>>>> <property key="CommonEnabled">
>>>>>>>>     <value xml:lang="ar">شغال</value>
>>>>>>>>
>>>>>>>> Any thoughts???
>>>>>>>>
>>>>>>>>
>>>>>>>> Andrew
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
>


Re:   Codes

Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
Here is a patch which does exactly this, and appears to work with just  
a little testing. I'm just not sure of the total impact it will cause.



Re:   Codes

Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
Well there is an option which might be viable. We could simply wrap  
all values in the uiLabelMap using StringUtil.wrapString(). This will  
allow HTML characters in the UI labels again and shouldn't be too much  
of a security risk, as only developers have access to these strings.

Thoughts?

Andrew

On Apr 23, 2009, at 10:56 AM, Adrian Crum wrote:

> I agree. We should look into the widget code and the label manager  
> code to get these issues fixed properly.
>
> -Adrian
>
> Scott Gray wrote:
>> That's probably something we can fix in the widget code isn't it?   
>> If the title attribute is missing then use the field name otherwise  
>> render whatever is specified in the title even if it is just an  
>> empty string.
>> Regards
>> Scott
>> HotWax Media
>> http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/>
>> On 23/04/2009, at 8:53 PM, Jacopo Cappellato wrote:
>>> I think it is related to the situation where you want to specify  
>>> an empty content for the "title" attribute in form widgets. if  
>>> title element is missing or is set to title="" then the widgets  
>>> render it with the name of the field or simialr.
>>>
>>> Jacopo
>>>
>>> On Apr 23, 2009, at 10:43 AM, Scott Gray wrote:
>>>
>>>> I can't remember the reason for adding the CommonEmptyHeader  
>>>> label but I'm wondering if we should consider removing it and  
>>>> find another solution to whatever problem it solved?
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote:
>>>>
>>>>> Hi Andrew,
>>>>>
>>>>> From: "Andrew Zeneski" <andrew.zeneski@hotwaxmedia.com <mailto:andrew.zeneski@hotwaxmedia.com 
>>>>> >>
>>>>>> I think this is due to the new HTML security, but now we have  
>>>>>> these  "&#160;" codes floating all over the place. I'm not sure  
>>>>>> what the best  solution for this is, but I thought I would  
>>>>>> check in a change like this:
>>>>>
>>>>> This is not as simple. I agree it's a quick fix for the issue at  
>>>>> hand. But this is due to Labels Manager. If you put a sole space  
>>>>> (ie > < ) then if you do some modifications with Labels Manager  
>>>>> in this file and then save in the file you will get
>>>>> <property key="CommonEmptyHeader">
>>>>>     <value xml:lang="en"/>
>>>>> </property>
>>>>>
>>>>> In order to cope with this I tried to write directly at  
>>>>> SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String "&#160;"  
>>>>> which should be ok. But I guess I would have to change the  
>>>>> format passed to UtilXml.writeXmlDocument some lines below since  
>>>>> else it write "&amp;#160;" and not "&#160;" as intended. Not  
>>>>> sure it's possible though. And I have no time to look at it  
>>>>> right now.
>>>>>
>>>>> So I made the change you proposed at r767845  and  r767848  for  
>>>>> R9.04
>>>>> And we will have to deal with that in a complete way since else  
>>>>> we will find an even worst trouble later (as soon someone will  
>>>>> use Labels Manager to save changes in this file)
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> I had some zele here (ok not only here ;o)
>>>>>
>>>>>> Index: config/CommonUiLabels.xml
>>>>>> = 
>>>>>> = 
>>>>>> =================================================================
>>>>>> --- config/CommonUiLabels.xml (revision 767649)
>>>>>> +++ config/CommonUiLabels.xml (working copy)
>>>>>> @@ -1997,7 +1997,7 @@
>>>>>>       <value xml:lang="zh_CN">电子邮件</value>
>>>>>>   </property>
>>>>>>   <property key="CommonEmptyHeader">
>>>>>> -        <value xml:lang="en">&amp;#160;</value>
>>>>>> +        <value xml:lang="en"> </value>
>>>>>>   </property>
>>>>>>   <property key="CommonEnabled">
>>>>>>       <value xml:lang="ar">شغال</value>
>>>>>>
>>>>>> Any thoughts???
>>>>>>
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>>
>>>>>
>>>>
>>>


Re:   Codes

Posted by Adrian Crum <ad...@hlmksw.com>.
I agree. We should look into the widget code and the label manager code 
to get these issues fixed properly.

-Adrian

Scott Gray wrote:
> That's probably something we can fix in the widget code isn't it?  If 
> the title attribute is missing then use the field name otherwise render 
> whatever is specified in the title even if it is just an empty string.
> 
> Regards
> Scott
> 
> HotWax Media
> http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/>
> 
> On 23/04/2009, at 8:53 PM, Jacopo Cappellato wrote:
> 
>> I think it is related to the situation where you want to specify an 
>> empty content for the "title" attribute in form widgets. if title 
>> element is missing or is set to title="" then the widgets render it 
>> with the name of the field or simialr.
>>
>> Jacopo
>>
>> On Apr 23, 2009, at 10:43 AM, Scott Gray wrote:
>>
>>> I can't remember the reason for adding the CommonEmptyHeader label 
>>> but I'm wondering if we should consider removing it and find another 
>>> solution to whatever problem it solved?
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>> From: "Andrew Zeneski" <andrew.zeneski@hotwaxmedia.com 
>>>> <ma...@hotwaxmedia.com>>
>>>>> I think this is due to the new HTML security, but now we have these 
>>>>>  "&#160;" codes floating all over the place. I'm not sure what the 
>>>>> best  solution for this is, but I thought I would check in a change 
>>>>> like this:
>>>>
>>>> This is not as simple. I agree it's a quick fix for the issue at 
>>>> hand. But this is due to Labels Manager. If you put a sole space (ie 
>>>> > < ) then if you do some modifications with Labels Manager in this 
>>>> file and then save in the file you will get
>>>>  <property key="CommonEmptyHeader">
>>>>      <value xml:lang="en"/>
>>>>  </property>
>>>>
>>>> In order to cope with this I tried to write directly at 
>>>> SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String "&#160;" 
>>>> which should be ok. But I guess I would have to change the format 
>>>> passed to UtilXml.writeXmlDocument some lines below since else it 
>>>> write "&amp;#160;" and not "&#160;" as intended. Not sure it's 
>>>> possible though. And I have no time to look at it right now.
>>>>
>>>> So I made the change you proposed at r767845  and  r767848  for R9.04
>>>> And we will have to deal with that in a complete way since else we 
>>>> will find an even worst trouble later (as soon someone will use 
>>>> Labels Manager to save changes in this file)
>>>>
>>>> Jacques
>>>>
>>>>
>>>> I had some zele here (ok not only here ;o)
>>>>
>>>>> Index: config/CommonUiLabels.xml
>>>>> ===================================================================
>>>>> --- config/CommonUiLabels.xml (revision 767649)
>>>>> +++ config/CommonUiLabels.xml (working copy)
>>>>> @@ -1997,7 +1997,7 @@
>>>>>        <value xml:lang="zh_CN">电子邮件</value>
>>>>>    </property>
>>>>>    <property key="CommonEmptyHeader">
>>>>> -        <value xml:lang="en">&amp;#160;</value>
>>>>> +        <value xml:lang="en"> </value>
>>>>>    </property>
>>>>>    <property key="CommonEnabled">
>>>>>        <value xml:lang="ar">شغال</value>
>>>>>
>>>>> Any thoughts???
>>>>>
>>>>>
>>>>> Andrew
>>>>>
>>>>
>>>>
>>>
>>
> 

Re:   Codes

Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
I had a look into this; the code is the following one:

         if (this.title == null || formElement.hasAttribute("title")) {
             this.title = formElement.getAttribute("title");
         }

the tricky thing is that formElement.hasAttribute("title") returns  
true even if the title is not set (this is weird, according to the api  
definition it shouldn't);

For this reason, the following two field definitions are equivalent  
(i.e. you get "fieldname" as the column header/title of the field):

         <field name="fieldname"><display/></field>
         <field name="fieldname" title=""><display/></field>

and the only workaround is to use:

         <field name="fieldname" title=" "><display/></field>

If we prefer this solution (over CommonEmptyHeader) we can go for it.

Jacopo

On Apr 23, 2009, at 11:18 AM, Scott Gray wrote:

> That's probably something we can fix in the widget code isn't it?   
> If the title attribute is missing then use the field name otherwise  
> render whatever is specified in the title even if it is just an  
> empty string.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 23/04/2009, at 8:53 PM, Jacopo Cappellato wrote:
>
>> I think it is related to the situation where you want to specify an  
>> empty content for the "title" attribute in form widgets. if title  
>> element is missing or is set to title="" then the widgets render it  
>> with the name of the field or simialr.
>>
>> Jacopo
>>
>> On Apr 23, 2009, at 10:43 AM, Scott Gray wrote:
>>
>>> I can't remember the reason for adding the CommonEmptyHeader label  
>>> but I'm wondering if we should consider removing it and find  
>>> another solution to whatever problem it solved?
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>> From: "Andrew Zeneski" <an...@hotwaxmedia.com>
>>>>> I think this is due to the new HTML security, but now we have  
>>>>> these  "&#160;" codes floating all over the place. I'm not sure  
>>>>> what the best  solution for this is, but I thought I would check  
>>>>> in a change like this:
>>>>
>>>> This is not as simple. I agree it's a quick fix for the issue at  
>>>> hand. But this is due to Labels Manager. If you put a sole space  
>>>> (ie > < ) then if you do some modifications with Labels Manager  
>>>> in this file and then save in the file you will get
>>>>  <property key="CommonEmptyHeader">
>>>>      <value xml:lang="en"/>
>>>>  </property>
>>>>
>>>> In order to cope with this I tried to write directly at  
>>>> SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String "&#160;"  
>>>> which should be ok. But I guess I would have to change the format  
>>>> passed to UtilXml.writeXmlDocument some lines below since else it  
>>>> write "&amp;#160;" and not "&#160;" as intended. Not sure it's  
>>>> possible though. And I have no time to look at it right now.
>>>>
>>>> So I made the change you proposed at r767845  and  r767848  for  
>>>> R9.04
>>>> And we will have to deal with that in a complete way since else  
>>>> we will find an even worst trouble later (as soon someone will  
>>>> use Labels Manager to save changes in this file)
>>>>
>>>> Jacques
>>>>
>>>>
>>>> I had some zele here (ok not only here ;o)
>>>>
>>>>> Index: config/CommonUiLabels.xml
>>>>> = 
>>>>> ==================================================================
>>>>> --- config/CommonUiLabels.xml (revision 767649)
>>>>> +++ config/CommonUiLabels.xml (working copy)
>>>>> @@ -1997,7 +1997,7 @@
>>>>>        <value xml:lang="zh_CN">电子邮件</value>
>>>>>    </property>
>>>>>    <property key="CommonEmptyHeader">
>>>>> -        <value xml:lang="en">&amp;#160;</value>
>>>>> +        <value xml:lang="en"> </value>
>>>>>    </property>
>>>>>    <property key="CommonEnabled">
>>>>>        <value xml:lang="ar">شغال</value>
>>>>>
>>>>> Any thoughts???
>>>>>
>>>>>
>>>>> Andrew
>>>>>
>>>>
>>>>
>>>
>>
>


Re:   Codes

Posted by Scott Gray <sc...@hotwaxmedia.com>.
That's probably something we can fix in the widget code isn't it?  If  
the title attribute is missing then use the field name otherwise  
render whatever is specified in the title even if it is just an empty  
string.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 23/04/2009, at 8:53 PM, Jacopo Cappellato wrote:

> I think it is related to the situation where you want to specify an  
> empty content for the "title" attribute in form widgets. if title  
> element is missing or is set to title="" then the widgets render it  
> with the name of the field or simialr.
>
> Jacopo
>
> On Apr 23, 2009, at 10:43 AM, Scott Gray wrote:
>
>> I can't remember the reason for adding the CommonEmptyHeader label  
>> but I'm wondering if we should consider removing it and find  
>> another solution to whatever problem it solved?
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote:
>>
>>> Hi Andrew,
>>>
>>> From: "Andrew Zeneski" <an...@hotwaxmedia.com>
>>>> I think this is due to the new HTML security, but now we have  
>>>> these  "&#160;" codes floating all over the place. I'm not sure  
>>>> what the best  solution for this is, but I thought I would check  
>>>> in a change like this:
>>>
>>> This is not as simple. I agree it's a quick fix for the issue at  
>>> hand. But this is due to Labels Manager. If you put a sole space  
>>> (ie > < ) then if you do some modifications with Labels Manager in  
>>> this file and then save in the file you will get
>>>  <property key="CommonEmptyHeader">
>>>      <value xml:lang="en"/>
>>>  </property>
>>>
>>> In order to cope with this I tried to write directly at  
>>> SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String "&#160;"  
>>> which should be ok. But I guess I would have to change the format  
>>> passed to UtilXml.writeXmlDocument some lines below since else it  
>>> write "&amp;#160;" and not "&#160;" as intended. Not sure it's  
>>> possible though. And I have no time to look at it right now.
>>>
>>> So I made the change you proposed at r767845  and  r767848  for  
>>> R9.04
>>> And we will have to deal with that in a complete way since else we  
>>> will find an even worst trouble later (as soon someone will use  
>>> Labels Manager to save changes in this file)
>>>
>>> Jacques
>>>
>>>
>>> I had some zele here (ok not only here ;o)
>>>
>>>> Index: config/CommonUiLabels.xml
>>>> ===================================================================
>>>> --- config/CommonUiLabels.xml (revision 767649)
>>>> +++ config/CommonUiLabels.xml (working copy)
>>>> @@ -1997,7 +1997,7 @@
>>>>        <value xml:lang="zh_CN">电子邮件</value>
>>>>    </property>
>>>>    <property key="CommonEmptyHeader">
>>>> -        <value xml:lang="en">&amp;#160;</value>
>>>> +        <value xml:lang="en"> </value>
>>>>    </property>
>>>>    <property key="CommonEnabled">
>>>>        <value xml:lang="ar">شغال</value>
>>>>
>>>> Any thoughts???
>>>>
>>>>
>>>> Andrew
>>>>
>>>
>>>
>>
>


Re:   Codes

Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
I think it is related to the situation where you want to specify an  
empty content for the "title" attribute in form widgets. if title  
element is missing or is set to title="" then the widgets render it  
with the name of the field or simialr.

Jacopo

On Apr 23, 2009, at 10:43 AM, Scott Gray wrote:

> I can't remember the reason for adding the CommonEmptyHeader label  
> but I'm wondering if we should consider removing it and find another  
> solution to whatever problem it solved?
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote:
>
>> Hi Andrew,
>>
>> From: "Andrew Zeneski" <an...@hotwaxmedia.com>
>>> I think this is due to the new HTML security, but now we have  
>>> these  "&#160;" codes floating all over the place. I'm not sure  
>>> what the best  solution for this is, but I thought I would check  
>>> in a change like this:
>>
>> This is not as simple. I agree it's a quick fix for the issue at  
>> hand. But this is due to Labels Manager. If you put a sole space  
>> (ie > < ) then if you do some modifications with Labels Manager in  
>> this file and then save in the file you will get
>>   <property key="CommonEmptyHeader">
>>       <value xml:lang="en"/>
>>   </property>
>>
>> In order to cope with this I tried to write directly at  
>> SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String "&#160;"  
>> which should be ok. But I guess I would have to change the format  
>> passed to UtilXml.writeXmlDocument some lines below since else it  
>> write "&amp;#160;" and not "&#160;" as intended. Not sure it's  
>> possible though. And I have no time to look at it right now.
>>
>> So I made the change you proposed at r767845  and  r767848  for R9.04
>> And we will have to deal with that in a complete way since else we  
>> will find an even worst trouble later (as soon someone will use  
>> Labels Manager to save changes in this file)
>>
>> Jacques
>>
>>
>> I had some zele here (ok not only here ;o)
>>
>>> Index: config/CommonUiLabels.xml
>>> ===================================================================
>>> --- config/CommonUiLabels.xml (revision 767649)
>>> +++ config/CommonUiLabels.xml (working copy)
>>> @@ -1997,7 +1997,7 @@
>>>         <value xml:lang="zh_CN">电子邮件</value>
>>>     </property>
>>>     <property key="CommonEmptyHeader">
>>> -        <value xml:lang="en">&amp;#160;</value>
>>> +        <value xml:lang="en"> </value>
>>>     </property>
>>>     <property key="CommonEnabled">
>>>         <value xml:lang="ar">شغال</value>
>>>
>>> Any thoughts???
>>>
>>>
>>> Andrew
>>>
>>
>>
>


Re:   Codes

Posted by Scott Gray <sc...@hotwaxmedia.com>.
I can't remember the reason for adding the CommonEmptyHeader label but  
I'm wondering if we should consider removing it and find another  
solution to whatever problem it solved?

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote:

> Hi Andrew,
>
> From: "Andrew Zeneski" <an...@hotwaxmedia.com>
>> I think this is due to the new HTML security, but now we have  
>> these  "&#160;" codes floating all over the place. I'm not sure  
>> what the best  solution for this is, but I thought I would check in  
>> a change like this:
>
> This is not as simple. I agree it's a quick fix for the issue at  
> hand. But this is due to Labels Manager. If you put a sole space (ie  
> > < ) then if you do some modifications with Labels Manager in this  
> file and then save in the file you will get
>   <property key="CommonEmptyHeader">
>       <value xml:lang="en"/>
>   </property>
>
> In order to cope with this I tried to write directly at  
> SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String "&#160;"  
> which should be ok. But I guess I would have to change the format  
> passed to UtilXml.writeXmlDocument some lines below since else it  
> write "&amp;#160;" and not "&#160;" as intended. Not sure it's  
> possible though. And I have no time to look at it right now.
>
> So I made the change you proposed at r767845  and  r767848  for R9.04
> And we will have to deal with that in a complete way since else we  
> will find an even worst trouble later (as soon someone will use  
> Labels Manager to save changes in this file)
>
> Jacques
>
>
> I had some zele here (ok not only here ;o)
>
>> Index: config/CommonUiLabels.xml
>> ===================================================================
>> --- config/CommonUiLabels.xml (revision 767649)
>> +++ config/CommonUiLabels.xml (working copy)
>> @@ -1997,7 +1997,7 @@
>>         <value xml:lang="zh_CN">电子邮件</value>
>>     </property>
>>     <property key="CommonEmptyHeader">
>> -        <value xml:lang="en">&amp;#160;</value>
>> +        <value xml:lang="en"> </value>
>>     </property>
>>     <property key="CommonEnabled">
>>         <value xml:lang="ar">شغال</value>
>>
>> Any thoughts???
>>
>>
>> Andrew
>>
>
>


Re:   Codes

Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Andrew,

From: "Andrew Zeneski" <an...@hotwaxmedia.com>
>I think this is due to the new HTML security, but now we have these  "&#160;" codes floating all over the place. I'm not sure what 
>the best  solution for this is, but I thought I would check in a change like this:

This is not as simple. I agree it's a quick fix for the issue at hand. But this is due to Labels Manager. If you put a sole space 
(ie > < ) then if you do some modifications with Labels Manager in this file and then save in the file you will get
    <property key="CommonEmptyHeader">
        <value xml:lang="en"/>
    </property>

In order to cope with this I tried to write directly at SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String "&#160;" which should 
be ok. But I guess I would have to change the format passed to UtilXml.writeXmlDocument some lines below since else it write 
"&amp;#160;" and not "&#160;" as intended. Not sure it's possible though. And I have no time to look at it right now.

So I made the change you proposed at r767845  and  r767848  for R9.04
And we will have to deal with that in a complete way since else we will find an even worst trouble later (as soon someone will use 
Labels Manager to save changes in this file)

Jacques


I had some zele here (ok not only here ;o)

> Index: config/CommonUiLabels.xml
> ===================================================================
> --- config/CommonUiLabels.xml (revision 767649)
> +++ config/CommonUiLabels.xml (working copy)
> @@ -1997,7 +1997,7 @@
>          <value xml:lang="zh_CN">电子邮件</value>
>      </property>
>      <property key="CommonEmptyHeader">
> -        <value xml:lang="en">&amp;#160;</value>
> +        <value xml:lang="en"> </value>
>      </property>
>      <property key="CommonEnabled">
>          <value xml:lang="ar">شغال</value>
>
> Any thoughts???
>
>
> Andrew
>
>