So we are back to my 1st solution
* easy, but certainly not generic enough, put an underscore before each 
surveyQuestionId value
isn'it ?

Or should we try to take specifically into account this problem for surveys ? I 
don't htink so finally...

That means also that people will have to take care with Id now : they can't begin by a digit, period. I guess most of us are already well acquainted with that from our background...

Jacques

From: "Adrian Crum" <[email protected]>
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







Reply via email to