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
