while(availableTime>0) {

NMVP Version 1.0.0 - HERE IT COMES!!!

For you guys that helped us improve the NMVP Framework so far, GREAT NEWS! We are writing the specs for V1.0.0 of the Framework. The vision statement can be found here, so I urge you guys to help us help you. I'd like to discuss some points of the vision statement here, though.

First I'd like to talk about Backwards Compatibility. Yes, I know, you all want it to play nice and stuff, but this time I just can't cut it. Backwards compatibility would hinder our ability to do a lot of really COOL stuff, so we decided to forget about it.

Even more, we decided on making it completely incompatible. We are changing namespaces to Stormwind. Stormwind is the name of the project that will "glue" all the other projects together. So far I haven't really committed on making my projects behave nicely together. This is really a shame, and something that I will fix in the future, I promise. Some that I envision in the Stormwind Umbrella:

1. NMVP - UI Logic
2. Validation Everywhere - Validation of User Input
3. Stormwind Reports - Reporting
4. Digital Fortress - Security

With these four projects integrated you'd cover a GREAT ground in application development, and that's my goal. Lowering our barriers. Enhancing the quality of our code without sacrificing the quality and maintainability of it.

Today they aren't integrated. Hell, Stormwind Reports and Digital Fortress aren't even released. So there is still a lot of ground to cover, but right now I want to focus in the more mature ones - NMVP and Validation Everywhere.

The reason we decided on changing namespaces, assembly names, assembly versions and anything we can is that you guys can use both NMVP old version in stuff you already built, and NMVP 1.0.0 on new stuff that you build after release 1.0.0.

Second, I'd like to talk about Validation. NMVP does nothing out of the box to help you with validation. This is just not acceptable, since Validation of user input is a primary concern of EVERY UI and being an UI framework NMVP can't just ignore this responsibility.

This is where the Stormwind Umbrella pays off. We'll be integrating as a first-class citizen Validation Everywhere in NMVP. It's a full featured Validation Framework as of today, with Validation via Container of via Attributes. It's highly customizable and VERY Extensible. It comes with several validators out of the box in the current version. We are planning on some more for v1.0.0, but that's another post.

Now there's the part I'm most excited about. I'll quote the vision statement as it is today:

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.
It's still to be decided whether we'll be using the Decorator Design Pattern or implementing a new hierarchy of presenters. We are leaning more to the Decorator side as of now, since it would allow us a much smoother evolution of the framework's presenter capabilities than the hierarchical form.

Decorator Design Pattern (Through attributes)

Advantages

1. More flexibility, since the developer can choose exactly which features to increment his presenter with.
2. Easily add new features to the presenter structure without breaking existing codebase.
3. Easily add custom features to the presenter through user custom presenter plug-ins, registered with NMVP Engine.

Disadvantages

1. No compile-time support, since the attributes will only be read by the NMVP engine at runtime.
2. Methods used by each attribute aren't just overrides, so they have to be convention-named (i.e. Validate()).
3. Can be somewhat misleading if users start to place business logic into plug-ins.
4. Still unclear if this affects testability.

Sample Code (just to illustrate)

  [PersistencePresenter]
  [ValidatingPresenter]
  [SecurityEnabledPresenter]
  public class CustomerDetailsPresenter : Presenter<ICustomerDetails>{
    //regular presenter implementation...
 
    public void Save(){
      //Save logic in here...
    }
 
    public bool Validate(){
      //Validation logic in here...
    }
 
    private SecurityContext securityContext;

    //This will be filled automatically by NMVP because of the SecurityEnabledPresenter attribute.
    public SecurityContext SecurityContext{
      get { return securityContext; }
      set { securityContext = value; }
    }
  }

As it's clear from the code above, the methods have their names via convention, and thus if you spell then wrong or anything (different parameters, different access) you won't notice it until runtime, which is really not good. Note that the actual decoration involved with the pattern (composing presenters) would be performed by the NMVP Engine, so no trouble there.

New Hierarchy

Advantages

1. Compile-time support, so when the users need to know what methods they can override it's easier.

Disadvantages

1. Can be misleading as well if users don't want to use all methods that a given level of the hierarchy offers.
2. Very hard to build a hierarchy that covers all combinations, and each time a new feature is included, this becomes even harder (N*N-1).

Sample Code (just to illustrate)

  public class CustomerDetailsPresenter 
                           : ValidatingPersistentSecurePresenter<ICustomerDetails> { //See how hard it is?
    //regular presenter implementation...
 
   protected override void SaveCore(){
      //Save logic in here...  This method will get called when the user 
      //of this presenter calls Save. This is how it's done today.
    }
 
    protected override bool ValidateCore(){
      //Validation logic in here... This method will get called when the user 
      //of this presenter calls Validate. This is how it's done today.
    }
  }

Enhancing the presenters means enhancing the Framework User Experience, and thus lowering the entry barrier that exists today for NMVP. This is something I'm willing to invest my time in. I would like very much to hear your thoughts on this subject.

Then there's the UI support for the new features. This time we'll be supporting another web environment: MonoRail. I really advise you to check it out. It's a REALLY cool project by Hamilton Veríssimo (and team) and one that we plan on adopting as our company's standard, over WebForms. I blogged about it just last time, so I won't enter in much detail here. Check the vision statement for more detail.

I know you're worried right now that we won't support WebForms anymore. Don't worry. NMVP will continue to support WebForms as we'll support anything we can. There are already plans on building similar infrastructures for Windows Forms and WPF.

I'd like to add that we still have undecided parts of the vision statement, so help us out. Take some time to read it, comment on it, suggest improvements, suggest stuff that you'd like to see in the 1.0.0 release of NMVP. Make a difference.

I hope to be hearing a lot of stuff really soon!

#110