You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2009/02/01 19:00:16 UTC
Minipol in eCommerce
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
Re: Minipol in eCommerce
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <ad...@hlmksw.com>
> 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 <da...@hotwaxmedia.com> wrote:
>>>
>>>> From: David E Jones <da...@hotwaxmedia.com>
>>>> Subject: Re: Minipol in eCommerce
>>>> To: dev@ofbiz.apache.org
>>>> 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
>>>
>>>
>>>
>>
>>
>
Re: Minipol in eCommerce
Posted by David E Jones <da...@hotwaxmedia.com>.
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 <da...@hotwaxmedia.com>
>>> wrote:
>>>
>>>> From: David E Jones <da...@hotwaxmedia.com>
>>>> Subject: Re: Minipol in eCommerce
>>>> To: dev@ofbiz.apache.org
>>>> 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
>>>
>>>
>>>
Re: Minipol in eCommerce
Posted by Adrian Crum <ad...@hlmksw.com>.
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 <da...@hotwaxmedia.com> wrote:
>>
>>> From: David E Jones <da...@hotwaxmedia.com>
>>> Subject: Re: Minipol in eCommerce
>>> To: dev@ofbiz.apache.org
>>> 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
>>
>>
>>
>
>
Re: Minipol in eCommerce
Posted by David E Jones <da...@hotwaxmedia.com>.
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 <da...@hotwaxmedia.com> wrote:
>
>> From: David E Jones <da...@hotwaxmedia.com>
>> Subject: Re: Minipol in eCommerce
>> To: dev@ofbiz.apache.org
>> 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
>
>
>
Re: Minipol in eCommerce
Posted by Adrian Crum <ad...@yahoo.com>.
http://docs.ofbiz.org/display/OFBTECH/Unified+Expression+Language+(JSR-245)+in+OFBiz
--- On Sun, 2/1/09, David E Jones <da...@hotwaxmedia.com> wrote:
> From: David E Jones <da...@hotwaxmedia.com>
> Subject: Re: Minipol in eCommerce
> To: dev@ofbiz.apache.org
> 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
Re: Minipol in eCommerce
Posted by David E Jones <da...@hotwaxmedia.com>.
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