note
tospo
not really. The crucial point is that the entire content of that csv file can be auto-generated in a few linew unless I'm missing something important here.<br/>
Take this as a simple example:
<code>
my @combinations = ( "1,1","1,2","2,1","2,2")
</code>
vs.
<code>
my @combinations;
for my $i (1..2){
for my $j (1..2) {
push @combinations, "$i,$j";
}
}
</code>
I'm generating an array in this case with strings that are combinations of elements, in this case simply the number 1 and 2 but you can easily substitute that with "THIS", "THAT" and "This Evaluation", "That Evalutation" etc, which is what you have (if I remember your other thread correctly).<br/>
In the first example, I harcode the array by typing all the combinations in my script. I could also save them to a file in csv format, as dump of the array (using Data::Dumper), or whatever format you can think of - the problem remains: I'm hardcoding all possible but entirely predictabe and therefore scriptable combinations of elements.<br/>
In the second example, I generate all possible combinations on the fly. Again, if I remember correctly, you only need to do that to generate a file name. For that reason you don't even need to save the data to an array or a hash - you just generate the string as a combination of all the elements and then use that to open your file - job done.<br/>
Of course, in my simple example, the second version is longer than the first, but you can easily see how that changes quickly with more elements and more combinations.<br/>
So, if the data can be generated on the fly, do it - that's the whole point of scripting. If not, i.e. sometimes you want the scale for a "THIS" plot to be "0:" and sometimes ":100" and tehre is no way to predict it, then you have to resort to a config file (for which you can use a number of options, such as YAML or simple config format - have a look around on the CPAN).<br/>
Hope this helps.
931485
931540