Re: [TFUI] The MVP pattern and loose coupling between view/presenter and presenter/model

Timothy Wall <[email protected]> writes:

> On Sep 14, 2005, at 7:51 PM, Ed Howland wrote:
>
>> OK, say you have a dialog, (be it ever so humble,) and you have
>> implemented the presenter and the view such that only primitive things
>> are passed from the presenter to the view (strings, ints, lists,
>> dates.)
>
>> What I'm wondering is, can there ever be a scenario in which higher
>> order objects (from the model) are passed between presenter and view?
>>
>> Consider adding some more functionality to the dialog. I want to add a
>> [Add New] button which invokes a new form whose job it is to return a
>> newly populated object from one of the model's classes.
> ...
>
>>
>> This seems straightforward, till you follow the chain to the end
> ...
>> But I can't get this view to invoke my Add New dialog for me without
>> passing in and out the constructed and populated model object to my
>> presenter for insertion into the collection. Which violates the "only
>> pass primitive things" rule.
>>
>
> I've been stewing over this sort of thing for a while, since most 
> interesting UIs deal with a lot more complexity than simple, 
> unconnected basic data types.

Same here.

> I think the key here is to stop before you create the custom object.  
> Use the UI to collect as much data as you need to create the custom 
> object, then pass that data as a group back to your model to let it do 
> the creation.

Interesting. This is somewhat similar to what I do.

I'm not a big fan of the humble dialog box, or MVP --- it seems to proliferate
thin classes that do nothing interesting. Instead, I prefer to have a single
class behind each window in the GUI, as far as possible. This means that this
class knows about the GUI toolkit, and knows about basic business logic
related to what it's doing --- this class is responsible for ensuring that the
correct controls are enabled/disabled, the correct data is populated, etc.

However, I also like to keep things fine-grained, so this class has very
GUI-focused responsibilities --- if it needs information from the rest of the
system, or it needs to actually *do* something to the system (e.g. an "Apply
Now" button in a config dialog), then it asks its (single) collaborator. This
collaborator is also responsible for displaying additional GUI windows if
asked --- e.g. the main GUI window might have a button which displays a
secondary dialog. The main window doesn't know about the secondary dialog, it
just asks its collaborator to retrieve the information from the user, and the
collaborator then instantiates the dialog to get the information.

In this way, the collaborator acts as a bridge. It knows which classes are
responsible for displaying the various parts of the GUI (but doesn't talk to
the GUI toolkit itself), and it knows which classes are responsible for
managing the various aspects of the system (but doesn't actually manage
anything itself).

I tend to go for one collaborator per GUI window, so in actual fact, they only
know about the subset of GUI classes and backend classes related to the first
GUI window.

You could think of this as Model (Backend classes) View (GUI class) Presenter
(Collaborator), but I think that the way I work has the boundaries at a
different level. There's none of this mapping between UI events and presenter
methods --- the GUI class handles UI events, and only requests business info
and external user interaction from the collaborator; a typical dialog might
only invoke two calls on the collaborator during its entire existence --- once
at the beginning to request current state information, and once at the end to
set new state.

Anthony
-- 
Anthony Williams
Software Developer
Just Software Solutions Ltd
http://www.justsoftwaresolutions.co.uk



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/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/