It's possible I don't quite understand the proposed design, so bear with
me.

But it seems to me you're saying the interface has two parts - raising
the request, and handling it.

Raising will be simple, and hidden using methods like Object>>notify:,
whatever the implementation.

OTOH, handling is a bit more complicated, because it has to handle
expansion. You describe a specific expansion scheme. I think the
question here is, what's the simplest thing that could possibly work?
our current goal is not to solve configurability here forever. Our first
goal is to disconnect the direct UI references, so we can start to
experiment with redesigning the other participants (clients and UIs). 
Seems to me we'll be wiser about the requirements for expansion later
on... so IMO for now we should do only what is required to fix the cases
found in the image.

Daniel

Avi Bryant <avi at beta4.com> wrote:
> 
> On Sun, 11 May 2003, Stephane Ducasse wrote:
> 
> > 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].
> 
> 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