We need an ECP (Error Cleanup Project)
Stephane Ducasse
ducasse at iam.unibe.ch
Sun May 11 19:31:13 UTC 2003
Hi
I do not feel really good for assessing your design.
But I have some questions to help evaluating it:
- How many of different interaction do we have?
I do not think that we have that much
- what is the frequency of having new interaction?
I think that this is rare that we have new ones (but I can be
completely wrong)
>> For me what I would really to see happening is a clean of the
>> inform: ..... to generate exception that UI clients could catch.
>
> I've started work on this. It's not completely obvious what the
> design of
> this facility should be. The simplest would be something like this:
>
> - define a "Dialog" protocol with methods like #inform:, #confirm: ...
> - define Object>>inform: to be something like this:
>
> inform: aString
> CurrentDialogNotification signal inform: aString
>
> - set up handlers for CurrentDialogNotification that provide an
> instance
> that responds to the Dialog protocol:
>
> [...] on: CurrentDialogNotification do: [:n | n resume: MyDialog new]
>
> The advantage here is the relative simplicity - we only need to
> introduce
> one new exception class, along with implementations of Dialog for
> Morphic,
> MVC, etc. Adding new UI interactions is quite lightweight - just add
> new
> methods to the Dialog implementations.
>
> Another possibility is to define an exception class for each type of
> interaction. #inform: would look like:
>
> inform: aString
> (InformUserNotification message: aString) signal
>
> It's possible we could make things a little more general and have one
> exception for message boxes (with configurable buttons), one for text
> input boxes, and so on. But there would still be a fair number of
> exceptions, and adding an interaction would mean adding a new exception
> class.
>
> The advantage here is that it's possible to catch any individual one of
> these without affecting the rest of the UI. For example, in an install
> script you might want to ignore any simple messages, but still have
> progress bars show up - so you could do something like
>
> [...] on: InformUserNotification do: [:n | n resume].
I have the impression that we do not really want that.
Others?
> What I've actually done so far is a hybrid of this approach - I define
> an
> exception for each interaction, all of which are subclasses of
> UserNotification. I've then defined UserNotificationHandler classes
> that
> catch any UserNotifications, and then call a particular handler method
> using double dispatch through the notification. This way, generally
> what
> you have to do for a new UI is define a new Handler subclass and
> implement
> the #handleFooNotification:, #handleBarNotification: methods - but it
> would still be possible to catch individual exceptions in special
> cases.
> However, this all feels a bit heavyweight and overdesigned.
>
> Any comments?
>
> Avi
What I like is that we could remove all UI dependency from the kernel.
Now I still do not really see where the handler for Morphic would be
defined?
In some UISession (if I remember the class proposed by the SqueakMod
guys).
Stef
More information about the Squeak-dev
mailing list
|