Re: Discussion: UEL and backward incompatibility

[Scott Gray]

Isn't someEntity.someId a String?

For example orderHeader.orderId in java would be:
String orderId = (String) orderHeader.get("orderId");



Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 15/04/2009, at 1:01 PM, Adrian Crum wrote:

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?

Scott,



-Adrian

--- On Tue, 4/14/09, Scott Gray <scott.g...@hotwaxmedia.com> wrote:

You're missing something: The problem is with using integers as Map keys, not Map values.

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

smime.p7s
Description: S/MIME cryptographic signature