on_string seems to be defined for datatool parameters only.

There's a common idiom for looking up fields from the relevant .loc
files for things like all_fasta - it's not pretty but it does work -
eg from the bowtie wrapper:

 --ref="${ filter( lambda x: str( x[0] ) == str(
$refGenomeSource.index ), $__app__.tool_data_tables[ 'bowtie_indexes'
].get_fields() )[0][-1] }"

As you can see, it will pass the last column from the relevant row of
the loc file pointed at by the tool_data_table.xml entry for
bowtie_indexes_color
To get a name instead of a path, you could replace the column selector
with (eg) 2 if that's the column you want from the .loc file?

It's complex but do-able - I hope this helps...

On Fri, Sep 16, 2011 at 1:19 PM, Florent Angly <florent.an...@gmail.com> wrote:
>
> While ${on_string} works well for items in the history, I found that for a
> dataset in a data table, for example in the 'all_fasta' table, the content
> of ${on_string} is the null string.
> Is that expected? Is there a better to get the name or some sort of
> identifier of the dataset?
> Thank you,
> Florent
>
>
> On 02/09/11 08:52, Dave Walton wrote:
>>
>> This is a big part of the reason we did this.
>>
>> I will push it out for the galaxy team to look at.  If for some reason the
>> don't approve it I can share our change directly with you.
>>
>> Dave
>>
>> On Sep 1, 2011, at 6:39 PM, "Ross"<ross.laza...@gmail.com>  wrote:
>>
>>> FWIW: This sounds like a useful idea to me.
>>>
>>> My users are struggling with output names currently being generated by
>>> complex workflows where many tools do something like
>>> label="${tool.name} on ${on_string}: reordered ${outputFormat}" - that
>>> might be ok for a single step but after traveling through a few of
>>> those, the base name (which we routinely use for metadata needed at
>>> some final amalgamation step, such as experimental condition) is hard
>>> to find in all the cruft.
>>>
>>>
>>>
>>> On Thu, Sep 1, 2011 at 11:16 PM, Dave Walton<dave.wal...@jax.org>  wrote:
>>>>
>>>> This is similar to something we've done for workflows in our instance of
>>>> Galaxy.  Dannon actually suggested I push a copy of my changes out so he
>>>> can
>>>> review them and potentially add them to galaxy central.  I've been
>>>> delinquent in doing this push.  It's not exactly what you are talking
>>>> about
>>>> but similar (IMHO)...  If folks are interested in this functionality
>>>> I'll
>>>> get off my butt and make the time to share the changes.
>>>>
>>>> In brief, here's what I did:
>>>>
>>>> The change is totally isolated to lib/galaxy/jobs/actions/post.py in the
>>>> RenameDatasetAction.execute method.
>>>>
>>>> I have introduced syntax similar to the ${variable} syntax that is used
>>>> for
>>>> creating workflow variables.
>>>>
>>>> In my case the syntax is as follows:
>>>> #{inputs_file_variable | option 1 | option n}
>>>> where:
>>>>     input_file_variable = is the name of a module input variable
>>>>     |  = the delimiter for added options. Optional if no options.
>>>>     options = basename, upper, lower
>>>>     basename = keep all of the file name except the extension
>>>>                (everything before the final ".")
>>>>     upper = force the file name to upper case
>>>>     lower = force the file name to lower case
>>>>  suggested additions:
>>>>     "replace" option so you can replace a portion of the name,
>>>>     support multiple #{name} in one rename action...
>>>>
>>>> The choice of the character "#" instead of "$" was relatively
>>>> arbitrary...
>>>> It was that or "!" actually.
>>>>
>>>> So an example might be:
>>>> I have a workflow with an Input Dataset and a FASTQ Groomer.
>>>> In the FASTQ Groomer I select "Rename Dataset" "output_file" and then in
>>>> the
>>>> "New output name:" field I might type:
>>>> #{input_file | basename | upper}.fastqsanger
>>>>
>>>> Assume the original input file name to the Input Dataset was
>>>> s_1_1_PWDxNOD.txt
>>>> The variable in the FastQ Groomer module for that file is "input_file".
>>>> When I run the workflow, the resulting output file from the groomer
>>>> would be
>>>> "S_1_1_PWDXNOD.fastqsanger"
>>>>
>>>> A much simpler example might just be "#{input_file}.fastqsanger".  This
>>>> is
>>>> perfectly legal syntax, but the downside is if you have a lengthy
>>>> workflow
>>>> and you are continually appending new extentions, you could end up with
>>>> something like "s_1_1_PWDxNOD.fastqsanger.bam.gex.tab".
>>>>
>>>> Like the first of the two suggested additions I mention above, I could
>>>> see
>>>> you deciding to add more possible operations in addition to basename,
>>>> upper,
>>>> lower and replace.
>>>>
>>>> The concept of the markup I used for adding the operations was taken
>>>> from
>>>> "Liquid markup"
>>>> (https://github.com/tobi/liquid/wiki/liquid-for-designers).
>>>>
>>>> I welcome any feedback and am more than happy to share the code back to
>>>> the
>>>> galaxy community.
>>>>
>>>> Dave
>>>>
>>>> On 8/29/11 6:20 PM, "Ross"<ross.laza...@gmail.com>  wrote:
>>>>
>>>>> Most times I need a user supplied label substring. I'm not sure how
>>>>> else to conditionally set a string to a predetermined value other than
>>>>> with boolean true/false strings or select parameter values.
>>>>>
>>>>> One even more ugly option is to use a (strictly speaking now
>>>>> deprecated) post job exec hook to change the output dataset name based
>>>>> on some logic - but if the boolean works, I'd recommend moving on :)
>>>>>
>>>>> On Tue, Aug 30, 2011 at 7:56 AM, Nikhil Joshi<najo...@ucdavis.edu>
>>>>>  wrote:
>>>>>>
>>>>>> Hi Ross,
>>>>>>
>>>>>> Yes, I did try that... but what I want is string parameter that
>>>>>> changes
>>>>>> based on whether or not you've checked a checkbox (or a way to change
>>>>>> the
>>>>>> label of the output based on whether or not the checkbox was checked).
>>>>>>  So
>>>>>> my idea below did work, but it seems like a hack.  Which is why I was
>>>>>> wondering if there was a better way.
>>>>>>
>>>>>> - Nik.
>>>>>>
>>>>>> On Mon, Aug 29, 2011 at 2:55 AM, Ross<ross.laza...@gmail.com>  wrote:
>>>>>>>>>
>>>>>>>>> On Thu, Aug 25, 2011 at 6:34 AM, SHAUN
>>>>>>>>> WEBB<swe...@staffmail.ed.ac.uk>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> I meant to say label="${input}" or label="${input.value}.
>>>>>>>>>>
>>>>>>> Nikhil, did you try as Shaun and others have suggested? Any available
>>>>>>> string parameter can be used in a label as far as I can tell.
>>>>>>>
>>>>>>> This is a common idiom - ask for a string ('title') to describe the
>>>>>>> job/output for posterity, then in an output:
>>>>>>>
>>>>>>> <data format="foo" name="output1" metadata_source="input1"
>>>>>>> label="${title}.myext"/>
>>>>>>>
>>>>>>> There's even a built in ${on_string} if you just want the file name
>>>>>>> plus some history ids?
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Aug 29, 2011 at 6:54 PM, Nikhil Joshi<najo...@ucdavis.edu>
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> It looks like the Cheetah syntax only is parsed within the<command>
>>>>>>>> tags.... so I figured out a way to do it... but it seems hackish.  I
>>>>>>>> basically changed the string values of truevalue and falsevalue
>>>>>>>> within
>>>>>>>> the
>>>>>>>> parameter to be an English sentence that would become the label for
>>>>>>>> the
>>>>>>>> output.  I.e., in the input section:
>>>>>>>>
>>>>>>>> <param name="filter_reads" type="boolean" truevalue="Filtered Reads
>>>>>>>> Fasta"
>>>>>>>> falsevalue="Unfiltered Reads Fasta" label="Filter reads?"/>
>>>>>>>>
>>>>>>>> and in the output section:
>>>>>>>>
>>>>>>>> <data format="fasta" name="output_fasta" label="$filter_reads"/>
>>>>>>>>
>>>>>>>> This seems wrong to do, but it does work.  If anyone has a better
>>>>>>>> method,
>>>>>>>> please let me know!
>>>>>>>>
>>>>>>>> - Nik.
>>>>>>>>
>>>>>>>> On Thu, Aug 25, 2011 at 2:36 PM, Nikhil Joshi<najo...@ucdavis.edu>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> It's actually a boolean checkbox..... so I basically want the label
>>>>>>>>> to
>>>>>>>>> change based upon whether or not the checkbox is checked.  Is there
>>>>>>>>> any
>>>>>>>>> way
>>>>>>>>> to do that?  Again, I've tried using the Cheetah syntax to do the
>>>>>>>>> #if
>>>>>>>>> #end
>>>>>>>>> inside the<output>  tags.... but that didn't work.
>>>>>>>>>
>>>>>>>>> - Nik.
>>>>>>>>>
>>>>>>>>> On Thu, Aug 25, 2011 at 6:34 AM, SHAUN
>>>>>>>>> WEBB<swe...@staffmail.ed.ac.uk>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> I meant to say label="${input}" or label="${input.value}.
>>>>>>>>>>
>>>>>>>>>> If it's a select field then you can change the option values to
>>>>>>>>>> the
>>>>>>>>>> text
>>>>>>>>>> you want to add to your output label.
>>>>>>>>>>
>>>>>>>>>> Shaun
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Quoting Kanwei Li<kan...@gmail.com>  on Wed, 24 Aug 2011 20:34:57
>>>>>>>>>> -0400:
>>>>>>>>>>
>>>>>>>>>>> Hi Nikhil,
>>>>>>>>>>>
>>>>>>>>>>> The tool templates are Cheetah templates, so you can do things
>>>>>>>>>>> like:
>>>>>>>>>>>
>>>>>>>>>>> <outputs>
>>>>>>>>>>> %if param == True:
>>>>>>>>>>>   <data format="txt" name="blah" label="Label1" />
>>>>>>>>>>> %else
>>>>>>>>>>>  <data format="txt" name="blah" label="Label2" />
>>>>>>>>>>> %endif
>>>>>>>>>>> </outputs>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> K
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Aug 24, 2011 at 8:24 PM, Nikhil
>>>>>>>>>>> Joshi<najo...@ucdavis.edu>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> Is there a way to set the label of the output based on the input
>>>>>>>>>>>> parameters?  Perhaps by using the<action>  tag?  Basically, I
>>>>>>>>>>>> want
>>>>>>>>>>>> the
>>>>>>>>>>>> output label to be different if the user sets a particular
>>>>>>>>>>>> parameter
>>>>>>>>>>>> to
>>>>>>>>>>>> be
>>>>>>>>>>>> true.
>>
>> ___________________________________________________________
>> Please keep all replies on the list by using "reply all"
>> in your mail client.  To manage your subscriptions to this
>> and other Galaxy lists, please use the interface at:
>>
>>   http://lists.bx.psu.edu/
>
> ___________________________________________________________
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>
>  http://lists.bx.psu.edu/
>



-- 
Ross Lazarus MBBS MPH;
Associate Professor, Harvard Medical School;
Director of Bioinformatics, Channing Lab; Tel: +1 617 505 4850;
Head, Medical Bioinformatics, BakerIDI; Tel: +61 385321444;

___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Reply via email to