Discussion: UEL and backward incompatibility
Locked
Discussion: UEL and backward incompatibility
 
|
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 |
Re: Discussion: UEL and backward incompatibility
|
|
Thanks for writing about this Adrian. I played with this a bit yesterday after seeing your messages and the issue about the income statement. The main point that I think is important is that it is a WAY better approach to use the natural data instead of trying to prefix it, as that is pretty error prone since ALL code (even outside of simple- methods for some code) has to be changed. So anyway, trying to use a UEL syntax that supports this with things like: theMap["${foo.bar}"] does work well for reading no matter what "foo.bar" evaluates to (even a number), but like you said for the auto- vivify o the Map the square-brace ([]) syntax means a list and so a List is created instead of a Map. The funny thing about the above is that even if you put a number in quotes it evaluates to a number and not a String, and that causes the auto-vivify to create a list instead of a Map for the square braces ([]). If we could do something about that it would be nice. Another thing I'm considering is: let's just have the *Entity Engine* prefix all generated keys so things in the database and other places have a character first letter. That's easy to do with a single attribute on the delegator element in the entityengine.xml file. Along with that we'd have to change the current demo data to do this as well. It would still be nice to do something more about the Map auto-vivify issue as it is much cleaner to treat things like data instead of like a variable name. What I propose above is just a work-around, and not the best option IMO... requiring identifiers to not be a number is a bit of a bad thing... -David On Apr 14, 2009, at 12:38 PM, 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 |
Re: Discussion: UEL and backward incompatibility
|
|
David,
Thanks for the reply! I don't like the prefixing either, that's why I suggested the new attribute values. To me, that makes the OFBiz scripting more like other script engines - you can't use a variable unless it is declared. One clarification that needs to be made though, in UEL the [] and . operators don't determine whether the referenced object is a List or a Map. UEL expressions can use ${object.property} or ${object[property]} - there are no rules on the object's data type. The object data type could be a List, a Map, or an arbitrary Object. The property could be a List index, a Map key, or an Object method name. In UEL, the object's data type determines how the property is used. I'll continue to tinker with the auto-vivify code and see if I can come up with a better solution. In the meantime, I'd still like to get comments on the new attribute values. -Adrian David E Jones wrote: > > Thanks for writing about this Adrian. I played with this a bit yesterday > after seeing your messages and the issue about the income statement. > > The main point that I think is important is that it is a WAY better > approach to use the natural data instead of trying to prefix it, as that > is pretty error prone since ALL code (even outside of simple-methods for > some code) has to be changed. > > So anyway, trying to use a UEL syntax that supports this with things > like: theMap["${foo.bar}"] does work well for reading no matter what > "foo.bar" evaluates to (even a number), but like you said for the > auto-vivify o the Map the square-brace ([]) syntax means a list and so a > List is created instead of a Map. > > The funny thing about the above is that even if you put a number in > quotes it evaluates to a number and not a String, and that causes the > auto-vivify to create a list instead of a Map for the square braces > ([]). If we could do something about that it would be nice. > > Another thing I'm considering is: let's just have the *Entity Engine* > prefix all generated keys so things in the database and other places > have a character first letter. That's easy to do with a single attribute > on the delegator element in the entityengine.xml file. Along with that > we'd have to change the current demo data to do this as well. > > It would still be nice to do something more about the Map auto-vivify > issue as it is much cleaner to treat things like data instead of like a > variable name. What I propose above is just a work-around, and not the > best option IMO... requiring identifiers to not be a number is a bit of > a bad thing... > > -David > > > On Apr 14, 2009, at 12:38 PM, 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 > > |
Re: Discussion: UEL and backward incompatibility
|
|
Avoiding declaration of variables was actually one of the goals of the simple-methods, just like it is for most "scripting" languages (as opposed to compiled languages). I have no problem with the proposed attribute/etc, but it would be nice to find a less cumbersome alternative... :) -David On Apr 14, 2009, at 3:19 PM, Adrian Crum wrote: > David, > > Thanks for the reply! > > I don't like the prefixing either, that's why I suggested the new > attribute values. To me, that makes the OFBiz scripting more like > other script engines - you can't use a variable unless it is declared. > > One clarification that needs to be made though, in UEL the [] and . > operators don't determine whether the referenced object is a List or > a Map. UEL expressions can use ${object.property} or $ > {object[property]} - there are no rules on the object's data type. > The object data type could be a List, a Map, or an arbitrary Object. > The property could be a List index, a Map key, or an Object method > name. In UEL, the object's data type determines how the property is > used. > > I'll continue to tinker with the auto-vivify code and see if I can > come up with a better solution. In the meantime, I'd still like to > get comments on the new attribute values. > > -Adrian > > > David E Jones wrote: >> Thanks for writing about this Adrian. I played with this a bit >> yesterday after seeing your messages and the issue about the income >> statement. >> The main point that I think is important is that it is a WAY better >> approach to use the natural data instead of trying to prefix it, as >> that is pretty error prone since ALL code (even outside of simple- >> methods for some code) has to be changed. >> So anyway, trying to use a UEL syntax that supports this with >> things like: theMap["${foo.bar}"] does work well for reading no >> matter what "foo.bar" evaluates to (even a number), but like you >> said for the auto-vivify o the Map the square-brace ([]) syntax >> means a list and so a List is created instead of a Map. >> The funny thing about the above is that even if you put a number in >> quotes it evaluates to a number and not a String, and that causes >> the auto-vivify to create a list instead of a Map for the square >> braces ([]). If we could do something about that it would be nice. >> Another thing I'm considering is: let's just have the *Entity >> Engine* prefix all generated keys so things in the database and >> other places have a character first letter. That's easy to do with >> a single attribute on the delegator element in the entityengine.xml >> file. Along with that we'd have to change the current demo data to >> do this as well. >> It would still be nice to do something more about the Map auto- >> vivify issue as it is much cleaner to treat things like data >> instead of like a variable name. What I propose above is just a >> work-around, and not the best option IMO... requiring identifiers >> to not be a number is a bit of a bad thing... >> -David >> On Apr 14, 2009, at 12:38 PM, 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 |
Re: Discussion: UEL and backward incompatibility
|
|
Let's see if revision 764992 solves the problem.
-Adrian David E Jones wrote: > > Avoiding declaration of variables was actually one of the goals of the > simple-methods, just like it is for most "scripting" languages (as > opposed to compiled languages). > > I have no problem with the proposed attribute/etc, but it would be nice > to find a less cumbersome alternative... :) > > -David > > > On Apr 14, 2009, at 3:19 PM, Adrian Crum wrote: > >> David, >> >> Thanks for the reply! >> >> I don't like the prefixing either, that's why I suggested the new >> attribute values. To me, that makes the OFBiz scripting more like >> other script engines - you can't use a variable unless it is declared. >> >> One clarification that needs to be made though, in UEL the [] and . >> operators don't determine whether the referenced object is a List or a >> Map. UEL expressions can use ${object.property} or ${object[property]} >> - there are no rules on the object's data type. The object data type >> could be a List, a Map, or an arbitrary Object. The property could be >> a List index, a Map key, or an Object method name. In UEL, the >> object's data type determines how the property is used. >> >> I'll continue to tinker with the auto-vivify code and see if I can >> come up with a better solution. In the meantime, I'd still like to get >> comments on the new attribute values. >> >> -Adrian >> >> >> David E Jones wrote: >>> Thanks for writing about this Adrian. I played with this a bit >>> yesterday after seeing your messages and the issue about the income >>> statement. >>> The main point that I think is important is that it is a WAY better >>> approach to use the natural data instead of trying to prefix it, as >>> that is pretty error prone since ALL code (even outside of >>> simple-methods for some code) has to be changed. >>> So anyway, trying to use a UEL syntax that supports this with things >>> like: theMap["${foo.bar}"] does work well for reading no matter what >>> "foo.bar" evaluates to (even a number), but like you said for the >>> auto-vivify o the Map the square-brace ([]) syntax means a list and >>> so a List is created instead of a Map. >>> The funny thing about the above is that even if you put a number in >>> quotes it evaluates to a number and not a String, and that causes the >>> auto-vivify to create a list instead of a Map for the square braces >>> ([]). If we could do something about that it would be nice. >>> Another thing I'm considering is: let's just have the *Entity Engine* >>> prefix all generated keys so things in the database and other places >>> have a character first letter. That's easy to do with a single >>> attribute on the delegator element in the entityengine.xml file. >>> Along with that we'd have to change the current demo data to do this >>> as well. >>> It would still be nice to do something more about the Map auto-vivify >>> issue as it is much cleaner to treat things like data instead of like >>> a variable name. What I propose above is just a work-around, and not >>> the best option IMO... requiring identifiers to not be a number is a >>> bit of a bad thing... >>> -David >>> On Apr 14, 2009, at 12:38 PM, 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 > > |
Re: Discussion: UEL and backward incompatibility
|
|
In reply to this post by Adrian Crum
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 On 15/04/2009, at 6:38 AM, Adrian Crum wrote:
|
smime.p7s (3K)
Re: Discussion: UEL and backward incompatibility
|
|
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 <[hidden email]> wrote: > From: Scott Gray <[hidden email]> > Subject: Re: Discussion: UEL and backward incompatibility > To: [hidden email] > 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 |
Re: Discussion: UEL and backward incompatibility
|
|
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 On 15/04/2009, at 1:01 PM, Adrian Crum wrote:
|
Re: Discussion: UEL and backward incompatibility
|
|
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 <[hidden email]> wrote: > From: Scott Gray <[hidden email]> > Subject: Re: Discussion: UEL and backward incompatibility > To: [hidden email] > 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 > <[hidden email]> wrote: > > > >> From: Scott Gray > <[hidden email]> > >> Subject: Re: Discussion: UEL and backward > incompatibility > >> To: [hidden email] > >> 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 > > > > > > |
|
|
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 <[hidden email]> 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 <[hidden email]> wrote: > > > From: Scott Gray <[hidden email]> > > Subject: Re: Discussion: UEL and backward incompatibility > > To: [hidden email] > > 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 > > <[hidden email]> wrote: > > > > > >> From: Scott Gray > > <[hidden email]> > > >> Subject: Re: Discussion: UEL and backward > > incompatibility > > >> To: [hidden email] > > >> 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 > > > > > > > > > > > > > |
Re: Discussion: UEL and backward incompatibility
|
|
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 <[hidden email]> wrote: > From: Al Byers <[hidden email]> > Subject: Re: Discussion: UEL and backward incompatibility > To: [hidden email], [hidden email] > 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 > <[hidden email]> 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 > <[hidden email]> wrote: > > > > > From: Scott Gray > <[hidden email]> > > > Subject: Re: Discussion: UEL and backward > incompatibility > > > To: [hidden email] > > > 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 > > > <[hidden email]> wrote: > > > > > > > >> From: Scott Gray > > > <[hidden email]> > > > >> Subject: Re: Discussion: UEL and > backward > > > incompatibility > > > >> To: [hidden email] > > > >> 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 > > > > > > > > > > > > > > > > > > > > |
Re: Discussion: UEL and backward incompatibility
|
|
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 <[hidden email]> wrote: > >> From: Al Byers <[hidden email]> >> Subject: Re: Discussion: UEL and backward incompatibility >> To: [hidden email], [hidden email] >> 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 >> <[hidden email]> 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 >> <[hidden email]> wrote: >>> >>>> From: Scott Gray >> <[hidden email]> >>>> Subject: Re: Discussion: UEL and backward >> incompatibility >>>> To: [hidden email] >>>> 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 >>>> <[hidden email]> wrote: >>>>> >>>>>> From: Scott Gray >>>> <[hidden email]> >>>>>> Subject: Re: Discussion: UEL and >> backward >>>> incompatibility >>>>>> To: [hidden email] >>>>>> 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 >>>>> >>>>> >>>>> >>> >>> >>> >>> > > > |
Re: Discussion: UEL and backward incompatibility
|
|
Cool. Thanks! I'll work on that. -Adrian --- On Tue, 4/14/09, David E Jones <[hidden email]> wrote: > From: David E Jones <[hidden email]> > Subject: Re: Discussion: UEL and backward incompatibility > To: [hidden email] > 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 > <[hidden email]> wrote: > > > >> From: Al Byers <[hidden email]> > >> Subject: Re: Discussion: UEL and backward > incompatibility > >> To: [hidden email], [hidden email] > >> 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 > >> <[hidden email]> 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 > >> <[hidden email]> wrote: > >>> > >>>> From: Scott Gray > >> <[hidden email]> > >>>> Subject: Re: Discussion: UEL and backward > >> incompatibility > >>>> To: [hidden email] > >>>> 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 > >>>> <[hidden email]> wrote: > >>>>> > >>>>>> From: Scott Gray > >>>> <[hidden email]> > >>>>>> Subject: Re: Discussion: UEL and > >> backward > >>>> incompatibility > >>>>>> To: [hidden email] > >>>>>> 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 > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > >>> > > > > > > |
Re: Discussion: UEL and backward incompatibility
Administrator
|
In reply to this post by David E Jones-3
Yes +1
Jacques From: "David E Jones" <[hidden email]> > 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 <[hidden email]> wrote: >> >>> From: Al Byers <[hidden email]> >>> Subject: Re: Discussion: UEL and backward incompatibility >>> To: [hidden email], [hidden email] >>> 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 >>> <[hidden email]> 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 >>> <[hidden email]> wrote: >>>> >>>>> From: Scott Gray >>> <[hidden email]> >>>>> Subject: Re: Discussion: UEL and backward >>> incompatibility >>>>> To: [hidden email] >>>>> 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 >>>>> <[hidden email]> wrote: >>>>>> >>>>>>> From: Scott Gray >>>>> <[hidden email]> >>>>>>> Subject: Re: Discussion: UEL and >>> backward >>>>> incompatibility >>>>>>> To: [hidden email] >>>>>>> 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 >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >> >> >> > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |