multi-widget accept/cancel (was Re: SMLoaderPlus and ToolBuilder)

Lex Spoon lex at
Sat Nov 25 13:23:54 UTC 2006

Brian Rice <water at> writes:
> On Nov 24, 2006, at 1:04 AM, Lex Spoon wrote:
> > When I write Squeak dialogs by hand, the best approach I have found is
> > that each entire pane has a variable with a list of individual widgets
> > that need to be accepted before the pane can do its work.  Then, I
> > have a method that iterates through this list and calls acceptIfNeeded
> > (or whatever it is called).  Then, I call this method at the beginning
> > of every method that observes the input of those fields.
> Huh. That does seem like a decent way to get the job done in morphic.
> > I implement this pattern repeatedly.  It would be a candidate for a
> > framework such as ToolBuilder.  (Of course, if ToolBuilder has another
> > approach to this problem, then just as well!)
> ToolBuilder doesn't do this - it just offers PluggableInputFieldSpec
> which is just a text input field. The spec could conceivably be
> extended with an action button and/or title, but it doesn't seem like
> an easy way to go.

One approach would be that all button specs optionally trigger this
"accept everything" behavior.  Buttons that have this option turned on
would have an intermediary between the ButtonMorph and the model.
This intermediary would accept all fields in the dialog before
invoking the user-specified method on the model.

This option could even be turned on by default!  It seems like the
common case, as well as the safer case.

> Certainly an InputSpec makes sense which would come
> with its own way to specify validators and sub-validators.

Yeah, that's another thing.  There are various levels of input
validation for dialogs, aren't there?  There's syntax of individual
inputs (that's not a valid date), things dependent on different fields
(your final date is earlier than yoru start date), and the overall
final request (you just tried to schedule an appointment at a time
that overlaps an existing one).  It would be nice to have a generic
way to specify these validators.

> > For your search example, the model object behind the search-area
> > pane--or indeed the search-area pane itsealf--could have a variable
> > pointing back to the text widget where the user types in the search
> > phrase.  Then the "search" method would accept this pane before doing
> > the actual search.
> The problem is that the model (that specifies what it wants built)
> only holds on to the /spec/ of the widget, not the widget itself. The
> point of the build process is to decouple that model from the actual
> structural details of the output, focussing only on the spec. If I
> reach into the "window" variable output and grab the specific morph
> in question, I've coupled my app not just to Morphic but to the way
> in which the ToolBuilder generates Morphic widgets.

Yes, this coupling is ugly.  The intermediary idea I described above
seems to avoid this problem, though.  The intermediary is part of the
UI stuff.

Anyway, one way around this is to make each dialog have its own morph
class.  Then the dialog object has the pointers to the individual
input widgets.  This way, you keep the UI and model parts separate.

By the way, thinking of these issues, I hope that ToolBuilder has a
way for users to add their own morph classes to a UI.  This is an
escape hatch for any feature a user wants that is not already covered
by the existing system.  Even businessy plain-gray UI's will
occasionally benefit from a custom widget here and there.


More information about the Squeak-dev mailing list