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
