Cool. Thanks! I'll work on that.
-Adrian --- On Tue, 4/14/09, David E Jones <david.jo...@hotwaxmedia.com> wrote: > From: David E Jones <david.jo...@hotwaxmedia.com> > Subject: Re: Discussion: UEL and backward incompatibility > To: dev@ofbiz.apache.org > Date: Tuesday, April 14, 2009, 11:03 PM > I think adding those data types would be fine Adrian, and > would solve > what Al brings up (and it is nice to be able to return an > empty List/ > etc sometimes). > > Now that we have an alternative way to do this it is nice > and we don't > have to use it, but I agree it's a nice option. > > -David > > > On Apr 14, 2009, at 11:40 PM, Adrian Crum wrote: > > > > > 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 > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > >>> > > > > > >
