WCSF, Starter Kit?

Topics: Web Client Software Factory, UIP Application Block discussion, User Forum
Jan 26, 2009 at 7:19 AM
Edited Jan 26, 2009 at 7:21 AM
Hi,

I don't know if I missed it, but does WCSF have some sample running application like "ASP.NET MVC StorefrontStarter Kit"?
Where we can some how use it as base for standard coding approach when using WCSF.
Why is it that there we not enough resources/sample whole wcsf application out there?  =(

We have a small irritating issue:
Question:
   Where should we put the tweaking of GridView or DataGrid Elements such as 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?
   Is it, still the same old approach, where the page it self will manipulate the gridview/datagrid items using ItemDataBound/RowDataBound?
   OR is it, passing it(gridview/datagrid) to a Presenter as an object and let the manipulation takes from there(Presenter)


br,
ca
Jan 26, 2009 at 1:16 PM

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

http://blogs.southworks.net/dschenkelman

Jan 28, 2009 at 10:28 AM
Damian,

For the sake of the discussion I use "Passive View".
Still my question below still an unanswered.

We have a small irritating issue:
Question:
   Where should we put the tweaking of GridView or DataGrid Elements such as 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?
   Is it, still the same old approach, where the page(View) it self will manipulate the gridview/datagrid items using ItemDataBound/RowDataBound?
   OR is it, passing it(gridview/datagrid) to a Presenter as an object and let the manipulation takes from there(Presenter)

Anyways, which of the 2 approaches below is appropriate?
#1 Approach:
View Code:

protected void FillGridData()
{
   GridView1.DataSource = _presenter.FillData();
   GridView1.DataBind();
}
 protected void GridView1_RowDataBound(object sender, 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);
                
            }
        }


#2 Approach :

View Code:

protected void FillGridData()
{
   GridView1.DataSource = _presenter.FillData();
   GridView1.DataBind();
}

 protected void GridView1_RowDataBound(object sender, System.Web.UI.WebControls.GridViewRowEventArgs e)
        {
           _presenter.GridView1RowDataBound(e);
        }

Presenter Code:

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);
    }

}



br,
ca
Jan 28, 2009 at 2:04 PM

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

http://blogs.southworks.net/dschenkelman
Feb 2, 2009 at 2:45 AM
Hi again,

Does it mean that those MVP, where View is heavily using Ajax or JQuery will fall under "Supervising Controller"?

br,
ca
Jan 24, 2012 at 11:09 AM
Edited Jan 24, 2012 at 12:08 PM

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

 

 

 

Jan 24, 2012 at 8:13 PM

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

Jan 25, 2012 at 3:04 PM
Edited Jan 25, 2012 at 3:09 PM

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