NMVP Framework

New Post: MVP Pattern Reuse Pages

PradeepY — Mon, 03 Nov 2008 15:29:46 GMT

Hi,

I have multiple aspx pages which have the same layout but differs in the data being populated based on the query string coming to the page and other Business rules.

Is there anyway i can combine these redundant aspx pages into one single aspx page in MVP pattern??

I am using same view in all the redundant aspx pages as of now.

Does this open source framework solves my problem above?

Any comments or suggestions here are welcome.

Thanks in advance.

UPDATED WIKI: Home

Ohad — Fri, 02 Nov 2007 20:24:50 GMT

Welcome to Project NMVP Framework

Project NMVP has moved to http://stormwind-trac.cvsdude.com/NMVP. This is the NMVP TRAC site for Stormwind Community. We'll be improving it from there.

Check out our new community website at http://www.stormwindproject.org/.

To check out the 1.0.0 Vision Statement Document go here: http://stormwind-trac.cvsdude.com/NMVP/wiki/Documentation
To check on the Home Page for CodePlex as it used to be go here: OldFirstPage

NEW POST: NMVP Project

Ohad — Thu, 25 Oct 2007 08:23:21 GMT

Hmmm... I just now see the phpBB forums.

NEW POST: NMVP Project

Ohad — Thu, 25 Oct 2007 08:16:05 GMT

So, finally I've started working with this project, and I start reviewing its code, and this project looks like great project (I didn't like MonoRail, and as I said in the previous post - I was looking for a MVC / MVP framework to work with)

The question are:
1. Are you still working on this project?
2. What next? I'd like to help with this project. As I was saying - I'm an ASP.NET developer so I can help with the Web project.
3. What with the Stormwind? You were writing:
"Now our next steps are to get the Web Site for the Community online (Any help is immensely appreciated) and a forum (that one will be easier since we already have one chosen). We'll probably be providing blogs for the community in blogs.stormwindproject.org."

Are you looking for a community and a forum? what about CommunityServer? or Yet another forum?
http://www.yetanotherforum.net/

BTW,
42 is not the answer to life.

Ohad

NEW POST: Is this project still active?

Ohad — Thu, 30 Aug 2007 05:15:25 GMT

k... :)

NEW POST: Is this project still active?

Heynemann — Wed, 29 Aug 2007 14:00:31 GMT

I am... I got pulse...
:)
I´m waiting on your evaluation of the NMVP code :)

Thanks

NEW POST: Is this project still active?

Ohad — Wed, 29 Aug 2007 13:02:52 GMT

Are you alive?

NEW POST: Is this project still active?

Ohad — Sun, 26 Aug 2007 19:24:16 GMT

Great! I thought that this project is dead,

I hope I'll have enough time next week to go over the code, and try it,
In the last month I was learning about MVC/MVP, and maybe I will help you!

I'm a webdeveloper (ASP.NET, C#, and in the past Classic ASP).

Ohad.

UPDATED WIKI: OldFirstPage

Heynemann — Sun, 26 Aug 2007 04:25:06 GMT

Welcome to Project NMVP Framework

News

Date	News
16-Aug-2007	NMVP V1.0.0 is in the Oven - Help out by contributing to it's vision statement at Vision Statement. By the way, 21.000+ visitors to the project and growing. Thanks for the interest guys!
11-Feb-2007	The first three chapters of the book "NMVP Inside-Out" have been released! Make sure you check them out here!
03-Feb-2007	Release 0.3.0 Production is out! This is the release that features both bindable MvpContainer for ASP.Net and the new MockFactory that allows for ZERO-WORK mocking! Be sure to check both out!
03-Feb-2007	Srihari Suresh joined the team! Welcome aboard buddy!
27-Jan-2007	Release 0.2.0 Production is out! It has tons of new features and a tutorial on all of those as well as framework structure explanation will be posted soon. Keep posted!

Showing News 1-5 of 12 - Click here for older news

Staff

Bernardo Heynemann - Coordinator
Márcio Duarte - Developer
Sadek Drobi - Developer
Srihari Suresh - Developer

NMVP is an acronym for .Net Model-View-Presenter Framework.
The NMVP Framework is a framework for helping in building Model-View-Presenter (MVP) based UI architectures.

Even though it´s possible to create very simple MVP Architectures using NMVP, it really shines when used to build Composite MVP Architectures. If you don´t know MVP yet, please check out our Links page. There are several good articles about it there.

Intro

First let´s understand what every component does in the bigger picture. Each one of these classes is better documented in the reference of the project (that comes with each release).

Resolver - This is the Dependency Injection container and is responsible for resolving a fully configured and hooked HostPresenter.

Host Presenter - The HostPresenter class is responsible for orchestrating every single other presenter. This is the component that receives the Init, Load and Save calls from the Host (the ASP.Net Page for instance). This class has references to the current Security Context (ISecurityContext), the current Configuration Context (Config) and for the current Transaction Context (used for maintaining the same transaction across different presenter calls).

IHost - The IHost interface is responsible for defining the contract of a Host. This interface contains a property called IsValid that is responsible for telling the HostPresenter the state of validity of the Host.

IContract - The IContract interface defines the contract that the view must implement. Every single interface that views implement MUST inherit from this one.

IContainer - The IContainer interface defines a container. A container is a model that has dynamic models attached to it. Likely this model will be used for multiple relationships like participants on a project, for instance (you don´t know at first hand how many there will be, so you need a dynamic container).

