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

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.

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.

For example, I was writing a little proxy tunnel manager.  When 
creating a new tunnel, I need to specify a local host, remote address 
and remote port.  My "add new" button needs to collect that information 
and return it (and maybe do some validation); that's all.  The UI's 
responsibility is to collect information and pass it on to the model.  
The model can then create a new custom object, populate the model 
appropriately, and fire notifications.

Once you start collecting a lot of parameters, though, there starts to 
be a bit more logic in your UI, which itself will need testing separate 
from the model.  And the dialog becomes not-so-humble.  Some have 
suggested putting things like selection state into the data model, but 
I don't think that's appropriate.

At any rate, considering the UI as a parameter collector is one step 
that might help form the right patterns in your head.



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