From: "Adam Heath" <[email protected]>
Scott Gray wrote:
On 10/03/2010, at 10:35 AM, Adam Heath wrote:
Scott Gray wrote:
On 10/03/2010, at 9:48 AM, Adam Heath wrote:
[email protected] wrote:
Author: jleroux
Date: Wed Mar 10 16:12:30 2010
New Revision: 921421
URL: http://svn.apache.org/viewvc?rev=921421&view=rev
Log:
You can't use double quote in tooltips. I tried to find a quick way to allow this in MacroFormRenderer.appendTooltip() but
gave up, too narrow need.
Modified:
ofbiz/trunk/framework/example/config/ExampleUiLabels.xml
Modified: ofbiz/trunk/framework/example/config/ExampleUiLabels.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/config/ExampleUiLabels.xml?rev=921421&r1=921420&r2=921421&view=diff
==============================================================================
--- ofbiz/trunk/framework/example/config/ExampleUiLabels.xml (original)
+++ ofbiz/trunk/framework/example/config/ExampleUiLabels.xml Wed Mar 10
16:12:30 2010
@@ -97,7 +97,7 @@
</property>
<property key="ExampleDateField10Tooltip">
<value xml:lang="en">Same as above, uses the nowTimestamp variable (always available in the form context) to set the
default value to now</value>
- <value xml:lang="fr">La même chose mais la variable nowTimestamp (toujours disponible dans context) est utilisée
pour affecter la valeur par défaut à "maintenant"</value>
+ <value xml:lang="fr">La même chose mais la variable nowTimestamp (toujours disponible dans context) est utilisée
pour affecter la valeur par défaut à 'maintenant'</value>
<value xml:lang="it">Lo stesso di sopra, usare la variabile nowTimestamp (sempre disponibile nel contesto della form)
per impostare il valore di default ad adesso</value>
<value xml:lang="zh">åŒä¸Šï¼Œä½¿ç”¨nowTimstampå˜é‡(在表å•ä¸
总是å¯ç”¨çš„)æ¥æŠŠç¼ºçœå€¼è®¾ç½®ä¸ºçŽ°åœ¨</value>
</property>
tooltip.replaceAll("\"", """), also handling any other weird html
characters, like < or > or &.
I agree about other weird characters but not for the double quote case.
If you like at it closer you will see that it's not an encoding issue.
Because we have to distinguish between quote around the tooltip and inside the
tooltip.
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);
It's not the same case
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.
Did you try? You will get something like
2010-03-10 19:32:05,375 (http-0.0.0.0-8443-6) [
MacroFormRenderer.java:135:ERROR]
---- exception report ----------------------------------------------------------
Error rendering screen thru ftl
Exception: freemarker.core.ParseException
Message: Encountered "%" at line 1, column 25 in Wed Mar 10 19:32:05 CET 2010.
Was expecting one of:
<STRING_LITERAL> ...
<RAW_STRING> ...
"false" ...
"true" ...
<INTEGER> ...
<DECIMAL> ...
"." ...
"+" ...
"-" ...
"!" ...
"[" ...
"(" ...
"{" ...
<ID> ...
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?
That's the problem I crossed in r921401
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.
Yes, I agree with that, but IMO it's a delicate issue. A bit like the work you did for BigDecimal, maybe harder because there are
different cases, maybe not because these cases are possibly the same all over.
Jacques
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.
