Re: [TFUI] Re: UI Guidelines and Acceptance Testing

On Jul 24, 2004, at 4:33 PM, Phlip wrote:
> Great. I'm saying the right thing the wrong way. When
> I speak of GUI events, I mean the event queue, and its
> activity. GUI toolkit architectures forces event
> receivers themselves to be event driven.

Not necessarily, not at the raw event/queue level.  Framework code may 
operate at the raw event/queue level, and then send messages to 
particular objects when events trigger particular states.

For example, the only time you generally need to worry about mouse 
events in Cocoa is when you're implementing a custom control that needs 
to actually perform mouse tracking (rather than just send its action to 
its target on a click).  So a custom kind of button generally doesn't 
need any event handling, while (say) a round knob control only needs 
some minimal event handling to track the mouse.

I think talking about "events" and "the event queue" is getting 
low-level when you don't need to.  You don't need to simulate raw user 
input to do most test-first human interface development.  Rather, you 
need to simulate the framework interaction that results from user 
input.  For some frameworks, these are the same thing.  For other 
frameworks, one or the other is easier.

> That will suggest that your Representation Layer
> should not have state (in the DDD sense - it can have
> proxy objects containing reference data), and the
> Logic Layer
>  ought to be event driven. The events that drive it
> come either from its tests or (via the Representation
> Layer) from its GUI.

Model-View-Controller.  Model objects are where the actual state of the 
application lives.  Views just display whatever a controller hands 
them, and hand a controller whatever the user gives them.  Controllers 
mediate between model objects and views.

This is simple, standard terminology that doesn't require talking about 
"Logic Layers" and "Representation Layers," and it's also a very easy 
and natural way to structure applications in many frameworks.  It also 
happens to, at least with some frameworks, be easy to do test-first.

> Are there Carbon or Cocoa clones for Win32?

Carbon and Cocoa are very different.  Carbon is a procedural API based 
on the original Macintosh Toolbox.  Cocoa is a collection of 
object-oriented frameworks based on NeXT OpenStep.  Cocoa and its 
developer tools -- which are an integral part of the Cocoa developer 
experience -- are only available for Mac OS X.  The full Carbon API is 
available only on Mac OS X; a subset is available on Mac OS 9 for 
cross-compatibility.

   -- Chris

-- 
Chris Hanson <[email protected]>
http://www.livejournal.com/users/chanson/



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~-> 

To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/TestFirstUserInterfaces/

<*> To unsubscribe from this group, send an email to:
    TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/