What is the reason there is not a method to create empty lists and maps in simple-methods? I have found a need to do such many times. I was welcoming Adrian's first proposed solution.
-Al On Tue, Apr 14, 2009 at 9:19 PM, Adrian Crum <adrian.c...@yahoo.com> wrote: > > 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 > > > > > > > > > > > > >
