Right, it was another (logical) issue in code. I mixed up both when it was actually obvious that a map was rendered by
UtilMisc.toMap("field1", value1) hence no issues :/
Thanks for your help (both Scott and you)
Jacques
From: "Martin Kreidenweis" <martin.kreidenw...@tngtech.com>
Hi,
changing a method call from ellipsis signature to the other. I introduced
UtilMisc.toMap for the
last argument because I had 2
values and changed for one only, hence ellipsis could not be used. I did that
in a hurry, not
thinking about the argument swap.
Let me try to explain from your example:
delegator.findOne("Entity", true, "field1", value1, "field2", value2);
and tried to change it to:
delegator.findOne("Entity", true, UtilMisc.toMap("field1", value1));
Now that Scott has told us that UtilMisc.toMap() supports the case where there
is only one param and
it already is a map, I don't see any reason to change the signature.
I just tried it out. All three those lines found the right entity for me:
delegator.findOne("Product", true, "productId", testProductId);
delegator.findOne("Product", UtilMisc.toMap("productId", testProductId), true);
delegator.findOne("Product", true, UtilMisc.toMap("productId", testProductId));
I'm against changing the signature. I like the decreasing importance structure
of the parameters
(what-which-how/entityname-conditions-useCache) the find* methods have. And we
would have quite some
code to migrate.
BTW, we usually would write the statement in Groovy like that:
delegator.findOne("Product", [productId: testProductId], true)
We changed the ant tasks so we can use Groovy also for the compiled code --
service and event
classes -- not only for action scripts. Maybe this is something the OFBiz
project wants to consider.
I think it makes most of the code easier to write and read.
A disadvantage is, that the compile times are significantly higher. But it
isn't often that one
needs to do a clean build. :-)
Martin
