[mcclim-devel] questions about CLIM interface paradigm

[Paolo Amoroso]

rpgoldman at real-time.com writes:

> 1.  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?


> 2.  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
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log