rpgoldman@real-time.com writes:
- This is a question about using the CLIM interface paradigm that I know
should have an obvious answer, but I just don't understand where to find it.
Possibly likewise ;-)
Consider that I have a command with some number of arguments > 1. Now, I specify a command with argument types. OK. Now where do I put the procedural information about the mechanics of choosing the arguments?
Doesn't CLIM already take care of this in interactor panes, e.g. with required and keyword arguments? See for example the CLIM Listener commands Show Class Subclasses/Superclasses.
But this seems wrong. Shouldn't I be able to specify the arguments and their types and have McCLIM Do the Right Thing about reading the additional arguments? E.g., know that a set of radiobuttons might be the right way to collect a multiple-choice modifier argument?
1.a) To get this behavior, should I be writing a bunch of accept methods?
When you have many inputs of different types, you may use accepting-values.
1.b) If so, in an app that has an graphical application-pane and an interactor-pane, should I have one accept method that lets people click on the corresponding presentations (if any) and a separate one that will handle textual input? E.g., if I have objects with names,
What about views?
- Is it good style to use the Enabled method? Is there a standard
I think this is a general UI issue, not necessarily a CLIM one.
Previously I had a lot of code that would handle inappropriate methods and produce a helpful string or two, but this is repetitive, a blemish on the design, and can be very large if there is a relatively complex condition for enablement....
You may keep a table associating commands with lists of commands to enable/disable. Each entry could also include tests for checking whether to actually disable/enable commands. The commands that need to do that could access the appropriate entry, run the tests, and enable/disable the relevant commands. It should be possible to hide much of this complexity to a CLIM application.
Paolo