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

Timothy Wall wrote:
>  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.
>  

I gave this some consideration in my concrete example. Like one of the
jobs of the main dialog here was to create new customers, and that act
may change the state of the dialog itself. For instance, I could see
passing a Hashtable back between the [Add New] dialog and the
presenter.

However, this is too simple for my purposes. The new dialog needs
selection lists and possibly more from the model state
(states/provinces, zips/postal codes and salutations, to name a few.)
So it really needs its own presenter that is connected somehow to the
model. If the creation of the new view and presenter duo happens in
the existing dialog, then it gets a lot of dependencies from outside
itself. And makes testing a bit more of a chore.

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

I seem to missing something, but isn't state the job of the presenter?
In doing validation and so forth. If this were a MVC web app like
Struts, the controller would maintain state to direct the field
validation prior to allowing the user to progress to the next screen.

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

As I said, that is an intriguing idea. I read somewhere that the UI
can be considered a form of Human API, in that you are controlling the
user as if he or shee were a data store.. But the idea doesn't go to
the aspects of my overall architecture.

In thinking it through, I think what is needed is some form of DI. I
had previously thought that this was only useful in the large arena.
Hundreds of UI screens, thousands of classes, etc. But maybe not. A
simple form of IOC might be just loading classes from names.
Everything would take an interface (view, controller and model.) Each
thing would be passed in the ctor a handle to a UI collaborator or
factory. This would have been the parent of the current UI triad, so
it passes itself into each constructor for view and presenter. Then
the request to [Add New] would be simply:
(AddNewCustomer)this.uiMaker.createUITriad("AddNewCustomer",
typeof(AddNewCustomer)). The wiring from view to presenter can be done
externally in XML or internally in a source file ran at startup.

Note, this is a lot like how we call the Mock instances..

Haven't really thought this all the way out, but it seems the best bet
for my current layout. And it it can be refactored in since I already
have the view and presenter interfaces.

 
Ed


------------------------ Yahoo! Groups Sponsor --------------------~--> 
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/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/