[GRASS-dev] Re: [GRASS GIS] #1031: More specific parameter information in command line help

[GRASS GIS]

#1031: More specific parameter information in command line help
--------------------------+-------------------------------------------------
  Reporter:  huhabla      |       Owner:  grass-dev at lists.osgeo.org
      Type:  enhancement  |      Status:  new                      
  Priority:  minor        |   Milestone:  7.0.0                    
 Component:  libgis       |     Version:  svn-trunk                
Resolution:               |    Keywords:  parser, help             
  Platform:  All          |         Cpu:  All                      
--------------------------+-------------------------------------------------
Comment (by glynn):

 Replying to [comment:14 huhabla]:
 > I have implemented a simple prototype, to get an idea how this may work.
 Files are attached. Do you think my implementation points in the right
 direction?

 I think that it's too early to be bothering with implementation details
 right now. I'd rather clarify the concept then the interface.

 > > Variadic functions could either use a prefixed count or a NULL
 terminator (but the latter won't work for numbers).
 > >
 > > You would also need dependent base types, e.g. "column name within the
 database table associated with the map specified by the input= option".
 >
 > I am not sure if i understand that, What is the benefit of dependent
 base type?

 I'm talking about the situation where the set of valid values for one
 option is dependent upon the value of another option. E.g. for options
 which specify the name of a database column, valid values are column names
 in a particular table, typically the table associated with a specific map.

 E.g. for d.vect, there are rgb_column=, wcolumn=, size_column=,
 rot_column=, and attrcolumn= options; valid values for these options are
 column names from the table associated with the map specified by the map=
 option. Ideally, the GUI would be able to offer a list of column names
 once the user has chosen a map.

 IIRC, at present the GUI updates the list whenever the user chooses a map.
 If a module has more than one option whose value is a vector map name, the
 GUI has no way of knowing which one determines the set of valid column
 names.

 Similar issues exist if valid option values are categories within a raster
 map, or cell values within the map's range, or coordinates within the
 map's bounds, subgroups within an imagery group, etc.

 > > When it comes to parsing, you could implement such types using a
 generic mechanism using a callback function to enumerate or validate
 allowed values; however, we need to think about how this interacts with
 the GUI.

 Right. This is why I'm inclined towards a "closed sum" approach, with a
 finite, fixed set of base types and constructors. Having the GUI invoke
 the module to execute a call-back should be a last resort. Apart from
 efficiency issues, it forces the GUI to use a generic interface rather
 than more specialised interfaces.

 > I think your approach has enormous potential, but i am also concerned
 that it may be to complicated for grass module programmers?

 Most modules will only need relatively straightforward types, e.g. "raster
 map name". The most common cases will just use G_define_standard_option().
 Still-common but more complex cases (e.g. a database column for a
 particular map) can have utility functions written for them.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1031#comment:15>
GRASS GIS <http://grass.osgeo.org>