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.

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 Version 1.0.0 Vision Statement.

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.

More on Validation in the Validation Version 1.0.0 Vision Statement.

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.

Read more about it at the Field State Control Version 1.0.0 Vision Statement.

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.

4 - WebForms Integration

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.

5 - Unit Testing Integration

At release 1.0.0 we are aiming for a seamless integration with NUnit in a way that really estimulates the user of the framework to create unit tests. At this point we are not sure of how to improve on the unit testing process, but using Fitnesse might be the way to go, since what I'm aiming for in unit test integration is something like:

  Fill CustomerDetails.Name with "Bernardo Heynemann".
  Fill CustomerDetails.Age with "25".
  //other customer details.
  Insert CustomerAddress.
  Fill CustomerAddress[0].Street with "The Street Where You Live".
  //other customer address details.
  Insert CustomerAddress.
  Fill CustomerAddress[1].Street with "The Long and Winding Road".
  //other customer address details.
  Fill CustomerCreditCard.Type with "MasterCard".
  Fill CustomerCreditCard.Number with "1111111111111".
  Fill CustomerCreditCard.Expiration with "12/12/2010".
  Save the Customer.
  Assert Validation.
  Assert InstanceId is not 0.

Now this is an unit test I'd like to have. Maybe we'll come to that eventually. More on the Unit Testing Integration in Unit Testing 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 or in the NMVP mailing list.