ISecurityContext - The ISecurityContext interface is responsible for defining a security context model. Any implementation of this interface can be used in the framework as Security Context.

Config - The Config class is responsible for obtaining the current MVP configuration (for the model being executed). This class reads this configurations of a XML configuration file.

PresenterBase - The PresenterBase class is the base class of the generic presenter. It has a few base implementations of the main methods, and a few important properties and events.

Presenter<> - The Presenter<> class is the base class from whom all the presenters (all but the Container ones) must inherit, since it allows a type-safe usage of the Model that the presenter is bound to. This class inherits from PresenterBase.

ContainerPresenterBase - The ContainerPresenterBase class is responsible for performing container presenter operations. This is the class that the generic ContainerPresenter inherits from. This class inherits from PresenterBase.

ContainerPresenter<> - The ContainerPresenter<> class is the class from whom all the ContainerPresenter classes must inherit, since it allows a type-safe usage of the Container that the presenter is bound to. This class inherits from ContainerPresenterBase.

ASP.Net Support

NMVp supports ASP.Net usage of presenters by default. If you want your page and/or user controls to be automatically hooked to their presenters all you have to do is inherit from MvpPage or MvpUserControl and everything gets done for you.

If you inherit from MvpPage all you have to do is add the presenter class full name in the header of your page:

<%@ Page Language="C#" AutoEventWireup="true" Codebehind="LoginMvpPage.aspx.cs" Inherits="NMvp.Web.Testing.LoginMvpPage"
PresenterId="NMvp.TestModel.Login.LoginFormPresenter, NMvp.TestModel" %>

If you prefer that it´s an user control, just add the presenter class full name to the user control declaration:

<uc1:MvpLoginForm ID="MvpLoginForm1" runat="server" PresenterId="NMvp.TestModel.Login.LoginFormPresenter, NMvp.TestModel" />

Those are the main features. More details will be loaded here in the wiki at a later time.

UPDATED WIKI: Home

Heynemann — Sun, 26 Aug 2007 04:24:12 GMT

Welcome to Project NMVP Framework

Project NMVP has moved to http://stormwind-trac.cvsdude.com/NMVP. This is the NMVP TRAC site for Stormwind Community. We'll be improving it from there.

Soon there will be more news about it here.

To check out the 1.0.0 Vision Statement Document go here: http://stormwind-trac.cvsdude.com/NMVP/wiki/Documentation
To check on the Home Page for CodePlex as it used to be go here: OldFirstPage

UPDATED WIKI: Home

Heynemann — Sun, 26 Aug 2007 04:23:44 GMT

Welcome to Project NMVP Framework

UPDATED WIKI: OldFirstPage

Heynemann — Sun, 26 Aug 2007 04:22:58 GMT

Welcome to Project NMVP Framework

News

Date	News
16-Aug-2007	NMVP V1.0.0 is in the Oven - Help out by contributing to it's vision statement at Vision Statement. By the way, 21.000+ visitors to the project and growing. Thanks for the interest guys!
11-Feb-2007	The first three chapters of the book "NMVP Inside-Out" have been released! Make sure you check them out here!
03-Feb-2007	Release 0.3.0 Production is out! This is the release that features both bindable MvpContainer for ASP.Net and the new MockFactory that allows for ZERO-WORK mocking! Be sure to check both out!
03-Feb-2007	Srihari Suresh joined the team! Welcome aboard buddy!
27-Jan-2007	Release 0.2.0 Production is out! It has tons of new features and a tutorial on all of those as well as framework structure explanation will be posted soon. Keep posted!

Showing News 1-5 of 12 - Click here for older news

Staff

Bernardo Heynemann - Coordinator
Márcio Duarte - Developer
Sadek Drobi - Developer
Srihari Suresh - Developer

Intro

First let´s understand what every component does in the bigger picture. Each one of these classes is better documented in the reference of the project (that comes with each release).

Cannot resolve link: [image:NMVP.Classes.jpg]

Resolver - This is the Dependency Injection container and is responsible for resolving a fully configured and hooked HostPresenter.

Host Presenter - The HostPresenter class is responsible for orchestrating every single other presenter. This is the component that receives the Init, Load and Save calls from the Host (the ASP.Net Page for instance). This class has references to the current Security Context (ISecurityContext), the current Configuration Context (Config) and for the current Transaction Context (used for maintaining the same transaction across different presenter calls).

IHost - The IHost interface is responsible for defining the contract of a Host. This interface contains a property called IsValid that is responsible for telling the HostPresenter the state of validity of the Host.

IContract - The IContract interface defines the contract that the view must implement. Every single interface that views implement MUST inherit from this one.

IContainer - The IContainer interface defines a container. A container is a model that has dynamic models attached to it. Likely this model will be used for multiple relationships like participants on a project, for instance (you don´t know at first hand how many there will be, so you need a dynamic container).

ISecurityContext - The ISecurityContext interface is responsible for defining a security context model. Any implementation of this interface can be used in the framework as Security Context.

Config - The Config class is responsible for obtaining the current MVP configuration (for the model being executed). This class reads this configurations of a XML configuration file.

PresenterBase - The PresenterBase class is the base class of the generic presenter. It has a few base implementations of the main methods, and a few important properties and events.

Presenter<> - The Presenter<> class is the base class from whom all the presenters (all but the Container ones) must inherit, since it allows a type-safe usage of the Model that the presenter is bound to. This class inherits from PresenterBase.

