If you are trying to save syntax, the quotes on the keys are optional, and if
you want code you can surround in parens:
//This can be defined in your base class, as a global, whatever so it’s not in
your fixture DSL
int c = 0
def closureKey = {“_CLOSURE_$c”}
def fixture = {
field1: “value1”,
field2: “value2”,
(closureKey()): {$(‘a.button’).click()},
field3: “value3”,
(closureKey()): {…}
}
Another option is to use the Groovy call syntax, where all “named” parameters
turn into a map, and all the rest are in a list (although order is not
preserved). The resulting DSL would look like this:
Fixture(
field1: “value1”,
field2: “value2”,
{$(‘a.button’).click()},
field3: “value3”,
{ … }
)
The Fixture method would have this signature:
def Fixture(Map fields, List closures)
The drawback is that the relative order between the “fields” and closures is
not preserved.
Jason
From: Jeff Lowery [mailto:jef...@mavericklabel.com]
Sent: Thursday, July 23, 2015 1:32 PM
To: users@groovy.incubator.apache.org
Subject: Re: Auto-generating a map key
This is sort of a unique situation, where I’m setting up test fixtures and
trying to minimize the punctuation. The fixture is iterated through, and in
general the key is the name of a form field and the value is the value the
field is set to.
The problem is most, but not all, cases fit that pattern. Some times I have a
button to click, or a mouse hover action to perform.
So a fixture looks like:
def fixture = {
“field1”: “value1”,
“field2”: “value2”,
“_CLOSURE_0”: {$(‘a.button’).click()},
“field3”: “value3”,
“_CLOSURE_1”: {…}
}
So the two points you make about GStrings (which I appreciate), don’t apply
here. The “_CLOSURE_${c++}” GString is just a way to uniquify the closure keys
automatically.
It is a bit ugly, but it is also concise (it is essentially a script that is
run through an interpreter). Could a different data structure do the trick?
Sure:
def fixture = [
[“field1”, “value1”],
[“field2”, “value2”],
[{$(‘a.button’).click()}],
…
];
Just a little too brackety in my opinion, but it does dispense with the ugly
“_CLOSURE_${c++}” naming.
What I was hoping for was a generator-like function that I could use in place
of the “_CLOSURE_${c++}”, but Groovy doesn’t seem to allow method execution
when defining a map key (though GStrings come close).
— Jeff
On Jul 22, 2015, at 10:49 PM, Jochen Theodorou
<blackd...@gmx.org<mailto:blackd...@gmx.org>> wrote:
Am 23.07.2015 00:39, schrieb Lowery, Jeff:
Trying to find the simplest way to auto generate a map key; the best
I've come up with is:
def c=0
def map = {
"_KEY$c++" : "foo", "_KEY$c++": "bar", ... }
First of all: You shall not use GString as map key.
a) GString is a mutable, using mutables as map keys can lead to very
interesting behaviour of the map
b) GString is not having the same hashcode as String even if the toString()
representation is the same.
Factor (a) is probably not a problem here, but (b) can easily cause a problem.
Is there better?
you are not really giving enough information. For example, why not simply use a
list here? The key seems not to play an important role, thus I doubt that
searching is the problem you try to solve with the map. But then it is
questionable if a map is even the right datastructure for your problem.
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
----------------------------------------------------------------------
This email message and any attachments are for the sole use of the intended
recipient(s). Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message and any attachments.
