Maybe (outside the UEL issue) we could consider that. David said one of the goals in the OFBiz scripting was to avoid having to declare variables before using them. We could make it optional - you could declare variables if you want - to avoid data-type ambiguity. Otherwise, you could assign values to non-existing variables and let OFBiz try to infer the data type.
The <set> element data-typing I had proposed earlier could work in concert with my recent commit. -Adrian --- On Tue, 4/14/09, Al Byers <bye...@automationgroups.com> wrote: > From: Al Byers <bye...@automationgroups.com> > Subject: Re: Discussion: UEL and backward incompatibility > To: dev@ofbiz.apache.org, adrian.c...@yahoo.com > Date: Tuesday, April 14, 2009, 10:21 PM > 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 > > > > > > > > > > > > > > > > > > > >
