On Nov 24, 2006, at 4:42 PM, Brian Rice wrote:
On Nov 24, 2006, at 1:10 PM, Andreas Raab wrote:
- 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. So the search button had to go, because ToolBuilder can't do that easily.
Yes, that is true.
Maybe it can be fixed by detecting that a model is a Spec and then remembering that in an IdentityDictionary and then mapping it to the output. I don't know how feasible that is, but it's seems like it'd work reasonably.
It's time for me to backtrack again - I was wrong about this in the general sense. There *is* a Dictionary mapping widgets to outputs. More specifically, it maps the names of widgets to outputs, which is good enough, and accessible via widgetAt:(ifAbsent:). I missed this because the abstract ToolBuilder class doesn't have a dictionary instvar, just the protocol, even if all concrete subclasses use it. Also, there is no code making use of this feature, but it works fine.
What has to happen is that the model that calls the builder should retain the builder or at least its widgets dictionary after building. I am writing up a ToolModel class to make an easy way to do this and hopefully a few other things by default.
I am approaching the point where I may be able to write an article about the use of ToolBuilder, probably on Squeak People or I may blog it elsewhere.
-- -Brian http://briantrice.com