ContainerPresenterBase - The ContainerPresenterBase class is responsible for performing container presenter operations. This is the class that the generic ContainerPresenter inherits from. This class inherits from PresenterBase.

ContainerPresenter<> - The ContainerPresenter<> class is the class from whom all the ContainerPresenter classes must inherit, since it allows a type-safe usage of the Container that the presenter is bound to. This class inherits from ContainerPresenterBase.

ASP.Net Support

Cannot resolve link: [image:NMVP.Web.jpg]

NMVp supports ASP.Net usage of presenters by default. If you want your page and/or user controls to be automatically hooked to their presenters all you have to do is inherit from MvpPage or MvpUserControl and everything gets done for you.

If you inherit from MvpPage all you have to do is add the presenter class full name in the header of your page:

<%@ Page Language="C#" AutoEventWireup="true" Codebehind="LoginMvpPage.aspx.cs" Inherits="NMvp.Web.Testing.LoginMvpPage"
PresenterId="NMvp.TestModel.Login.LoginFormPresenter, NMvp.TestModel" %>

If you prefer that it´s an user control, just add the presenter class full name to the user control declaration:

<uc1:MvpLoginForm ID="MvpLoginForm1" runat="server" PresenterId="NMvp.TestModel.Login.LoginFormPresenter, NMvp.TestModel" />

Those are the main features. More details will be loaded here in the wiki at a later time.

UPDATED WIKI: OldFirstPage

Heynemann — Sun, 26 Aug 2007 04:22:43 GMT

Welcome to Project NMVP Framework

News

Date	News
16-Aug-2007	NMVP V1.0.0 is in the Oven - Help out by contributing to it's vision statement at Vision Statement. By the way, 21.000+ visitors to the project and growing. Thanks for the interest guys!
11-Feb-2007	The first three chapters of the book "NMVP Inside-Out" have been released! Make sure you check them out here!
03-Feb-2007	Release 0.3.0 Production is out! This is the release that features both bindable MvpContainer for ASP.Net and the new MockFactory that allows for ZERO-WORK mocking! Be sure to check both out!
03-Feb-2007	Srihari Suresh joined the team! Welcome aboard buddy!
27-Jan-2007	Release 0.2.0 Production is out! It has tons of new features and a tutorial on all of those as well as framework structure explanation will be posted soon. Keep posted!

Showing News 1-5 of 12 - Click here for older news

Staff

Bernardo Heynemann - Coordinator
Márcio Duarte - Developer
Sadek Drobi - Developer
Srihari Suresh - Developer

Intro

Resolver - This is the Dependency Injection container and is responsible for resolving a fully configured and hooked HostPresenter.

Host Presenter - The HostPresenter class is responsible for orchestrating every single other presenter. This is the component that receives the Init, Load and Save calls from the Host (the ASP.Net Page for instance). This class has references to the current Security Context (ISecurityContext), the current Configuration Context (Config) and for the current Transaction Context (used for maintaining the same transaction across different presenter calls).

IHost - The IHost interface is responsible for defining the contract of a Host. This interface contains a property called IsValid that is responsible for telling the HostPresenter the state of validity of the Host.

IContract - The IContract interface defines the contract that the view must implement. Every single interface that views implement MUST inherit from this one.

IContainer - The IContainer interface defines a container. A container is a model that has dynamic models attached to it. Likely this model will be used for multiple relationships like participants on a project, for instance (you don´t know at first hand how many there will be, so you need a dynamic container).

ISecurityContext - The ISecurityContext interface is responsible for defining a security context model. Any implementation of this interface can be used in the framework as Security Context.

Config - The Config class is responsible for obtaining the current MVP configuration (for the model being executed). This class reads this configurations of a XML configuration file.

PresenterBase - The PresenterBase class is the base class of the generic presenter. It has a few base implementations of the main methods, and a few important properties and events.

Presenter<> - The Presenter<> class is the base class from whom all the presenters (all but the Container ones) must inherit, since it allows a type-safe usage of the Model that the presenter is bound to. This class inherits from PresenterBase.

ContainerPresenterBase - The ContainerPresenterBase class is responsible for performing container presenter operations. This is the class that the generic ContainerPresenter inherits from. This class inherits from PresenterBase.

ContainerPresenter<> - The ContainerPresenter<> class is the class from whom all the ContainerPresenter classes must inherit, since it allows a type-safe usage of the Container that the presenter is bound to. This class inherits from ContainerPresenterBase.

ASP.Net Support

UPDATED WIKI: OldFirstPage

Heynemann — Sun, 26 Aug 2007 04:22:06 GMT

Welcome to Project NMVP Framework

News

Date	News
16-Aug-2007	NMVP V1.0.0 is in the Oven - Help out by contributing to it's vision statement at Vision Statement. By the way, 21.000+ visitors to the project and growing. Thanks for the interest guys!
11-Feb-2007	The first three chapters of the book "NMVP Inside-Out" have been released! Make sure you check them out here!
03-Feb-2007	Release 0.3.0 Production is out! This is the release that features both bindable MvpContainer for ASP.Net and the new MockFactory that allows for ZERO-WORK mocking! Be sure to check both out!
03-Feb-2007	Srihari Suresh joined the team! Welcome aboard buddy!
27-Jan-2007	Release 0.2.0 Production is out! It has tons of new features and a tutorial on all of those as well as framework structure explanation will be posted soon. Keep posted!

Showing News 1-5 of 12 - Click here for older news

Staff

