On Nov 24, 2006, at 1:04 AM, Lex Spoon wrote:
Brian Rice water@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.
I agree about this perspective.
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.
UIManager of course has its dialog protocol, which to me sounds like a ChoiceSpec or something similar, but it's not the same as offering a non-modal open-input choice, or even a modal set of open-(or not)- input choices. Certainly an InputSpec makes sense which would come with its own way to specify validators and sub-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.
But maybe what you're saying is that there needs to be a separate model, perhaps generated for every input field/set. That's interesting, but I don't know what to do with that idea.
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.
Yeah, that's a good point.
[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.
There should probably be a term neutral to pane/window which specifies an activity or something. I'll give it some thought.
-- -Brian http://briantrice.com