[PEAK] Towards a GUI facility for PEAK

[Phillip J. Eby]

At 12:48 AM 12/5/04 -0500, Phillip J. Eby wrote:
>Well, enough speculation for tonight.

Okay, maybe just a little more...

Potentially, a portion of the interaction model could be the concept of an 
'Action' class, that's associated with menu items, buttons, etc.  An 
instance is created by the GUI when the action is to be invoked, and then 
various named views get looked up.  For example, the GUI might do a lookup 
to see if there's an "input dialog" view for the action, and if so, run 
that dialog to modify the Action instance's properties to reflect the input 
from the dialog.  The GUI could then look up whether there's a "progress 
dialog" view for the action, and display that while the action is taking place.

Notice, by the way, that these concepts apply almost as well to a web UI; 
one need only register actions under view names for given object types, and 
then have an adapter for Actions that looks up a view to render them as a 
web form.  When the form is submitted, the form data is used to populate a 
new Action instance, whose operation is then invoked.  With an appropriate 
validation mechanism, the form can be redisplayed with error information if 
there are any problems.  And, in a client-side GUI, validation can 
optionally occur as the user moves from field to field.

Actions might be components that get set as children of higher-level 
interaction model components, like the current "perspective" or "shell" (to 
use Eclipse's terminology).  They could then use bindings to automatically 
locate other, relevant interaction model components, in order to 
communicate with them if needed.  Of course, at least one of those bindings 
will likely reflect the current window or current selection, and be passed 
in by the UI system.

The system as a whole could perhaps be bootstrapped by having an 
"application" object, whose GUI view creates the top-level window(s) and 
such.  In the case of a web UI, this could perhaps be the root location 
object as well.

It's a rather intriguing idea that you could actually have what are 
effectively UI-independent Actions, that can then be registered as context 
menus for a GUI client, or as navigation menus for a web client.  At least, 
that would be true for actions associated with domain model 
objects.  Actions associated with interaction model objects (like a "Close 
Window" action) are less likely to be shared across GUI vs. web 
interfaces.  Perhaps, however, there will be generic functions for things 
like "get rid of the UI affordance for this interaction model object", that 
handle such actions.  For the "null UI" and "web UI", the function would do 
nothing, while in GUI toolkit UIs it would close the relevant window.

With some more work, I think we could also register Actions to be performed 
for drag-and-drop operations, based on the source and target types and any 
other necessary criteria.  It seems to me that some actions will be 
associated with the interaction model type, and others will be associated 
with a domain model object that the interaction model object wraps, 
although the action will receive a reference to both, regardless of what 
kind of action it is.

I also wonder how much overlap there might be between the ITraversalContext 
concept in peak.web, and these interaction model objects.  In other words, 
is web.ITraversalContext an interaction model for a web URL?  It's an 
intriguing thought, since it would allow web-specific Actions to control 
their behavior based on knowledge of the request environment, which seems 
quite appropriate.

Whew.  This is getting really interesting, but also far too much of an 
overload for my brain at this late hour, not to mention my sore hands from 
typing.