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
