It could be worded differently - I'll try to work on it when I have some
time.
The wiki document tries to explain how identifiers in UEL must follow
Java naming conventions. In other words, an identifier cannot start with
a digit.
The expression ${answers.1040} would evaluate to a List, because 1040
starts with a digit and that makes it an integer. The expression
${answers._1040} would evaluate to a Map or Bean since the identifier
_1040 starts with a non-digit character.
As I explained to Brett the other day, you have to look at UEL
expressions from an expression viewpoint, not from an implementation
viewpoint. The OFBiz developer community is used to thinking of
expressions as a collection of Maps (the implementation). That has
changed with the conversion to UEL. Using sequence IDs as Map keys was a
cool trick in the old code, but it just won't work with UEL - because
UEL doesn't consider them as Map keys.
Here is another way to look at it:
The Java code
public class answers {
public String 1040 = "Hello World!";
}
would not compile because 1040 is not a valid Java identifier. The Java code
public class answers {
public String _1040 = "Hello World!";
}
would compile because _1040 is a valid Java identifier.
I put some code in the framework to try and do some on-the-fly
expression conversions. If a digit follows a period, then an underscore
is inserted after the period. This helps maintain some backward
compatibility, but the downside is an expression like ${$5.95} will be
mistakenly converted to ${5._95}.
In summary, the best approach to this type of problem is to convert the
sequence ID to a valid Java identifier by changing the first character
of the ID.
-Adrian
David E Jones wrote:
That's a great document, but I don't see an answer to this question
there...
Am I missing something?
BTW, I haven't tried either of my suggestions in this case.
Adding an underscore to the beginning is great, but it needs to be done
everywhere the Map is used, including all get and set operations and any
that are missed will fail.
-David
On Feb 1, 2009, at 10:37 AM, Adrian Crum wrote:
http://docs.ofbiz.org/display/OFBTECH/Unified+Expression+Language+(JSR-245)+in+OFBiz
--- On Sun, 2/1/09, David E Jones <[email protected]> wrote:
From: David E Jones <[email protected]>
Subject: Re: Minipol in eCommerce
To: [email protected]
Date: Sunday, February 1, 2009, 10:15 AM
One limitation of the dot syntax under UEL is that it treats
the Map entry keys as variable names, which I think causes
this problem.
To get around it we may have to change the code and instead
of using something like answers.fieldName either use
something like answers[fieldName] or even
answers.get(fieldName) if we have issues with that.
-David
On Feb 1, 2009, at 10:00 AM, Jacques Le Roux wrote:
I had a new look at this. It's a problem with the
FlexibleMapAccessor.
It interprets "answers.1040" as null. There
are 2 solutions
* easy, but certainly not generic enough, put an
underscore before each surveyQuestionId value
* change FlexibleMapAccessor to not interprets strings
like "answers.1040" as null, resulting for
if-empty tag to render a false result (empty, but it's
not)
I remember having seen a discussion about such strings
(Id beginning by a digit) but I did not find it.
Jacques
