Brian Rice <water at tunes.org> writes:
> The search pane... hm, this gave me some grief. So, in this builder
> design pattern, you construct a tree of specification objects, pass
> it to the Builder object and tell it to build: them. This seems
> rather Java-inspired, but that's beside the point.
> - One issue I had was trying to recreate the "Search" button that in
> the original, took the search field as its model and called #accept
> on it to kick off a search. In a builder interface, you can't do
> this, because you only get the specification objects and not the
> output. In fact, you're not supposed to be able to access the output.
> I thought about work-arounds, but they all involved propagating the
> search field text to the model on every keystroke and then having the
> button call a method on the model that uses that, or making a
> trampoline in the model that the search field would watch... except
> that it can't do that.


This I think is a mis-designs in the Smalltalk accept/cancel style.  I
like accept/cancel in general, *except* that it should really apply at
the level of an entire pane [1], not at the level of individual widgets.

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.

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!)

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.

By the way, always remember when doing this that an "accept" can fail
on invalid input!  These methods should return a boolean to indicate
whether the accept was successful, and if it was not, the calling
method should silently quit.

-Lex





[1] I started to write "window", but really what I write just applies
to contiguous portions of a window used for one purpose.  There is a
contingent of Squeak UI designers who prefer to have big
multi-function windows instead of the more classical single-purpose
windows.