> > One advantage to hard-coding the relationship is that it gives better > type-checking and IDE support. Are there likely to be more than a few > different relationships that need to be expressed?
I just can think of a band index from a raster layer (talking from what I have seen in GRASS processes and other similar ones). For sure, there might be more complex relationships, like parameters to be used only if a given option is selected in another parameter, but I would leave those aside, as they might make things more complex. I thing in those cases is better to rethink the process inputs and maybe split it in several ones, so a generic UI can understand their semantic perfectly, and a customized one can join them into one single process (in terms of what the user will see) if needed. Atomizing processes is, IMHO, a good thing > Might want to use a slightly more explicit name, like "choiceGroup" or > "optionGroup". > I agree with that. Both of them sound good enough to me. Victor ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