Bernardo Heynemann - Coordinator
Márcio Duarte - Developer
Sadek Drobi - Developer
Srihari Suresh - Developer

Intro

Resolver - This is the Dependency Injection container and is responsible for resolving a fully configured and hooked HostPresenter.

Host Presenter - The HostPresenter class is responsible for orchestrating every single other presenter. This is the component that receives the Init, Load and Save calls from the Host (the ASP.Net Page for instance). This class has references to the current Security Context (ISecurityContext), the current Configuration Context (Config) and for the current Transaction Context (used for maintaining the same transaction across different presenter calls).

IHost - The IHost interface is responsible for defining the contract of a Host. This interface contains a property called IsValid that is responsible for telling the HostPresenter the state of validity of the Host.

IContract - The IContract interface defines the contract that the view must implement. Every single interface that views implement MUST inherit from this one.

IContainer - The IContainer interface defines a container. A container is a model that has dynamic models attached to it. Likely this model will be used for multiple relationships like participants on a project, for instance (you don´t know at first hand how many there will be, so you need a dynamic container).

ISecurityContext - The ISecurityContext interface is responsible for defining a security context model. Any implementation of this interface can be used in the framework as Security Context.

Config - The Config class is responsible for obtaining the current MVP configuration (for the model being executed). This class reads this configurations of a XML configuration file.

PresenterBase - The PresenterBase class is the base class of the generic presenter. It has a few base implementations of the main methods, and a few important properties and events.

Presenter<> - The Presenter<> class is the base class from whom all the presenters (all but the Container ones) must inherit, since it allows a type-safe usage of the Model that the presenter is bound to. This class inherits from PresenterBase.

ContainerPresenterBase - The ContainerPresenterBase class is responsible for performing container presenter operations. This is the class that the generic ContainerPresenter inherits from. This class inherits from PresenterBase.

ContainerPresenter<> - The ContainerPresenter<> class is the class from whom all the ContainerPresenter classes must inherit, since it allows a type-safe usage of the Container that the presenter is bound to. This class inherits from ContainerPresenterBase.

ASP.Net Support

UPDATED WIKI: Home

Heynemann — Sun, 26 Aug 2007 04:21:51 GMT

Welcome to Project NMVP Framework

UPDATED WIKI: v10Vision

Heynemann — Fri, 24 Aug 2007 19:20:45 GMT

Version 1.0.0 Vision Statement

Introduction

After several production applications using NMVP we learned some invaluable experience. The most critical points being:

Not every UI wants to SAVE, and still the presenter comes with the Save method bundled. Not every UI needs a HOST and HOST PRESENTER, but again, the presenter has them. This confuses the developers making them use the framework in incorrect ways or worst of all, don't use them for fear to be using incorrectly.
Validation is hard to be done as of today, since NMVP does not help one bit in this as of today. This was very bad since the developers spread the validation logic between the presenter, the view and the domain.
Enabling/Disabling and Showing/Hiding fields is not accomplished correctly with IsReadOnly attribute, since it can only cover the most simple scenarios.
The Web Forms lifecycle makes it HARD on developers to do some trivial tasks, like AJAX. It's been HELL using NMVP with the Microsoft Ajax 1.0 Framework. It came to the point where we had to rewrite some parts of the application just to eliminate MS Ajax, and replace it with a more lightweight approach. I'm not saying it does not work. But it encourages bad behavior.
Devs have a hard time today setting up the NMVP structure, since it still requires a lot of effort to get Contracts, Views, Presenters and Unit Tests off the ground.

We'll approach each of these problems at a time.

Other than these issues, there are some new features that we want to improve on:

MonoRail integration. We are aware that MonoRail is MVC. Even so, we have a vision where both can peacefully coexist, and one from which you can take advantage of what's best in each. This integration will allow a great deal of client-side integration with the MVP lifecycle through AJAX calls.
WebForms better integration. The new features will need to be integrated with web forms. Since NMVP was built essentially to cover up for WebForms flawed SOC model.
Assure Easier Testability - We'll have to choose here to evolve the Testing Infrastructure present in NMVP or simply go with Rhino Mocks, the best Mocking framework around.
Improved Namespace Organization. The namespaces of the NMVP project will probably be reorganized in the sake of clarity.

Backwards Compatibility

This is a major concern for current users of the framework that plan on upgrading to this version: THIS VERSION WILL NOT BE BACKWARDS COMPATIBLE!

After thorough consideration of the pros and cons of this matter, I (Bernardo Heynemann) decided that it's in the best interest of the community to have all projects under the same umbrella and not scattered around like they are.

This means the birth of project Stormwind. NMVP will now be Stormwind.NMvp, Validation Everywhere will be Stormwind.ValEver, and so on...

There will be an identity between the projects that now share the same parent project.

This is a good point for current users of the framework, since you'll be able to keep both versions running in the same project, as they'll have different namespaces, assembly names, assembly versions, and so on.

Stormwind Community

One of the pre-requisites of NMVP Version 1.0.0 is to deploy the Stormwind Community that will feature:

SVN Server for all the projects
Build Server for all the projects
Wiki for the Community and for each project (Project Documentation)
Forum for the Community and for each project
Tracking of bugs and change requests
Allow contribution of patches from the community
Plugin Repository for NMVP. This will allow contribution of plug-ins from the community to be integrated in the NMVP Contrib project.

Read more about it in Stormwind Community.

1 - Presenters

