Brian Rice water@tunes.org 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.
-Lex