What I find particularly interesting with this graph is convergence. PHP is losing its footing as the top dog as the one and only web development language. This preliminary glance into technology popularity doesn't factor "Zend", "Ruby on Rails" and "ASP.NET", which are the framework counterparts that make "PHP", "Ruby" and "C#" suited for enterprise web development.

The state-by-state breakdown is even more peculiar. In every US state except for Washington, PHP is the dominant search keyword. In Washington, it's C#:

If I was an ASP.NET developer, or someone trying to market ASP.NET products, I know I'd start in Washington. Take a look at the full data at Google Trends.

Now this is where the clincher is: Rails is a Ruby FRAMEWORK and yet, the hosting provider gets to pick which version I'm running. Obviously, this leads to a forced migration in a production environment. If they decided to upgrade the Ruby language processor it would be a different story. It seems like the Rails team didn't take a hint from the abomination that was PEAR / PECL due to hosting providers bearing the responsibility of versioning what were essentially early extensions of the PHP language.

Why can't I run my own Rails instance? Well hosting providers are being sold on mod_ruby which is really mod_rails. That's like your hosting provider installing mod_zend_framework and then getting to pick the version as it comes out. Let's not forget that four years ago, Zend didn't exist and Rails was a pet project by an young, but innovative group soon to be known to the world as 37Signals.

What bothers me is that this application is a little over a year old and due to the naming changes in the Rails tree (without graceful failures for deprecated functionality) I'm stuck hunting down why each controller is failing. Thankfully, if you're clever in ASP.NET, you can include a lib/ folder with any binaries required for compilation, and the codebase has matured to the point that migrations only occur at the *.5 release. You have to give Microsoft credit for not breaking backwards compatibility as well. As much as they get burned in the browser wars for this reason, it does mean that you're not forced to unravel the cobwebs on a deployed application and spend a week debugging it after 13 months!

While PHP 5.3 is offering some radical enhancements (like namespaces!) to the PHP language, they're at least waiting until 6.x before dropping some of the painful design decisions (like magic quotes etc...) that were made what is forever (more than 2 years!) by web development standards.

Ultimately, having an Apache module design to work with a specific version of a framework sounds like a mix of concerns. Why does the webserver module need to know the details of how Rails handles it's templating engine, or how it dispatches requests? Why is it so bloody complicated to get standardized rails hosting? Why do people develop in webrick, deploy using FastCGI and then have to deal with mod_ruby.

My suggestion is either buy your own machine, get virtual hosting environment, or wait until the dust settles and a unified development / testing / production environment presents itself.

The Purpose
As forms become more complex, there is greater incentive to minimize trips to the server. Furthermore, ASP.NET doesn't play nice with dynamically generated controls (something that occurs with any moderate AJAX development. The following is a way of utilizing the tools in the Microsoft ASP.NET framework without rewriting key components (for an example of this, look at the MonoRail project or the new Microsoft MVC framework).

In the Microsoft camp, usually you're encouraged to use validators that let act as decorators to existing ASP.NET textboxes and other form elements. To make matters more complicated, the Patterns and Practices group as well as the AJAX.NET group in Microsoft have competing components for dealing with client-side validation.

I propose a third method that employs a webservice and allows you to dynamically generate your validation through an asynchronous postback of your form to the server. I've been testing this approach and I've been pretty successful thus far:

On Using a Data Transfer Object (DTO)
A Data Transfer object is simply a container where you can store a collection of variables in an organized manner. A DTO doesn't have any behaviour, just public properties. For example, an Employee object might have the following properties:

	Employee employee = EmployeeRepository.GetNewEmployee();
	employee.HiredAt = DateTime.Now();
	employee.Position = "Sales Manager";
	employee.OfficeExtension = 4556;

To simplify things, I use Castleproject's ActiveRecord libraries to create a simple relationship between my database tables and my DTO's.

I've broken down the requests in terms of a linear timeline of events on the page.

Why Bother Mapping to a Data Transfer Object?
The Microsoft Enterprise Library enables you to decorate public properties (as well as methods) with validators. Furthermore, you create custom validators and include them in the same infrastructure that Microsoft provides for its own validators.

1) The page is rendered and delivered to the client's browser: for the most part, it's just a plain old aspx page. However, I've made certain minor modifications that help later on in the dynamic mapping of a DTO from the form back to the server:

A form element looks something like this:

 
	<ASP:TextBox id="tbEmployeePosition" dto="Employee" property="Position" runat="server" />
 