The presenter tree as it is today makes it hard for developers to know when to use each presenter feature. Developers usually get confused on things like:

Why is there a method Save if I don't need to Save anything?
Why is there a Host and HostPresenter if I don't even know what Composite MVP is?
What is a SecurityContext? And a TransactionContext? And a ConfigurationContext?

Those are all valid concerns and ones that will be addressed in the next version of NMVP. We'll be providing a more meaningful tree of presenters for this new release. One that leverages only the features that the user really needs.
The definition for this issue will be in the document Presenter Hierarchy for 1.0.0 Release.

2 - Validation

Validation of user input is a certain part of EVERY UI, so if NMVP is an UI Framework (Both Supervising Presenter and Passive View are UI Design Patterns and both are supported in NMVP), it's appropriate that it helps the user to deal with the Validation of views in a more straightforward way. There are two approaches here: Client-side Validation and Server-Side Validation.

As of today in our production apps we have a hard time finding scenarios where client-side validation would be used alone, since we have an UI requirement of displaying ALL the validation messages to the user together (one message box only with all the messages, or one summary or whatever). I'm not saying this is a MUST have, but it's something, I as an user, like. I don't want to get a message saying that I missed several fields, only to fill them and get another message saying that the customer I'm filling ALL that data for is disabled for operations above USD10K (Server-Side validation).

Even so, we have to catter for both scenarios in the framework, and I do believe that by doing the Server-Side validation correctly we already are, since there are GREAT tools out there to do client-side validation (ASP.Net Validators, MonoRail uses Prototype, JQuery, Ext just to name a few). For Windows Forms there are some good client-side ones, but if you are targeting windows forms as well as ASP.Net I'd go with Server side validation only, since it will make it easier on you to unit test validation logic, and it will get done in one place only. So we'll focus in Server side validation in this release.

If there's one thing that's blurred today in NMVP usage is where do I put my validation logic? From experience developers tend to spread it among layers, so some bits go into the code-behind file, some into the Presenter, some into the Domain classes. The problem with that approach is that it's VERY hard to unit test validation logic if it's done like this. Even if you spread your validation logic between client and server, testing will be harder.

So, our plans for validation is to have a ValidatingPresenter attribute, or a Validate presenter in the hierarchy that will allow validation to be performed.

Server side validation will be present in two ways:

Via attributes in the view Contract (provided by Validation Everywhere)
Via a Validate() method in the presenter, that will get called by the NMVP engine in the case of a validating scenario occur (more about this in the MonoRail and WebForms Integration part of the Vision Statement).

By doing this we are concentrating the Validation of the view's data in one tier only: the MVP Tier. Neither the UI tier, nor the Domain tier have to know about validations performed for the view.

One aspect that is regularly overlooked in several Validation Frameworks is how to return feedback on the validation for the developer, so he can in turn display it to the user. This subject will be dealt with in the WebForms Integration and MonoRail Integration parts of this document.

3 - Fields State Control

