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"
Hi,
changing a method call from ellipsis s
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 t
I had 2 values
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
No matter how many times I read what you've written below I can't understand
what issue you ran into?
You had:
delegator.findOne("Entity", true, "field1", value1);
and you tried to change it to:
delegator.findOne("Entity", true, UtilMisc.toMap("field1", value1));
?
That should still work since f
Hi,
> I suggest to refactor findOne signatures. Or actually only the signature
> w/out ellipsis. When we
> introduced the signature with elilpsis the cache argument was inevitably in
> the middle. We kept the
> signature for the other method. I was caught recently by changing a method
> call fr
Hi,
I suggest to refactor findOne signatures. Or actually only the signature w/out ellipsis. When we introduced the signature with
elilpsis the cache argument was inevitably in the middle. We kept the signature for the other method. I was caught recently by
changing a method call from ellipsis