In my form, I've provided two attributes, dto and property, which can be used on in the web service to dynamically map the form elements back to the DTO for validation.

2) Use a fake button to post the form asynchronously to a webservice in your project: all the latest javascript frameworks (my personal favourite is Prototype) support form serialization through utility of helper methods (see $F() in prototype). The JSON object you want to send to the webservice might look like this:

 
{ "EmployeeForm" :
    [
	[ "id" : "aspnet_dynamic_form_tbEmployeePosition"]
	[ "value" : "Sales Manager"]
	[ "property" : "Position"]
	[ "dto" : "Employee"]
     ]
 
    [
	[ "id" : "aspnet_dynamic_form_tbEmployeeOfficeExtension"]
	[ "value" : "4556"]
	[ "property" : "OfficeExtension"]
	[ "dto" : "Employee"]
     ]
}
 

3) The Mapping Layer grabs a DTO from the Repository and maps the values using the Data from the JSON posted to the webservice: it's very easy to take this data and, using the PropertyInfo class and a bit of type checking, map these values to a DTO. Once their mapped, you can easily run Entlib Validation.

4) The ValidationManager validates the DTO, collects the EntLib Validation messages in a Hashtable: The Hashtable can have a key / value pair with the submitted form element's ID and the error message associated with the invalid element. Error messages are pulled from the MessageTemplate field in your validator's, whether you're adding attributes, or adding validation through your web.config.

5) The Hashtable is returned to the client: Microsoft's webservices don't support Hashtables natively, however you can get around this by creating an ArrayList containing string[] objects.

6) The values are inserted back onto the form: with a Hashtable containing element ID's and their respective messages, it becomes trivial to add these server-side messages to the client-side. In Prototype, it's a matter of Element.insert( responseJSON[i][0] , { "after" : "<span class='error'>"+responseJSON[i][1] + "</span>" }); where i corresponds with to the message in the list, 0 is the client's element ID and 1 is the message.

7) The Form is automatically submitted to the server if the form is valid: if responseJSON is empty, we simply fire the .click(); on the ASP.NET textbox as though the user did it himself. This means keeping track of the ASP.NET prefix which is added on all IDs that have the runat="server" directive.

The beauty of this approach is that it's highly extensible, you could serialize and post any part of your form if you needed to. Furthermore, the mapping that happens when the actual form controls are posted to the server would be nearly identical and the validation would be consolidated into one place. Lastly, you could provide the same error messages on server-side postback of the form (however it would be a little tricky to make them display as easily as it is with the web service.

I'll be providing a Zend sample of this in the week to come.

Download Ajax Auto Completer Sample ASP.NET project

For example, take a look at line 301 of autocompleter.js:

 
  choicesToHtml : function(choices)
  {
    var output = "
<ul>";
        for (i=0; i< choices.length; i++)
            output = output + "
<li>" + choices[i] + "</li>
 
";
 
    return output + "</ul>
 
";
  }
 

Because you're actually pulling data from the web service, it would be easy to extend this example to provide a fully nested JSON object with images etc... as part of the auto-completer. I'll provide such an example with the Zend Framework and it's web service components at a later date, however being able to serialize a data structure like the one below would be perfect for an auto-completion web service.

 
 {
     "headerText": "SearchBox Header Text",
     "searchCollection": [
    "searchResult" : {
        "imageSource" : "product.gif",
        "text" : "my product text",
        "url" : "http://linkToMyProduct/"
    },
    "searchResult" : {
        "imageSource" : "product.gif",
        "text" : "my product text",
        "url" : "http://linkToMyProduct/"
    },
    "searchResult" : {
        "imageSource" : "product.gif",
        "text" : "my product text",
        "url" : "http://linkToMyProduct/"
    },
    "searchResult" : {
        "imageSource" : "product.gif",
        "text" : "my product text",
        "url" : "http://linkToMyProduct/"
    },
     ],
     "headerText": "SearchBox Footer Text"
 }
 

While I have excellent unix-based hosting, I unfortunately don't have an external IIS server that I can publish this out.

What seems to have been a requirement for contemporary Ruby / Python / PHP developers has really hit home with the C# web development community. It seems that two camps within Microsoft are pushing MVC (Model-View-Controller) and MVP (Model-View-Presenter) separately and simultaneously. On top of that, the confusion is being fanned out on blogs rather than through official testimonies from Microsoft. Developers are now stuck doing a ton of research with the hopes that one of these patterns will lead to "best practices" for the future.