Enabling/Disabling and Showing/Hiding fields is a very complex task as of now in NMVP. You never know when to place this logic in the presenter or in the view, or even worse, in both. We learned the hard way that spreading this among both has a very ill effect. You get a lot of unexpected behavior because of the involved parts lifecycle (WebForms vs WinForms, ASP.Net's one, Unit testing frameworks, and so on). This way you disable a field, just to see it enabled in the UI, because in some later time somewhere in the view, the presenter or somewhere else the field got re-enabled. It's really painful to find out where this kind of thing happen.

This seems to be a very trivial thing to pursue, but it's far from that. The most logical place for this kind of logic to be is in the view, but again this has some drawbacks when it comes to testability and a lot of non-trivial issues related to lifecycle, not to mention that some fields state is defined by some domain state, and as such should be defined by the presenter.

Now if this logic is in the presenter, and it's very easy to get why the presenter should handle this, how can he be able to enable/disable/hide/show fields when he doesn't even know what fields are. The presenter is presentation-layer agnostic. He does not know whether the UI is in WebForms or Windows Forms. So how can he perform actions on unkown entities? Our first choice was by contract. So we defined a DisableFields() method in the contract or something like that, and just call it through the presenter if it's needed. The problem with this is that it kinda defeats the state-only contract approach that we favor. And besides, if the disabling logic is in the Presentation tier (the presenter just calls it) you would have a hard time mocking it.

So right now where we stand? Well we still believe that the logic should be in the presenter, but the engine should manage somehow to make it easier on the developer to just disable fields. Something like: DisableFieldOfProperty("CustomerName"), this would disable the field that represents the Contract CustomerName property in the view. The thing here is how would the NMVP engine have knowledge of the fields in the view.

*This item is still under study, but MUST be solved by release 1.0.0.

4 - MonoRail Integration

We had a hard time in all our projects due to the WebForms life cycle. Plugging the NMVP Lifecycle (much smaller than WebForms') in the WebForms' one was really painful. Even worse, our developers made several mistakes due to how complex all the structure became. The customer wanted his forms to be full AJAX, so the picture became even uglier, since we decided at the time to go with Microsoft Ajax 1.0, which encourages several worst practices.

After a lot of pain we decided that we had to look around for better solutions (or build one). We were very thrilled when we found out how advanced MonoRail was. I knew the Castle Project from way back, since NMVP is built on top of Windsor, but finding out about ActiveRecord and MonoRail was really a blessing.

One of the best features of MonoRail for me is allowing the user to access a method in the controller (an action that renders a view) via it's URL. This is insanely useful on the AJAX scenario, as we really want our JavaScript code to call on the controller for any AJAX call (since the Controller is easily testable).

Another great improvement is on the View Engines that make it a LOT easier to maintain pages. I wrote an entry on my blog about it here. The ViewComponents and Helpers are also a great addition to our toolbox.

The only thing we missed in MonoRail is the contract-based approach enforced by NMVP. We learned with our teams that contract-based development really improved the way we build software in a way that we now can develop against a typed contract and not a ViewState or PropertyBag collection. I know that the web is stateless, and all you get from each Request is an HTTP message, but it's nice to have it all sorted out for me BEFORE reaching the UI logic. That's where NMVP will come on top of MonoRail.

We're planning on having two special controllers: RegularController and CompositeController, responsible for, respectively, Model-View-Presenter support and Composite Model-View-Presenter Support (you can learn more about CMVP in this wiki or in my book - the draft is in my blog).

We are planning some nice features for MonoRail integration:

"Automagically" created client-side functions that hook on:

NMVP Validation Engine
NMVP Security Context
NMVP Persistence Engine
NMVP Custom Plug-ins

Composeability of Views via CompositeController and Host.vm (view that will contain render views for all the children views).
Helpers for NMVP related tasks (still to be decided).
ViewComponents to help using NMVP container.

The MonoRail integration is detailed in another vision statement for V1.0.0 - MonoRail Integration Version 1.0.0 Vision Statement.

Essentially we'll have to provide some work-around to be able to provide the same things (given the constraints) to WebForms. This integration is detailed in another vision statement for V1.0.0 - WebForms Integration Version 1.0.0 Vision Statement.

Feedback

We need your feedback to be able to provide a better solution to real problems. Help us help you! We're eager to hearing from you in the discussion forums.

UPDATED WIKI: v10Vision

Heynemann — Fri, 24 Aug 2007 19:19:03 GMT

Version 1.0.0 Vision Statement

Introduction

After several production applications using NMVP we learned some invaluable experience. The most critical points being:

Not every UI wants to SAVE, and still the presenter comes with the Save method bundled. Not every UI needs a HOST and HOST PRESENTER, but again, the presenter has them. This confuses the developers making them use the framework in incorrect ways or worst of all, don't use them for fear to be using incorrectly.
Validation is hard to be done as of today, since NMVP does not help one bit in this as of today. This was very bad since the developers spread the validation logic between the presenter, the view and the domain.
Enabling/Disabling and Showing/Hiding fields is not accomplished correctly with IsReadOnly attribute, since it can only cover the most simple scenarios.
The Web Forms lifecycle makes it HARD on developers to do some trivial tasks, like AJAX. It's been HELL using NMVP with the Microsoft Ajax 1.0 Framework. It came to the point where we had to rewrite some parts of the application just to eliminate MS Ajax, and replace it with a more lightweight approach. I'm not saying it does not work. But it encourages bad behavior.
Devs have a hard time today setting up the NMVP structure, since it still requires a lot of effort to get Contracts, Views, Presenters and Unit Tests off the ground.

We'll approach each of these problems at a time.

Other than these issues, there are some new features that we want to improve on:

MonoRail integration. We are aware that MonoRail is MVC. Even so, we have a vision where both can peacefully coexist, and one from which you can take advantage of what's best in each. This integration will allow a great deal of client-side integration with the MVP lifecycle through AJAX calls.
WebForms better integration. The new features will need to be integrated with web forms. Since NMVP was built essentially to cover up for WebForms flawed SOC model.
Assure Easier Testability - We'll have to choose here to evolve the Testing Infrastructure present in NMVP or simply go with Rhino Mocks, the best Mocking framework around.
Improved Namespace Organization. The namespaces of the NMVP project will probably be reorganized in the sake of clarity.

Backwards Compatibility

Stormwind Community

One of the pre-requisites of NMVP Version 1.0.0 is to deploy the Stormwind Community that will feature:

SVN Server for all the projects
Build Server for all the projects
Wiki for the Community and for each project (Project Documentation)
Forum for the Community and for each project
Tracking of bugs and change requests
Allow contribution of patches from the community
Plugin Repository for NMVP. This will allow contribution of plug-ins from the community to be integrated in the NMVP Contrib project.

Read more about it in Stormwind Community.

1 - Presenters

The presenter tree as it is today makes it hard for developers to know when to use each presenter feature. Developers usually get confused on things like:

Why is there a method Save if I don't need to Save anything?
Why is there a Host and HostPresenter if I don't even know what Composite MVP is?
What is a SecurityContext? And a TransactionContext? And a ConfigurationContext?

2 - Validation

Via attributes in the view Contract (provided by Validation Everywhere)
Via a Validate() method in the presenter, that will get called by the NMVP engine in the case of a validating scenario occur (more about this in the MonoRail and WebForms Integration part of the Vision Statement).

By doing this we are concentrating the Validation of the view's data in one tier only: the MVP Tier. Neither the UI tier, nor the Domaing tier have to know about validations performed for the view.

One aspect that is regularly overlooked in several Validation Frameworks is how to return feedback on the validation for the developer, so he can in turn display it to the user. This subject will be dealt with in the WebForms Integration and MonoRail Integration parts of this document.

3 - Fields State Control

4 - MonoRail Integration

"Automagically" created client-side functions that hook on:

NMVP Validation Engine
NMVP Security Context
NMVP Persistence Engine
NMVP Custom Plug-ins

Composeability of Views via CompositeController and Host.vm (view that will contain render views for all the children views).
Helpers for NMVP related tasks (still to be decided).
ViewComponents to help using NMVP container.

Feedback

We need your feedback to be able to provide a better solution to real problems. Help us help you! We're eager to hearing from you in the discussion forums.

UPDATED WIKI: v10Vision

Heynemann — Fri, 24 Aug 2007 19:16:58 GMT

Version 1.0.0 Vision Statement

Introduction

After several production applications using NMVP we learned some invaluable experience. The most critical points being:

Not every UI wants to SAVE, and still the presenter comes with the Save method bundled. Not every UI needs a HOST and HOST PRESENTER, but again, the presenter has them. This confuses the developers making them use the framework in incorrect ways or worst of all, don't use them for fear to be using incorrectly.
Validation is hard to be done as of today, since NMVP does not help one bit in this as of today. This was very bad since the developers spread the validation logic between the presenter, the view and the domain.
Enabling/Disabling and Showing/Hiding fields is not accomplished correctly with IsReadOnly attribute, since it can only cover the most simple scenarios.
The Web Forms lifecycle makes it HARD on developers to do some trivial tasks, like AJAX. It's been HELL using NMVP with the Microsoft Ajax 1.0 Framework. It came to the point where we had to rewrite some parts of the application just to eliminate MS Ajax, and replace it with a more lightweight approach. I'm not saying it does not work. But it encourages bad behavior.
Devs have a hard time today setting up the NMVP structure, since it still requires a lot of effort to get Contracts, Views, Presenters and Unit Tests off the ground.

We'll approach each of these problems at a time.

Other than these issues, there are some new features that we want to improve on:

MonoRail integration. We are aware that MonoRail is MVC. Even so, we have a vision where both can peacefully coexist, and one from which you can take advantage of what's best in each. This integration will allow a great deal of client-side integration with the MVP lifecycle through AJAX calls.
WebForms better integration. The new features will need to be integrated with web forms. Since NMVP was built essentially to cover up for WebForms flawed SOC model.
Assure Easier Testability - We'll have to choose here to evolve the Testing Infrastructure present in NMVP or simply go with Rhino Mocks, the best Mocking framework around.
Improved Namespace Organization. The namespaces of the NMVP project will probably be reorganized in the sake of clarity.

Backwards Compatibility

Stormwind Community

One of the pre-requisites of NMVP Version 1.0.0 is to deploy the Stormwind Community that will feature:

SVN Server for all the projects
Build Server for all the projects
Wiki for the Community and for each project (Project Documentation)
Forum for the Community and for each project
Tracking of bugs and change requests
Allow contribution of patches from the community
Plugin Repository for NMVP. This will allow contribution of plug-ins from the community to be integrated in the NMVP Contrib project.

Read more about it in Stormwind Community.

1 - Presenters

The presenter tree as it is today makes it hard for developers to know when to use each presenter feature. Developers usually get confused on things like:

Why is there a method Save if I don't need to Save anything?
Why is there a Host and HostPresenter if I don't even know what Composite MVP is?
What is a SecurityContext? And a TransactionContext? And a ConfigurationContext?

2 - Validation

Validation of user input is a certain part of EVERY UI, so if NMVP is an UI Framework (Both Supervising Presenter and Passive View are UI Design Patterns and both are supported in NMVP), it's appropriate that it helps the user to deal with the Validation of views in a more straightforward way. There are two approaches here: Client-side Validation and Server-Side Validation.

As of today in our production apps we have a hard time finding scenarios where client-side validation would be used alone, since we have an UI requirement of displaying ALL the validation messages to the user together (one message box only with all the messages, or one summary or whatever). I'm not saying this is a MUST have, but it's something, I as an user, like. I don't want to get a message saying that I missed several fields, only to fill them and get another message saying that the customer I'm filling ALL that data for is disabled for operations above USD10K (Server-Side validation).

Even so, we have to catter for both scenarios in the framework, and I do believe that by doing the Server-Side validation correctly we already are, since there are GREAT tools out there to do client-side validation (ASP.Net Validators, MonoRail uses Prototype, JQuery, Ext just to name a few. For Windows Forms there are some good client-side ones, but if you are targeting windows forms as well as ASP.Net I'd go with Server side validation only, since it will make it easier on you to unit test validation logic, and it will get done in one place only). So we'll focus in Server side validation in this release.

If there's one thing that's blurred today in NMVP usage is where do I put my validation logic? From experience developers tend to spread it among layers, so some bits go into the code-behind file, some into the Presenter, some into the Domain classes. The problem with that approach is that it's VERY hard to unit test validation logic if it's done like this. Even if you spread your validation logic between client and server, testing will be harder.

So, our plans for validation is to have a ValidatingPresenter attribute, or a Validate presenter in the hierarchy that will allow validation to be performed.

Server side validation will be present in two ways:

Via attributes in the view Contract (provided by Validation Everywhere)
Via a Validate() method in the presenter, that will get called by the NMVP engine in the case of a validating scenario occur (more about this in the MonoRail and WebForms Integration part of the Vision Statement).

3 - Fields State Control

4 - MonoRail Integration

"Automagically" created client-side functions that hook on:

NMVP Validation Engine
NMVP Security Context
NMVP Persistence Engine
NMVP Custom Plug-ins

Composeability of Views via CompositeController and Host.vm (view that will contain render views for all the children views).
Helpers for NMVP related tasks (still to be decided).
ViewComponents to help using NMVP container.

Feedback

We need your feedback to be able to provide a better solution to real problems. Help us help you! We're eager to hearing from you in the discussion forums.

UPDATED WIKI: v10Vision

Heynemann — Fri, 24 Aug 2007 19:13:33 GMT

Version 1.0.0 Vision Statement

Introduction

After several production applications using NMVP we learned some invaluable experience. The most critical points being:

Not every UI wants to SAVE, and still the presenter comes with the Save method bundled. Not every UI needs a HOST and HOST PRESENTER, but again, the presenter has them. This confuses the developers making them use the framework in incorrect ways or worst of all, don't use them for fear to be using incorrectly.
Validation is hard to be done as of today, since NMVP does not help one bit in this as of today. This was very bad since the developers spread the validation logic between the presenter, the view and the domain.
Enabling/Disabling and Showing/Hiding fields is not accomplished correctly with IsReadOnly attribute, since it can only cover the most simple scenarios.
The Web Forms lifecycle makes it HARD on developers to do some trivial tasks, like AJAX. It's been HELL using NMVP with the Microsoft Ajax 1.0 Framework. It came to the point where we had to rewrite some parts of the application just to eliminate MS Ajax, and replace it with a more lightweight approach. I'm not saying it does not work. But it encourages bad behavior.
Devs have a hard time today setting up the NMVP structure, since it still requires a lot of effort to get Contracts, Views, Presenters and Unit Tests off the ground.

We'll approach each of these problems at a time.

Other than these issues, there are some new features that we want to improve on:

MonoRail integration. We are aware that MonoRail is MVC. Even so, we have a vision where both can peacefully coexist, and one from which you can take advantage of what's best in each. This integration will allow a great deal of client-side integration with the MVP lifecycle through AJAX calls.
WebForms better integration. The new features will need to be integrated with web forms. Since NMVP was built essentially to cover up for WebForms flawed SOC model.
Assure Easier Testability - We'll have to choose here to evolve the Testing Infrastructure present in NMVP or simply go with Rhino Mocks, the best Mocking framework around.
Improved Namespace Organization. The namespaces of the NMVP project will probably be reorganized in the sake of clarity.

Backwards Compatibility

Stormwind Community

One of the pre-requisites of NMVP Version 1.0.0 is to deploy the Stormwind Community that will feature:

SVN Server for all the projects
Build Server for all the projects
Wiki for the Community and for each project (Project Documentation)
Forum for the Community and for each project
Tracking of bugs and change requests
Allow contribution of patches from the community
Plugin Repository for NMVP. This will allow contribution of plug-ins from the community to be integrated in the NMVP Contrib project.

Read more about it in Stormwind Community.

1 - Presenters

The presenter tree as it is today makes it hard for developers to know when to use each presenter feature. Developers usually get confused on things like:

Why is there a method Save if I don't need to Save anything?
Why is there a Host and HostPresenter if I don't even know what Composite MVP is?
What is a SecurityContext? And a TransactionContext? And a ConfigurationContext?

2 - Validation

Validation of user input is a certain part of EVERY UI, so if NMVP is an UI Framework (MVP is an UI Design Pattern), it's appropriate that it helps the user to deal with the Validation of views in a more straightforward way. There are two approaches here: Client-side Validation and Server-Side Validation.

As of today in our production apps we have a hard time finding scenarios where client-side validation would be used alone, since we have an UI requirement of displaying ALL the validation messages to the user together (one message box only with all the messages, or one summary or whatever). I'm not saying this is a MUST have, but it's something, I as an user, like. I don't want to get a message saying that I missed several fields, only to fill them and get another message saying that the customer I'm filling ALL that data for is disabled for operations above USD10K (Server-Side validation).

Even so, we have to catter for both scenarios in the framework, and I do believe that by doing the Server-Side validation correctly we already are, since there are GREAT tools out there to do client-side validation (ASP.Net Validators, MonoRail uses Prototype, JQuery, Ext just to name a few. For Windows Forms there are some good client-side ones, but if you are targeting windows forms as well as ASP.Net I'd go with Server side validation only, since it will make it easier on you to unit test validation logic, and it will get done in one place only). So we'll focus in Server side validation in this release.

If there's one thing that's blurred today in NMVP usage is where do I put my validation logic? From experience developers tend to spread it among layers, so some bits go into the code-behind file, some into the Presenter, some into the Domain classes. The problem with that approach is that it's VERY hard to unit test validation logic if it's done like this. Even if you spread your validation logic between client and server, testing will be harder.

So, our plans for validation is to have a ValidatingPresenter attribute, or a Validate presenter in the hierarchy that will allow validation to be performed.

Server side validation will be present in two ways:

Via attributes in the view Contract (provided by Validation Everywhere)
Via a Validate() method in the presenter, that will get called by the NMVP engine in the case of a validating scenario occur (more about this in the MonoRail and WebForms Integration part of the Vision Statement).

3 - Fields State Control

4 - MonoRail Integration

"Automagically" created client-side functions that hook on:

NMVP Validation Engine
NMVP Security Context
NMVP Persistence Engine
NMVP Custom Plug-ins

Composeability of Views via CompositeController and Host.vm (view that will contain render views for all the children views).
Helpers for NMVP related tasks (still to be decided).
ViewComponents to help using NMVP container.

Feedback

We need your feedback to be able to provide a better solution to real problems. Help us help you! We're eager to hearing from you in the discussion forums.