Hi Peter,
I have to say the proposed way to get at the path from within the wrapper XML file looks very nasty. Is this a short term solution?
Yes, that is very nasty and a bad stop-gap solution that needs to not propogate. Data tables are pretty new and need lots of enhancement, something along the lines of what you expected (e.g. $param.path) is the intention. Any other data table suggestions? Thanks, Dan
On Thu, Nov 18, 2010 at 6:09 PM, Peter <peter@maubp.freeserve.co.uk> wrote:
On Thu, Nov 18, 2010 at 5:57 PM, Kelly Vincent <kpvincent@bx.psu.edu> wrote:
This changeset undoes part of the change to data tables in my commit, which was not an accident. ...
I didn't think it was an accident, but it had broken the BLAST+ wrappers.
Data tables is far more flexible than the raw loc approach, which is why we changed it. The unique ID is necessary for the data tables approach and allows for the structure of the loc file and/or data location to change without breaking things. The former approach was to store the path as the value for the parameter. This means that if it was set in a workflow and if that path changed (i.e. the data directory was restructured), the workflow would no longer work. However, if we use the unique ID, it's possible to maintain backwards compatibility. Instead of the path, it stores the unique ID, which can be used to obtain the path so that it can be passed to the Python file. And for items that were already in the loc file, you set the unique ID to be the same as the original path, so that the parameter values in existing workflows is still the same. But new items can have nicer-looking IDs. And if extra columns ever need to be added, it's easy. Ever since James' original data tables commit (in August), we have been wanting to change everything over to this style, so I am going to change these files back.
...
I'm working on a wiki page that will explain data tables, since they're pretty much undocumented at this point.
I see - that was my guess for what the new ID was for, but the setup as you'd left it wasn't working for the BLAST+ wrappers.
The new blastdb.loc.sample and blastdb_p.loc.sample have three columns: identifier (to be stored in the database to record what the user picked), name (to be shown to the user in the drop down select box), and path (to be given to the BLAST executable).
...
Please go ahead and fix it - I'm about to go home for the day here.
I see you put some documentation on the wiki yesterday, http://bitbucket.org/galaxy/galaxy-central/wiki/DataTables
I was expecting we might have to use $param.path rather than $param in the cheetah template for the command line in the wrapper XML, or that it might happen automatically (i.e. some code takes care of things so that the database path would be provided to the cheetah template as $param, while the value column would be used to record the step in the history/workflow).
I have to say the proposed way to get at the path from within the wrapper XML file looks very nasty. Is this a short term solution?
Regards,
Peter _______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev