If you read section 1.5 and 1.6 to get an idea of UEL syntax and evaluation:
http://docs.ofbiz.org/download/attachments/6430/UEL.pdf and understand that auto-vivify is an OFBiz add-on to UEL, then it should make more sense. I think I solved the problem with my recent commit. Let's see how it goes. -Adrian --- On Tue, 4/14/09, Scott Gray <scott.g...@hotwaxmedia.com> wrote: > From: Scott Gray <scott.g...@hotwaxmedia.com> > Subject: Re: Discussion: UEL and backward incompatibility > To: dev@ofbiz.apache.org > Date: Tuesday, April 14, 2009, 6:14 PM > Isn't someEntity.someId a String? > > For example orderHeader.orderId in java would be: > String orderId = (String) > orderHeader.get("orderId"); > > So my question is why does UEL evaluate orderId to an > Integer when the > actual type was a String? Or am I still missing something? > > Regards > Scott > > HotWax Media > http://www.hotwaxmedia.com > > On 15/04/2009, at 1:01 PM, Adrian Crum wrote: > > > > > Scott, > > > > You're missing something: The problem is with > using integers as Map > > keys, not Map values. > > > > -Adrian > > > > --- On Tue, 4/14/09, Scott Gray > <scott.g...@hotwaxmedia.com> wrote: > > > >> From: Scott Gray > <scott.g...@hotwaxmedia.com> > >> Subject: Re: Discussion: UEL and backward > incompatibility > >> To: dev@ofbiz.apache.org > >> Date: Tuesday, April 14, 2009, 5:22 PM > >> Sorry if I'm asking something obvious here and > keep in > >> mind I haven't really followed the UEL > introduction very > >> closely. > >> > >> You say below that these numeric Ids are evaluated > to > >> integers and my question is why exactly is that? > I'm > >> quite sure in 99% of cases the actual type of the > map entry > >> value is a String which just happens to contain > numbers. So > >> in my mind whatever code is retrieving a map > values using > >> dot syntax should preserve the type of the > original value. > >> Maps in OFBiz almost never require (or want) > automatic type > >> conversion of their values so is their any way to > turn that > >> off? > >> > >> Regards > >> Scott > >> > >> HotWax Media > >> http://www.hotwaxmedia.com > >> > >> > >> > >> On 15/04/2009, at 6:38 AM, Adrian Crum wrote: > >> > >>> As many of you know, the introduction of the > Uniform > >> Expression Language into the framework caused some > backward > >> compatibility problems - specifically with IDs > being used as > >> Map keys. I tried to accommodate that with a > couple of bits > >> of code, but there are still some issues. > >>> > >>> There have been suggestions on the mailing > list for > >> workarounds, but not all of them work, nor do they > work all > >> the time. I don't want to hack up the UEL > library > >> further, because its my viewpoint that OFBiz > should conform > >> to existing standards, not twist existing > standards to > >> conform to OFBiz. > >>> > >>> The crux of the main problem is the > implementation of > >> auto-vivify that I added to the UEL. Using the > following > >> code as an example: > >>> > >>> <set > field="someVar[someEntity.someId]" > >> value="Hello World!"/> > >>> > >>> If someVar was not previously defined, the > auto-vivify > >> code tries to guess what data type someVar is > supposed to > >> be. If someEntity.someId evaluates to an integer, > the code > >> assumes it is an index and creates a List, > otherwise it > >> creates a Map. This works fine in most cases. > >>> > >>> The problem comes when someEntity.someId > evaluates to > >> an integer (most IDs are integers) and the > developer > >> intended someVar to be a Map, not a List. There > needs to be > >> a way to create and empty Map in those cases. > >>> > >>> I believe the best solution is to modify the > >> <set> element to allow the creation of an > empty Map or > >> List. This will remove the ambiguity and solve the > problem - > >> without further modifying UEL. > >>> > >>> I modified my local copy to allow the creation > of an > >> empty Map: > >>> > >>> <set field="someVar" > >> type="NewMap"/> > >>> <set > field="someVar[someEntity.someId]" > >> value="Hello World!"/> > >>> > >>> and it works great. > >>> > >>> So, the bottom line is, I would like to add > >> "NewMap" and "NewList" to the > >> <set> element type attribute. What do you > think? > >>> > >>> -Adrian > > > > > >
