Minipol in eCommerce
Locked
 
Administrator
|
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 |
|
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 |
|
Administrator
|
In reply to this post by Jacques Le Roux
David,
I see that a syntax using underscore is already used in processSurveyResponseInline (SurveyServices.xml[726]) Could it not be a global solution to this answers issue ? Jacques From: "Assist" <[hidden email]> > Thanks David, > > I put your suggestion in https://issues.apache.org/jira/browse/OFBIZ-2112?focusedCommentId=12669418#action_12669418 > > Jacques > > From: "David E Jones" <[hidden email]> >> >> 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 >> |
|
|
In reply to this post by David E Jones-3
http://docs.ofbiz.org/display/OFBTECH/Unified+Expression+Language+(JSR-245)+in+OFBiz
--- On Sun, 2/1/09, David E Jones <[hidden email]> wrote: > From: David E Jones <[hidden email]> > Subject: Re: Minipol in eCommerce > To: [hidden email] > 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 |
|
|
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 <[hidden email]> wrote: > >> From: David E Jones <[hidden email]> >> Subject: Re: Minipol in eCommerce >> To: [hidden email] >> 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 > > > |
|
|
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 <[hidden email]> wrote: >> >>> From: David E Jones <[hidden email]> >>> Subject: Re: Minipol in eCommerce >>> To: [hidden email] >>> 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 >> >> >> > > |
|
Administrator
|
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" <[hidden email]> > 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 <[hidden email]> wrote: >>> >>>> From: David E Jones <[hidden email]> >>>> Subject: Re: Minipol in eCommerce >>>> To: [hidden email] >>>> 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 >>> >>> >>> >> >> > |
|
|
In reply to this post by Adrian Crum
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 <[hidden email]> >>> wrote: >>> >>>> From: David E Jones <[hidden email]> >>>> Subject: Re: Minipol in eCommerce >>>> To: [hidden email] >>>> 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 >>> >>> >>> |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |