#1031: More specific parameter information in command line help --------------------------+------------------------------------------------- Reporter: huhabla | Owner: [email protected] 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>
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
