I was asking more about where the messages are coming from, not how
they get displayed (all messages come through those generic messages
file...). We discussed this a while back (around the time of adding
the auto-escaping) and it has come up a couple of times since then.
The decision so far has been to escape these messages so they appear
literally to the user. Part of the reason for that is that we don't
want HTML in these messages.
So no, we shouldn't wrap them in a non-String to get around the HTML
escaping. In other words, the messages strings should be escaped.
However, if there is a specific scenario you've run into where HTML is
needed in the messages, please share that and we can discuss whether
or not to change the direction that has been established. I think you
were trying to list one below, but I'm not really sure as that looks
like just the type of messages that we would WANT to be escaped so
that none of the characters in it area interpreted as tags.
I can understand that maybe you forgot about these discussions, but at
least wait for feedback. Unless others agree and there is a good
reason to not escape error messages my opinion is that the changes in
revs 772887 and 772893 should be reverted.
-David
On May 8, 2009, at 2:58 AM, Jacques Le Roux wrote:
From: "David E Jones" <[email protected]>
Which error messages are you referring to, ie coming from where?
Error and event messages (respective lists also) rendered in UI by
message.ftl files
At r772887, I generalized r767694 to allow better error messages
rendering.
Actually I was more interested to solve the same issue in
BizznessTime, but StringUtil.wrapString is not working there (I
guess humanMsg.displayMsg is waiting a string and not something
embedded). I gave up :/
The reason I was trying to do that is that if you get a message
which allows to fill a sub-task of https://issues.apache.org/jira/browse/OFBIZ-2330
, you are not able to read it in BizznessTime. And as it's the
default now it's pretty annoying. As you can see in OFBIZ-2330 this
stratagem as pretty well worked so far to get returns from users.
Jacques
PS: the kind of msg I'm reffering to contains
<<Moreover it would be kind if you could create a Jira sub-task of
https://issues.apache.org/jira/browse/OFBIZ-2330
(check before if a sub-task for this error does not exist).
If you are not sure how to create a Jira issue please have a look
before at http://docs.ofbiz.org/x/r.
Thank you in advance for your help.>>
-David
On May 7, 2009, at 5:23 PM, Jacques Le Roux wrote:
Following this fix, I wonder if we should not put
StringUtil.wrapString around all error messages since some of
them use html entities and we don't care about security at this
stage.
Jacques
PS : Mmm... Actually I already did it for framework at r767694.
Should be extended to all message.ftl files...