I've listed out the three ASP.NET development approaches I've recently encountered.

• Codebehind development - this is the 2.x and 1.1x ASP.NET development model. Essentially the events and the business logic are stored in the code-behind. A lot of developers using ASP.NET still develop using this approach since the pre-compiled user controls lend themselves to direct data binding.
• Patterns & Practices MVP - The Microsoft Patterns & Practices group have been development application blocks, essentially, these are high-level development libraries that encourage developers to invest more time writing business-specific code. The application blocks that I've found particular cool are Validation, Logging and Exception Handling. This same group has been pushing "guidance packages", a bunch of recipes that facilitate a module-based development paradigm.
• MVC ASP.NET - Scott Guthrie, lead developer on the original ASP.NET architecture has been pushing for an MVC framework that closely resembles Zend and Rails.

Interestingly enough, the last two pattern approaches infringe on a lot of independent development.

In terms of a working MVC approach, Castleproject's Monorails has been a working implementation with a strong community for some time. However, now that Microsoft has decided to re-engineer this pattern, only time will tell if the Monorails community will be forced into jumping ship; a sad reality that developers in that community have been frequently faced with.

Phil Haack (Blog), Jean-Paul S. Boodhoo (MSDN magazine 2006), David Hayden (Blog) and Billy McCafferty (Codeproject) have all offered up sample projects around the MVP paradigm. While all of them are absolutely fascinating to the nerdy developer, they all quietly omit validation and how it affects how events fire on a page.

The MVP pattern, while being an evolution on MVC, seems to shine when unit testing is at the core of the development approach. Furthermore, because of the event-driven model, the presenter seems like a logical place to begin development. Mocking frameworks like NMock and Ayende's RhinoMock facilitate the isolation of a real persistence layer from DTO's (Data Transfer Objects) being pushed up from a Repository.

Microsoft seems to have missed the boat in the Patterns and Practices group for three reasons:

• The PnP tests that come with the sample projects incorporate methods that encourage the instantiation of a full-stack web server. This approach fundamentally breaks the notion of a Separation of Concerns since the presenter should be fully working without a web server.
• MVP really shines when TDD is applied to the development of the Domain, however with the recipes in place, a developer is more likely to start with a recipe and flush out code for the Presenter directly, essentially falling back on a waterfall development approach.
• The MVP sample circumvents the ugly fact that user controls have become too intelligent. Web Controls in ASP.NET implement appearance, events, data and validation. Luckily in ASP.NET 2.0, appearance has been isolated through the use of Skins, however events, data and validation are still managed in a similar manner. MVP, as I understand it, dictates that events are managed by the presenter, however the MVP sample projects attempt to hide the uglyness of the high-level data binding in Controllers! How could the terminology for these patterns become anymore confusing?

Welcome ASP.NET MVC

What appears to be a Microsoft implementation of Zend / Rails seems to have missed out on the issues that lie dormant in the MVC pattern that MVP has attempted to address.

Where does validation go?
Validation is a terrible word. It refers to data integrity at the persistence level, it refers to user submissions, security contexts and sometimes it's confused with business rules. All of these are different concerns that a web application has to deal with and to be honest, I haven't found a pattern that even attempts to handle all these different aspects of validation in a coherent, systematic and discrete manner.

How are business rules delegated?
Business rules belong in the domain of an application. The issue here is that business rules, being specific to a business, don't really fit into the typical "lets make a blog application in 10 minutes" approach to development. They are crafted in an iterative manner through discussions with the client, and as such, they also tend to disappear from any sample patterns or applications I've come across.

How should you handle AJAX calls to a controller?
My own thinking here is that a presenter architecture shouldn't care whether the event fired is from an AJAX request or a POSTback on a form. The IView should be passed in with the event firing and so the modifications that the presenter handles can be localized to the interface it receives.

I find it particular curious that the developers in PnP have decided to omit their own implementation of the Entlib Validation Framework in their MVP project. Ultimately, I think that Fowler might have been onto something when he said that MVP should be split into two separate patterns, Supervising Controller and Passive View.

Technology aside, I think Derek Greer has put together a fantastic history of MVP and MVC that's worth looking at, regardless of which technologies you're advocating and which patterns you've been committed to implementing.

If anyone out there has answers to these questions, I've been searching hard to come up with a good implementation of these concepts, regardless of economic interest.