I was planning on fixing this in the Java code. Be patient! ;-)
-Adrian [hidden email] wrote: > Author: jonesde > Date: Mon Dec 15 14:08:31 2008 > New Revision: 726837 > > URL: http://svn.apache.org/viewvc?rev=726837&view=rev > Log: > Fixed issue with ambiguous syntax using the new UEL stuff and in this case a productId with an arithmetic symbol in it, namely the minus sign > > Modified: > ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/StockMoveServices.xml > > Modified: ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/StockMoveServices.xml > URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/StockMoveServices.xml?rev=726837&r1=726836&r2=726837&view=diff > ============================================================================== > --- ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/StockMoveServices.xml (original) > +++ ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/StockMoveServices.xml Mon Dec 15 14:08:31 2008 > @@ -62,7 +62,7 @@ > <!-- now for more fun, split up by productId; this should generally not happen, but we'll make sure here --> > <clear-field field-name="oiirailByProdMap"/> > <iterate entry-name="orderItemShipGrpInvResAndItemLocation" list-name="perLocationOiirailList"> > - <field-to-list field-name="orderItemShipGrpInvResAndItemLocation" list-name="oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"/> > + <field-to-list field-name="orderItemShipGrpInvResAndItemLocation" list-name="oiirailByProdMap["${orderItemShipGrpInvResAndItemLocation.productId}"]"/> > </iterate> > > <clear-field field-name="perProductOiirailList"/> > > > |
IFF you can find a fix in the Java code. Because of the way UEL interprets things I don't think that will be possible. Like I explained IGNORING the error doesn't make it go away, it just causes a bigger problem by hiding the problem. If there is a general way to actually handle this, ie fix the problems and not just ignore the errors, then let's do it by all means. However, with UEL we're introducing new syntax rules and things like this are likely to come up. In this case, there is NO way for the parser to know that the "-" is part of the ID and not an arithmetic operator without using a different syntax, as is done in this commit. Well, if we could tell the parser "no arithmetic" for these sorts of expressions then we might be able to fix it in Java, but otherwise based on my experience with parsers and general parsing concepts, then there's no way to avoid these kinds of changes. -David On Dec 15, 2008, at 3:21 PM, Adrian Crum wrote: > I was planning on fixing this in the Java code. Be patient! ;-) > > -Adrian > > [hidden email] wrote: >> Author: jonesde >> Date: Mon Dec 15 14:08:31 2008 >> New Revision: 726837 >> URL: http://svn.apache.org/viewvc?rev=726837&view=rev >> Log: >> Fixed issue with ambiguous syntax using the new UEL stuff and in >> this case a productId with an arithmetic symbol in it, namely the >> minus sign >> Modified: >> ofbiz/trunk/applications/product/script/org/ofbiz/product/ >> inventory/StockMoveServices.xml >> Modified: ofbiz/trunk/applications/product/script/org/ofbiz/product/ >> inventory/StockMoveServices.xml >> URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/StockMoveServices.xml?rev=726837&r1=726836&r2=726837&view=diff >> = >> = >> = >> = >> = >> = >> = >> = >> = >> ===================================================================== >> --- ofbiz/trunk/applications/product/script/org/ofbiz/product/ >> inventory/StockMoveServices.xml (original) >> +++ ofbiz/trunk/applications/product/script/org/ofbiz/product/ >> inventory/StockMoveServices.xml Mon Dec 15 14:08:31 2008 >> @@ -62,7 +62,7 @@ >> <!-- now for more fun, split up by productId; this >> should generally not happen, but we'll make sure here --> >> <clear-field field-name="oiirailByProdMap"/> >> <iterate entry- >> name="orderItemShipGrpInvResAndItemLocation" list- >> name="perLocationOiirailList"> >> - <field-to-list field- >> name="orderItemShipGrpInvResAndItemLocation" list- >> name="oiirailByProdMap.$ >> {orderItemShipGrpInvResAndItemLocation.productId}"/> >> + <field-to-list field- >> name="orderItemShipGrpInvResAndItemLocation" list- >> name="oiirailByProdMap["$ >> {orderItemShipGrpInvResAndItemLocation.productId}"]"/> >> </iterate> >> <clear-field field-name="perProductOiirailList"/> |
David E Jones wrote:
> > IFF you can find a fix in the Java code. Because of the way UEL > interprets things I don't think that will be possible. > > Like I explained IGNORING the error doesn't make it go away, it just > causes a bigger problem by hiding the problem. If there is a general way > to actually handle this, ie fix the problems and not just ignore the > errors, then let's do it by all means. > > However, with UEL we're introducing new syntax rules and things like > this are likely to come up. In this case, there is NO way for the parser > to know that the "-" is part of the ID and not an arithmetic operator > without using a different syntax, as is done in this commit. Well, if we > could tell the parser "no arithmetic" for these sorts of expressions > then we might be able to fix it in Java, but otherwise based on my > experience with parsers and general parsing concepts, then there's no > way to avoid these kinds of changes. Like what happens when other characters are used, '*', '/', or, even, a '.' or ' '. |
By the way, I'm still working on this. I hope to have something
committed by the end of Wednesday. -Adrian Adam Heath wrote: > David E Jones wrote: >> IFF you can find a fix in the Java code. Because of the way UEL >> interprets things I don't think that will be possible. >> >> Like I explained IGNORING the error doesn't make it go away, it just >> causes a bigger problem by hiding the problem. If there is a general way >> to actually handle this, ie fix the problems and not just ignore the >> errors, then let's do it by all means. >> >> However, with UEL we're introducing new syntax rules and things like >> this are likely to come up. In this case, there is NO way for the parser >> to know that the "-" is part of the ID and not an arithmetic operator >> without using a different syntax, as is done in this commit. Well, if we >> could tell the parser "no arithmetic" for these sorts of expressions >> then we might be able to fix it in Java, but otherwise based on my >> experience with parsers and general parsing concepts, then there's no >> way to avoid these kinds of changes. > > Like what happens when other characters are used, '*', '/', or, even, a > '.' or ' '. > |
Free forum by Nabble | Edit this page |