Adrian,
My whole point was that the document does a fine job of explaining the
problem, which I summed up in my email... but says nothing about a
solution. In this reply you mentioned one option, which we can add in
this discussion to the 3 I already presented.
I think the problem is well understood, it's really not that complex,
the solutions are trickier.
-David
On Feb 2, 2009, at 9:13 AM, Adrian Crum wrote:
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
