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
