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

Chris Hanson wrote:

> 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.

We are talking sooo past each other.

The best design for a Logic Layer is event-driven,
period.

Grafting an event-driven GUI onto a procedural Logic
Layer causes cruft.

You are discussing the difference between sending a
message to a big object or dispatching the message to
many little objects. The latter is also best, but it's
orthogonal to event-driven.

> 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. 

Right. Talking about events and the event queue helps
discuss when not to simulate them.

> 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.

I just posted "Strict User Simulation". The breakdown
is:

 Simulate the User
  - Strict User Simulation
  - Firm User Simulation
  - Loose User Simulation

Strict means you put real events into the event queue
- as real as possible. Then you pump the queue. "Firm"
means you query your own framework to learn what would
have been called, and call it. 

You describe Loose User Simulation, where you just
call what you know the event system will call.

> > 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. 

The model stores the state of the model. The
application is everywhere. (I know you know that.
Verbiage!)

I put all of MVC in the Representation Layer. The view
is a representation of any kind of GUI Layer view, and
the model isa representation of any kind of Logic
Layer model. The model is just the rendezvous point
for all those GUIs to synchronize their world views.

> 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.

Sorry. 

All apps have logic, representation, and view, however
latent and coupled. All might need some kind of MVC,
but not all have them.

MVC really really means many little M, V, and C,
objects, all hooked to each other thru observers.

=====
Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


------------------------ 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/