|Andrew Zeneski||Apr 22, 2009 10:31 pm|
|Jacques Le Roux||Apr 23, 2009 1:24 am|
|Scott Gray||Apr 23, 2009 1:43 am|
|Jacopo Cappellato||Apr 23, 2009 1:53 am|
|Scott Gray||Apr 23, 2009 2:17 am|
|Adrian Crum||Apr 23, 2009 7:55 am|
|Andrew Zeneski||Apr 23, 2009 10:43 am|
|Jacopo Cappellato||Apr 23, 2009 10:49 am|
|Andrew Zeneski||Apr 23, 2009 11:12 am|
|Andrew Zeneski||Apr 23, 2009 11:27 am|
|Adrian Crum||Apr 23, 2009 11:28 am|
|David E Jones||Apr 23, 2009 11:41 am|
|Andrew Zeneski||Apr 23, 2009 12:32 pm|
|David E Jones||Apr 23, 2009 12:38 pm|
|Adrian Crum||Apr 23, 2009 1:22 pm|
|Adrian Crum||Apr 23, 2009 7:03 pm|
|Jacques Le Roux||Apr 24, 2009 12:07 am|
|From:||Adrian Crum (adri...@yahoo.com)|
|Date:||Apr 23, 2009 7:03:17 pm|
Okay, the Label Manager issue is fixed in revision 768123.
--- On Thu, 4/23/09, Adrian Crum <adri...@hlmksw.com> wrote:
From: Adrian Crum <adri...@hlmksw.com> Subject: Re:   Codes To: de...@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.
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).
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.
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.
On Apr 23, 2009, at 12:28 PM, Adrian Crum wrote:
Why would we want to put HTML in the UI labels?
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
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.
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.
Scott Gray wrote:
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.
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.
On Apr 23, 2009, at 10:43 AM, Scott Gray wrote:
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?
On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote:
this is due to the new HTML security, but now we have these " " 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"/>
In order to
cope with this I tried to write directly at SaveLabelsToXmlFile.saveLabelsToXmlFile the String " " 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 "&#160;" and not " " 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)
I had some zele here (ok not only here ;o)
--- config/CommonUiLabels.xml (revision 767649) +++ config/CommonUiLabels.xml (working copy) @@ -1997,7 +1997,7 @@
+ <value xml:lang="en"> </value>