pmr at ebi.ac.uk
Wed May 11 14:45:48 UTC 2005
José R. Valverde wrote:
> The idea I come up with is a 'dynlist' datatype: it would work
> much like a list, but would obtain the choices from a directory listing
> somewhere or from a file. This way, one would define e.g.
> dynlist: params [
> required: Y
> min: 1
> max: 1
> header: "Select Force Field"
> values: "/somewhere/params/*.prm"
> showpath: Y
> info: "Force Field parameters to use in the computation"
> values: "@/somewhere/params/FILE"
> to use the contents of FILE as the options listing...
> Then, on running the user would get a listing of options, possibly stripped
> of the path (e.g. with basename(3)) and choose whichever he wanted. ACD would
> return the selection to the program (possibly with the pathname stripped if
> so requested).
> This is akin to GUI OpenFile routines which list a series of files and let
> the user choose, hence it may have more applications than suggested. But,
> at any rate, it simplifies handling of these kind of datafiles that may
> experience high variation.
> Alternately, it might be nice to have a way to plug-in to emboss.defaults,
> allowing programmers to retrieve preferences/option lists from it. But this
> I find more problematic.
This is very similar to the proposal I posted recently for codon usage files
and genetic codes. We can add "resource" definitions to emboss.defaults and/or
use some expression as the values field for a list or selection ACD type -
it may not even need a new ACD dynlist type.
The showpath attribute would be tricky - that is pathname specific, so would
be better encoded as part of the values string.
I would be very interested in any other suggestions and use cases.
More information about the emboss-dev