Yes, the link doesn’t work. Can you please email me the sample code as well or fix the link?

Thanks
Setu.

I’ve thought more about this (and had a re-read of the martin fowler MVP page, which I’m sure has been updated since I last looked). The presenter implements *all* of the biz logic for any UI. The view is not allowed (my understanding of MVP) to “decide” any actions.

Now if I could the the product manager to use FitNess *and* I actually thought it was worth the effort we could have FIT tables to demonstrate what should happen in various UI senarios.

If only I’d gone to the effort of re-reading the Folwer page before my earlier post I could have better stated my thinking [now not then, which would have been then too had I read it, clear ].

Cheers,

adam

By adding a ComposerEnabled property, you are letting some implementation details of the view permeate into the presenter. Again, just my (possible naive) opinion

public bool AlbumForm::IsClassical
{
get{ /* … */}
set
{
cbClassical.Checked = value;
txtComposer.Enabled = value;
}
}

this is asnippet from your production code where you actually have business logic. i.e. setting the classical checkbox state also enables the state of another control. (In my case is was the clearing of a list before populating it.)

My current thinking is that this is wrong and should be 2 properties/methods on the IAlbumView [ComposerEnabled *and* ISClassical] such that setting the current Album on the presenter should invoke both of these methods seperatly.

I’ve not had enough experience using MVP to ‘know’ if I’m right so I’m still open minded about it all.

Lately, I have noticed that the Humble Dialog Box or Model…