Morning, Asger.
Given, Allan's relatively low coding input at the moment to the mainstream
humdrum of GUII, I'd say let's keep him happy and encourage him to do
this! Most of the dialogs already have a controller-view split and the
non-xforms GUIs have clearly benefitted from this. However, the
ButtonController is something of a pain to interact with at the moment.
Indeed, it's only through the comments posted by the "non-xformers", that
this is being done at all; I'd just got used to it's limitations.
His proposal should remove some of the main complaints about the
ButtonController and that will probably be "good enough". For the time being
at least! Equally importantly, the public interface to the class looks like
it's not going to change very much, so stability (Ha!) shouldn't be harmed.
Angus
On Wednesday 11 April 2001 09:02, Asger K. Alstrup Nielsen wrote:
> > Thoughts?
>
> I think you should consider once more whether this big and complicated
> machinery is really the best approach.
>
> It seems to be, looking from the sideline, that you have come to this
> point like this: First, an initial buttoncontroller was build. This
> turned out to be not as general as it could be, so it was rebuild in
> a better self. Then, this was introduced, but once again, it turned out
> that it was insufficient.
> Now, you can come up with a fairly general, but also quite complicated
> design. This general design looks like a kind of state machine facility.
> For each widget, you define a mapping to reflect whether it should be
> enabled or not.
>
> At first, this does indeed look fairly general, and certainly a
> step in the right direction. However, my bet is that you will need to
> extend even this general mechanism fairly soon. Then, you will discover
> that some dialog should enable and disable buttons according to what a
> certain input field contains, what item is selected in a drop list,
> and so on.
>
> It seems to me that the problem is very hard: It's not by accident that
> there does not exist a one-size-fits-all GUI design. Every toolkit does
> things it's own way, and so far, nobody has come up with a design that
> is general enough to support all needs. Now, this is not to say that it
> is not possible to come up with such a design at all. It's just a word
> of caution: It will prove harder than it seems.
>
> Given this, it's worth stopping and considering the best way to support
> the GUII work. Is it really worth the effort to develop the best and most
> general controller abstraction?
> Would it not be better to hold it, and just do the Model/ViewController
> split as discussed earlier?
>
> Greets,
>
> Asger
