Hi,

Getting Started

To get started with the WCSF I would recommend you to check out the Labs (although the labs are for the 2007 version, you should still be able to get some important concepts from them) and Quickstarts (you have to install the source code to use the Quickstarts). To accompany the labs you could check out the MSDN Documentation.

As for a base for standard approach when using WCSF, you can check the Bank Branch Reference Implementation. To use the Global Bank Reference Implementation you must install the WCSF - February 2008 source code. The WebClientFactorySourceInstall.msi installer is located in the Source folder located in the directory where you installed the factory.

Once you have installed the source code you should be able to open the Global Bank solution located under the GlobalBankRI folder.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Regarding where to place the logic to update your gridview/datagrid, there are different implementations of the MVP pattern, which should be chosen according to your testability needs. Depending on the implementation of the MVP pattern you are going to use, the relation between the Model-View-Presenter varies.

Passive View

The interaction with the model is handled only by the presenter; the view is not aware of changes to the model.

Implementation

The event handlers in your application should be in the Presenter. Its responsibility is to get the events raised by the view and use the model according to the business rules. Once the model is updated the Presenter’s has to notify the view, so it can refresh itself.

Example

View Code:

private void printGridButton_Click(object sender, EventArgs args)

{

    _presenter.PrintGrid(args);

}

Presenter Code:

public void PrintGrid(EventArgs args)

{

    // Your printing code…

    View.ShowMessage("Print Successful");

}

Supervising Controller

The interaction with the model is handled NOT only by the presenter. The view uses DataBinding to update itself when the model is updated.

Implementation

Unlike the previous implementation, the View has knowledge of the Model. Through databinding, when the model is updated so is the view, thus avoiding having the presenter notify the view of the changes to the model. This is useful for non complex UI changes. This implementation makes your view less testable.

For more information about the MVP pattern you might find useful:

·         Model-View-Presenter Pattern [WCSF]: Describes the two implementations of the MVP pattern mentioned above.

Please let me know if this helps.

Damian Schenkelman

public void GridView1RowDataBound(System.Web.UI.WebControls.GridViewRowEventArgs e)

{

    if (e.Row.RowType == System.Web.UI.WebControls.DataControlRowType.DataRow)
    {
       e.Row.Cells[3].ToolTip = e.Row.Cells[3].Text;
       e.Row.Cells[3].Text = AppendEllipse(e.Row.Cells[3].Text, 150);
    }

}

Hi

If you are using the Passive View implementation, the complex logic should be placed in the presenter which is also in charge of updating the view. Therefore the implementation would be similar to #2 Approach.

However, as this article says there might be no need to place any code on the presenter if this is a simple data-binding situation, but that would require using Supervising Controller: “In Supervising Controller, the view interacts directly with the model to perform simple data-binding that can be defined declaratively, without presenter intervention…”

As for “…hide & show of a certain Items or changing a item template appearance (enable, disable, changing images or objects from checkbox to raddio button) once a certain condition is/was satisfied…”, usually the code to handle this is in the presenter in both implementations. In Passive View because the presenter handles all complex logic to update the view. And in Supervising Controller: “…it manipulates the state of the view only in cases where complex UI logic that cannot be specified declaratively is required. Examples of complex UI logic might include changing the color of a control or dynamically hiding/showing controls” (Model-View-Presenter Pattern, same article as above talking about the presenter)

Which implementation to use is a design decision that should be made according to your needs. While the benefit of using the Passive View approach is having a more testable application (the presenter has all the logic to update the view), the Supervising Controller will allow you to write less code (direct Model-View interaction in some situations).

For an example on how to use data binding with a Grid View (using Supervising controller) you can check the MVPwithCWAB QuickStart. You can find it in the MVPwithCWAB folder where you installed the WCSF source code.

I hope this makes things more clear.

Damian Schenkelman

I don't think the approach 2 is correct. It causes the presenter to use "System.Web.UI.WebControls". Its a heavy violation, I think.

Approach 1 is also not proper as view should not do any presentation logic.

Thoughts?

Thanks

Hi,

Based on my understanding, the responsibility of the presenter would be to obtain the corresponding information from the model and present it in a consumable format to the view. I believe that any other logic regarding the visual elements of the view could be handled on the view itself, as this does not necessarily include performing any presentation logic (that is, organizing data, formatting it or calculating new data based on the existing one). In my opinion, for this case:

• If you want to hide/show an element from the grid (supposing that the presenter exposes the data that will be shown in the grid through a collection) you could remove/add this record for the data collection exposed by the presenter and update the grid in the view's code behind.
• If you need to change the appearance of a element in the view, I believe that this should be done in the view as the change itself only includes visual logic. Regarding the "condition" to perform this visual aspects, this could be based on a state or other information in the presenter.

I hope you find this useful,

Damian Cherubini
http://blogs.southworks.net/dcherubini

Firstly, I am very surprised to see an answer on a 3 year old post. Thanks for considering this (and not saying "try to switch to MVC"). I pretty much concur with your opinion - if there is any preseneation rule, it should be handled in presenter. Otherwise, control related task can be hanlded in view. (Still the preference is in presenter, if it can be done in presenter and if it doesn't overkill).

Will it be possible for you take a look at the following post and have your comments? http://forums.asp.net/p/1760921/4793183.aspx/1?Model+View+Presenter+Guidelines