ACD suggestion

[Peter Rice]

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"
> ]
> 
> or 
> ...
> 	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.

regards,

Peter