Jay Harris is Cpt. LoadTest

On Tuesday, February 9th, I was scheduled lead a jam session for Come Jam With Us, the software developer study group in Ann Arbor. The session was to be on ASP.NET MVC 2, aimed to give attendees enough of an introduction to the product to empower developers to be able to start coding their own ASP.NET MVC 2 projects. Unfortunately, Mother Nature did not cooperate that day, half of the state of Michigan seemingly shut down under 8" of snow, and the session was cancelled and rescheduled for February 23rd. The goal of these Learn to Code exercises is to give you an introduction to building applications with ASP.NET MVC 2. In the near future, I also hope to provide a screen cast of these same exercises.

About this Exercise

This coding exercise is designed to give you an introduction to ASP.NET MVC 2. In this exercise, developers will create their first database-driven ASP.NET MVC 2 application within Visual Studio, primarily using code generation built in to Visual Studio. Developers performing this exercise should be familiar with ASP.NET development and Visual Studio, but no previous experience with ASP.NET MVC is required.

Prerequisites

You will need few things for ASP.NET MVC 2 application development and to complete these exercises. Please complete the following prerequisites prior to moving on. The session is designed to be completed in about an hour, but prerequisite setup is not included in that time.

• Install Microsoft Visual Studio 2008 SP1 or Visual Web Developer 2008 Express with SP1
• Install Microsoft SQL Server or SQL Server Express
• Download and install the latest ASP.NET MVC 2 RC 2 bits from Microsoft

Exercise 0: Getting Started

Creating a Project

Before any coding can occur, the first thing that we have to do is create a new ASP.NET MVC 2 project from within Visual Studio.

1. In Visual Studio, create a new "ASP.NET MVC 2 Web Application" named MvcJamSession. You can create your project in either Visual Basic or Visual C#, though all of the examples in this post will be in C#.
2. After selecting the project type and solution/project name, you will be prompted for creating a unit test project. Select "Yes." Though we will not be using these tests in this exercise, we will be in future installments.
3. Be sure that your MvcJamSession.Test project includes a project reference back to your MvcJamSession project.
4. Compile and run. Your browser should display a blue web site showing "Welcome to ASP.NET MVC!" Congratulations. You now have your first ASP.NET MVC application.

Convention-Based Development

Development within ASP.NET MVC is based on convention over configuration. Certain naming conventions are built in the system to eliminate the amount of boiler-plate code that you need to recreate. That is not to say that you must follow these naming conventions—you may use whatever convention you like—but by straying from the standardized conventions, you will be creating a lot of extra work for yourself. With our new ASP.NET MVC 2 Project, a few of these conventions are immediately visible.

• Controllers folder. This is where all Controller classes must go. Individual classes must be named <Name>Controller. The default project includes HomeController, which governs the Home and About actions, and AccountController, which governs the log in, log out, change password, and registration actions. If we were to make an application that manages Widgets, we would likely have a class named WidgetController.
• Views folder. This is where all of the Views must go. By default, views are paired one-to-one with controller actions, such as one view for new user registration and another view for changing your password. Views are also separated into folders matching the associated controller name—/Views/<ControllerName>/<ActionName>. Thus, HomeController's About action is associated with the /Views/Home/About view.
  The Views folder also contains a Shared folder. This folder is where any common views, such as a Master Page, would reside. The Shared folder is also where the ViewEngine cascades to when it can't find an appropriate view in the /Views/<ControllerName> folder; if /Views/Home/About didn't exist, the ViewEngine would look for /Views/Shared/About. This can come in handy for common pages shared by all controllers, such as an error page.

Session Exercise 1: Building an Application

Using the project we just created, we're going to create an application that manage a list of employees, including their name, job title, date of hire, and date of termination. Though the default project is a great help on some applications, it can get in the way on others; we're not going to need any account services in our application, so we need to first trim the project down a little.

1. Delete the entire Account folder under /Views/.
2. Delete AccountController.cs from the Controllers folder.
3. Delete shared partial view /Views/Shared/LogOnUserControl.ascx.
4. Delete reference to this partial view by removing the "LoginDisplay" DIV from /Views/Shared/Site.Master, lines 18-20.
5. Removing LoginDisplay will cause a slight layout problem from the CSS. To fix it, modify the #menucontainer definition in /Content/Site.css on line 263.
   

   #menucontainer
   {
       padding-top:40px;
   }

6. Save all, compile, and Run. The site should be functioning normally, but without the Log In link in the top right of the home page.

Creating a Database

Like any dynamic web site, we need a storage mechanism. Create a database in SQL Server or SQL Server Express with an Employee table containing columns for name, job title, hired date, and termination date, as well as an identity column for finding records.

• For those with SQL Server Express, create a new database through right-clicking the App_Data folder, and adding a new item. The new item should be a SQL Server Database.
• For those with SQL Server, create a new database through SQL Server Management Studio (SSMS).

1. Create a new table called Employee.
2. Create the following columns within the new table:
   • Id (primary key, identity, int, not null)
   • Name (varchar(50), not null)
   • JobTitle (varchar(50), not null)
   • HiredOn (date, not null)
   • TerminatedOn (date, null)
3. Add a record or two to the table for good measure.

Creating a Model

The next thing we need to create is our Model. Not only is it the code representation for our business entity (An Employee class contains Name, JobTitle, HiredOn, and TerminatedOn properties), it is also responsible for how to get, save, or delete data from the database. We will be using Microsoft Entity Framework through Visual Studio to generate our model for us.

1. To create our new Model, right-click the Model folder and select Add New Item. The new item should be an ADO.NET Entity Data Model, found within the Data category of the Add New Item dialog. Name it MvcJamSessionEntities.
2. Generate the Model from a database, connecting to your MVC Jam Session database created in the previous section. On the step where you select your database connection, be sure to allow Visual Studio to add the connection string to your web.config by checking the appropriate checkbox.
3. The Employee table is the only Data Object that needs to be generated.
4. When the dialog completes, your Entity Data Model (a .edmx file) should be displayed in design view.
5. Save all and compile.

Creating a Controller

Now that our model is in place, we need to create a controller. The controller is responsible for managing all interaction between the end-user and the application, including identifying what data to get, save, or delete. (Remember, though the Controller is responsible for what, the Model is responsible for how.)

1. To create our new Controller, right-click the Controller folder and select Add Controller. Since the name matters in ASP.NET MVC's convention-over-configuration style, name it EmployeeController.cs (or .vb, if you happen to be working in Visual Basic .NET). Be sure to check the "Add action methods for Create, Update, Detail, and Delete scenarios" as we will be using them later.
2. We now have a basic controller, but it doesn't do anything yet. First, we want to modify our Index action, as it is the default action in the controller. We will use this action to list all of the Employees that currently exist in our database. Your Index() action method should contain the following code:
   

   var _entities = new MvcJamSession.Models.MvcJamSessionEntities();
   return View(_entities.Employee.ToList());

3. Save all and compile.

Creating a View

We have our Model and we have our Controller, so it is time for our View. The View is responsible for display only—it should contain virtually no logic. Our controller doesn't do anything yet, but we can at least get the base file structure and navigation in place. Since our Model governs how and our Controller governs what, think of the View as governing where, as it is responsible for deciding where each data element gets displayed on your page.

1. Once you have saved and compiled your Controller, right-click on the Index action name and select Add View.
2. The View should be named Index, just like your Controller action. Also, make your View strongly typed to the Employee model. Since a list of Employees is being passed to the View from the Controller, making the View strongly-typed prevents us from having to cast our View Model from object to Employee. Finally, since we are providing a list of Employees, the View Content should be a List.
3. The Employee folder should be automatically created under the /Views/ folder, and the Index.aspx View inside of this new Employee folder.
4. The last thing we need to do is provide some navigation to this view. Open up /Views/Shared/Site.Master and add an ActionLink within the Menu Container section to the Index action of the Employee controller. When you are done, the Menu Container should look like this:
   

   <ul id="menu">              
       <li><%= Html.ActionLink("Home", "Index", "Home")%></li>
       <li><%= Html.ActionLink("About", "About", "Home")%></li>
       <li><%= Html.ActionLink("Employees", "Index", "Employee")%></li>
   </ul>

5. Save all and run. When you navigate to your Employees link, you should get a list of all employees currently in the database with an Edit, Details, and Delete links.

New in ASP.NET MVC 2: Strongly Typed HTML Helpers

In the previous version of ASP.NET MVC, HTML helpers were simple generic classes. Generated views were full of Magic Strings for each property in your model, such as <%= Html.TextBox("Name") %>, opening the door for a fat-fingered property name. MVC 2 includes strongly-typed HTML helpers on strongly-typed views. For form-based views, use the new strongly-typed "For" methods, such as <%= Html.TextBoxFor(model => model.Name) %> or <%= Html.EditorFor(model => model.Name) %> to eliminate the risk of incorrectly entering a property name. For display fields, use Html.DisplayFor() to provide similar benefits for your read-only data, including the elimination of HTML encoding for each field.

Adding New Data

A list of employees is great, but we also need the ability to manipulate that data. First, let's start with the ability to create new data.

1. Within Visual Studio, open /Controllers/EmployeeController and navigate to the POST Create action. POST is an HTTP verb associated with pushing data to the server in the HTTP header, commonly associated with form submits. GET is the HTTP verb for pure retrieval, commonly associated with a direct URL request, such as clicking a link. In this case, the POST action can be identified by the [HttpPost] decoration.
2. The method arguments currently include only a FormCollection object that will contain all of the header values associated with the POST. However, MVC is smart; it can automatically transform this collection into a type-safe Model, based on the names of the header variables (the identities of the HTML form inputs match the names of the Model's properties). The one exception is the Id attribute, which is available in the Model but not populated until after the object is saved to the database. To get strong typing, and avoid having to manually cast or map form collection data to a new instance of our Model, change the method signature to the following:
   

   public ActionResult Create([Bind(Exclude="Id")] MvcJamSession.Models.Employee newEmployee)

3. Now that we have a populated Model, we just need to save the Model to the database and redirect back to the List when we are done. Do this by replacing the contents of the action method with the following code:
   

   try
   {
       if (!ModelState.IsValid) return View();
   
       var _entities = new MvcJamSession.Models.MvcJamSessionEntities();
       _entities.AddToEmployee(employee);
       _entities.SaveChanges();
       return RedirectToAction("Index");
   }
   catch
   {
       return View();
   }

4. Save and compile.
5. Now we must create the View for adding data. As we did with Index, we can create the view by right-clicking the Action method and selecting Add View. The view content should be Create.
6. The only modification for the Create view is the Id property. The generated code creates an input for this property, but it is not needed since the column value is auto-populated by the database when saving the entity. Remove this input and label from the form.
7. Save and run. You should now be able to add new records to the database.

New in ASP.NET MVC2: Better Verb Attributes

In the first version of ASP.NET MVC, HTTP Verb conditions were placed on an Action via the AcceptVerbsAttribute, such as the Create action's [AcceptVerbs(HttpVerbs.Post)]. In ASP.NET MVC 2, these attributes have been simplified with the introduction of the HttpGetAttribute, HttpDeleteAttribute, HttpPostAttribute, and HttpPutAttribute.

Routing and Updates

The end user can view a list of Employees, and can create new employees, but when the end user clicks the Edit or Detail links, they get an error since these Views haven't been created yet and the Actions are not implemented. One by one, we will get the new views in place.

1. Within Visual Studio, open /Controllers/EmployeeController and navigate to the Details action. You may notice that the method already accepts an integer as input, and shows example usage of the action in a commented URL above the method: /Employee/Details/5. This integer is the identity value of the Employee record, and is already populated in the links of our List view created in the previous section.
2. Within Visual Studio, open Global.asax and navigate to the RegisterRoutes method. The default route for ASP.NET MVC is /{controller}/{action}/{id}/. By parsing out any URL into the application, MVC can determine which Controller to use, which Action to execute, and which arguments to pass to the Action. Later portions of the URL path are often optional, and when not specified, are replaced with the default values: Home, Index, and String.Empty. The URLs of "/", "/Home", "/Home/", "/Home/Index", and "/Home/Index/" are all equivalent URLs in the eyes of ASP.NET MVC.

Go back to the Employee controller. Now that we know what the integer argument is for, we need to retrieve the Employee matching the associated identity and pass it to a view for editing or display.

1. Replace the contents of the GET version of the Edit action method with the following code to retrieve the Employee from the database that matches the identity specified in the route:
   

   var _entities = new MvcJamSession.Models.MvcJamSessionEntities();
   return View(_entities.Employee.Where(emp => emp.Id == id).First());

2. Save and compile.
3. Right-click the Action and add the View. The View should still be strongly typed, but this time the view content should be Edit.
4. The Details and GET Delete actions are largely similar as the GET Edit action, except that the view is labels instead of text boxes. Repeat the above three steps for the Details action method with a Details view content and for the GET Delete action method with a Delete view content.
5. As with the Create view, the Id property should be removed from the Edit view, as it is not an item that should be edited by the end user.
6. Save and run. You should see the details of an Employee when clicking on the Edit and Details links.
7. We can view Employee details within the Edit form, but when we make changes and submit, nothing happens. We need to modify the POST Edit action to save our changes back to the database. The default POST Edit action accepts an id and a FormCollection as input arguments, but similarly to the POST Create action, we can change this to use our strongly typed model to avoid having to cast or map data. However, unlike our Create action, we need to bind the id property so that the system knows which record to update. To make these modifications, replace the POST Edit signature with the following:
   

   public ActionResult Edit(MvcJamSession.Models.Employee employee)

8. Replace the contents of the POST Edit action method with the following code to save the changes to the database:
   

   try
   {
       if (!ModelState.IsValid) return View();
   
       var _entities = new MvcJamSession.Models.MvcJamSessionEntities();
       var _originalEmployee = _entities.Employee.Where(emp => emp.Id == employee.Id).First();
       _entities.ApplyPropertyChanges(_originalEmployee.EntityKey.EntitySetName, employee);
       _entities.SaveChanges();
       return RedirectToAction("Index");
   }
   catch
   {
       return View();
   }

9. Replace the signature of the POST Delete action method with the following code to provide strong typing on our model:
   

   public ActionResult Delete(MvcJamSession.Models.Employee employee)

10. Finally, replace the contents of the POST Delete action method with the following code to delete a record:
    

    var _entites = new MvcJamSession.Models.MvcJamSessionEntities();
    var originalEmployee = _entites.Employee.Where(emp => emp.Id == deletedEmployee.Id).First();
    _entites.DeleteObject(originalEmployee);
    _entites.SaveChanges();
    return RedirectToAction("Index");

11. Save, compile, and run. You should now be able to modify existing Employee records.

We now have a fully-functional ASP.NET MVC application to manage our Employee records. Congratulations!

On Tuesday, February 23rd, I will be leading the jam session for Come Jam With Us, the software developer study group in Ann Arbor. The session will be on ASP.NET MVC, and aims to give attendees enough of an introduction to the product to empower developers to be able to start coding their own ASP.NET MVC 2 projects. Like all of the Come Jam With Us sessions for the winter/spring of 2010, it will be held at the offices of SRT Solutions in Ann Arbor at 5:30p.

Prerequisites

You will need few things for ASP.NET MVC 2 application development and to complete this exercise. Please complete the following prerequisites prior to the session, otherwise you likely will spend the hour downloading and installing rather than coding.

• Install Microsoft Visual Studio 2008 SP1 or Visual Web Developer 2008 Express with SP1
• Install Microsoft SQL Server or SQL Server Express
• Download and install ASP.NET MVC 2 from Microsoft.com

Rescheduled

Due to weather, the original February 9th meeting was cancelled. This session is rescheduled for Tuesday, February 23rd.

The new season of Come Jam With Us in Ann Arbor is upon us. Come Jam With Us is a weekly software developers' study group in Ann Arbor for gaining exposure to and learning about many different software development topics. The group originally started in late 2008 by a group of developers looking for a way to help each other prepare for and pass one of the Microsoft .NET exams, and now has hour-long weekly Jam sessions covering Java, Ruby, .NET, F#, Silverlight, Design Patterns, and more.

The Winter/Spring 2010 Schedule begins this Tuesday, February 2nd, and continues every week until early May. Come Jam With Us in Ann Arbor, at the offices of SRT Solutions, 206 South 5th Ave, Suite 200. More information, including the prerequisites for each session (such as what software you need to have pre-installed), is available at the group's web site, http://www.comejamwithus.org.

Come Jam With Us in Ann Arbor

Every Tuesday, 5:30p-6:30p
February 2nd through May 5th, 2010

SRT Solutions
206 S. 5th Ave, Suite 200
Ann Arbor, MI 48104 | Map

Winter/Spring 2010 Jam Schedule

2-02 : Django with Darrell Hawley
2-09 : ASP.NET MVC2 with Jay Harris
2-16 : RESTful Web Services with Mike Smithson
2-23 : Erlang with Carl Wright
3-02 : MVVM with Brian Genisio
3-09 : F# (Part 1 of 3) with Chris Marinos
3-16 : F# (Part 2 of 3) with Chris Marinos
3-23 : F# (Part 3 of 3) with Chris Marinos
3-30 : WPF with Anne Marsan
4-06 : Getting to know jQuery with Dennis Burton
4-13 : Testing with WatiN with Jay Harris
4-20 : Adobe Air with Bill Heitzeg
4-27 : ActiveMQ with Becky Glesner
5-04 : NoSQL MongoDB with Dennis Burton

In ASP.NET MVC, the default signature for a Details action includes an Int32 method argument. The system works fine when the expected data is entered, and the happy path is followed, but put in an invalid value or no value at all, and an exception explodes all over the user.

The parameters dictionary contains a null entry for parameter 'id' of non-nullable type 'System.Int32' for method 'System.Web.Mvc.ActionResult Details(Int32)' in 'MvcSampleApplication.Controllers.WidgetController'.

By default, the third section of an ASP.NET MVC Route is the Id, passed as a method argument to a controller action. This value is a string, defaulting to String.Empty, but it can be parsed to other types such as an integer for a default Details action. The problem stems from when invalid values or missing values are passed to these integer-expecting actions; MVC handles the inability to parse the value into an integer, but then throws an exception trying to pass a null value to a Controller Action expecting a value type for a method argument.

A common solution is to convert the method argument to a nullable integer, which will automatically cause the argument to be null when the route value specified in the URL is an empty or non-integer value. The solution works fine, but seems a little lame to me; I want to avoid having to check HasValue within every action. I have to check for invalid identity values anyway (a user with an id of –1 isn’t going to exist in my system), so I would much rather default these invalid integers to one of these known, invalid values.

Using a custom ActionFilterAttribute, I can accomplish my goal. Prior to executing my Controller Action, an ActionFilterAttribute can validate that the specified route value meets an expected type, and correct the value to a default value if this validation fails; this will allowing me to keep that method argument as a value type integer and avoid Nullable<int>.HasValue.

ForceIntegerRouteValueAttribute class

public sealed class ForceIntegerRouteValueAttribute : ActionFilterAttribute
{
  private readonly int _defaultValue;
  private readonly string _routeValueName;

  public ForceIntegerRouteValueAttribute(string valueName, int defaultValue)
  {
    _routeValueName = valueName;
    _defaultValue = defaultValue;
  }

  public override void OnActionExecuting(ActionExecutingContext context)
  {
    base.OnActionExecuting(context);

    int testValue;
    if (!context.ActionParameters.ContainsKey(_routeValueName) ||
        !int.TryParse(context.RouteData.Values[_routeValueName].ToString(),
                      out testValue))
    {
      context.RouteData.Values[_routeValueName] = _defaultValue;
      context.Result = new RedirectToRouteResult(context.RouteData.Values);
    }
  }
}

The attribute accepts a string matching the name of the route value to analyze and a default value to assign to the route value should the validation fail. The override on OnActionExecuting will cause the validation to fire immediately prior to the Action being executed. The method attempts to parse the route value to an integer, and if it fails it will set the route value to the default value and restart processing of the route. RedirectToRouteResult restarts the route processing over again, since to get to this point, the method must have changed a route value, and without the redirect, the action would continue on with the original value. This will also redirect the browser to route matching the new route value, such as redirecting ~/Widgets/Details/Foo to ~/Widgets/Details/0.

Usage

public class WidgetsController : Controller
{
  [ForceIntegerRouteValue("id", 0)]
  public ActionResult Details(int id)
  {
    return View();
  }
}

By simply adding the attribute to the Action, I can now validate that my identity is an integer, allowing for some level of trust into user input values, and do so without having to laden my code with unnecessary value checks. This same idea can be used for any sort of pre-filtering, which could also include checking that the number contains no more than two decimal places. Just don’t go too far with this idea. Familiarize yourself with Route Constraints, too, as there will be times that a constraint can better serve your business needs than an Action Filter. But for areas where this solution does serve well, such as eliminating Nullable<int> in Action arguments, this option just seems cleaner to me. And in the ASP.NET MVC World of keeping Controllers as light as possible, I like clean.

If you have read my post on Misconceptions on JavaScript Plugins and SEO, you know that search engines don't do JavaScript. Though these plugins and libraries (such as one for pulling your latest Twitter Updates) are nice for adding dynamic content for your users, they are just end-user flare and add nothing to your SEO rankings. They also put an unnecessary tax on your users, as each client browser is responsible for independently retrieving the external content; the time for your page to render is extended by a few seconds as the client must first download the JS library then make the JSON/AJAX request for your content.

In response to this, I have created dasControls, a library of custom macros for dasBlog (the blogging engine that powers www.cptloadtest.com). I have started with content that is driven by custom JavaScript libraries and convert the content and data retrieval into server-side controls. For now, dasControls contains only a Twitter Status macro, but I intend to add more controls in the coming months.

dasControls [Build 1.0.0.0] : Download | Project Page

dasControls TwitterStatus Macro

The TwitterStatus macro uses server-side retrieval of your Twitter data, eliminating all client-side JavaScript calls for your tweets. By placing the Twitter request on the server, the data is also available to any search engines that index your page. Additionally, data is cached on the server, and new updates are retrieved based on the polling interval you specify. When using real-time client-side JavaScript calls, there is a 2-5 second delay for your end-users while the data is retrieved from Twitter; by caching the data on the local server, this delay is eliminated, and the content for each user is delivered from the local cache, lightening the load for the end-user while avoiding an undue burden for high-traffic sites.

Macro Name: TwitterStatus
Macro Syntax: <% TwitterStatus("user name"[, number of tweets[, polling interval]])|dasControls %>

• User Name : String. Your Twitter handle.
• Number of Tweets : Integer. The number of tweets to retrieve and display. [default: 10]
• Polling Interval : Integer. The number of minutes between each Twitter retrieval. [default: 5]

Relevant CSS:

• TwitterStatusItem : CSS class given to each Tweet, rendered as a DIV.
• TwitterStatusTimestamp : CSS class given to each Tweet's timestamp ("32 minutes ago"), rendered as an inline SPAN within each Tweet element.

Using the Macro within a dasBlog Template

This macro is for use in the dasBlog HomeTemplate. The macro works just like any out-of-the box macro, except that you must also include the alias specified within dasControls entry the web.config (the value of the "macro" attribute). Your twitter handle is required, though you can also optionally include the number of Tweets to pull from Twitter (default: 10) and the number of minutes between each Twitter data request (default: 5). Because everything happens on the server, there is no need to include any of the Twitter JSON JavaScript libraries or HTML markup.

<% TwitterStatus("jayharris", 6, 5)|dasControls %>

Installation and Setup of dasControls

Download dasControls, extract the assembly into your dasBlog 'bin' directory.

dasControls [Build 1.0.0.0] : Download | Project Page

Enable Custom Macros within your dasBlog installation, and add the Twitter macro to your list of Custom Macros.
First, ensure that the <newtelligence.DasBlog.Macros> section exists within your web.config:

<newtelligence.DasBlog.Macros>
  <!-- Other Macro Libraries -->
</newtelligence.DasBlog.Macros>

Second, ensure that the Macros Configuration Section is defined in to your web.config <configSections>:

<configSections>
  <!—Other Configuration Sections -->
  <section requirePermission="false" name="newtelligence.DasBlog.Macros"  
    type="newtelligence.DasBlog.Web.Core.MacroSectionHandler, newtelligence.DasBlog.Web.Core" />
</configSections>

Third, add the dasControls library entry to the dasBlog Macros section:

<newtelligence.DasBlog.Macros>
  <add macro="dasControls"
    type="HarrisDesigns.Controls.dasBlogControls.Macros,HarrisDesigns.Controls.dasBlogControls"/>
</newtelligence.DasBlog.Macros>

Roadmap for dasControls

In the upcoming weeks and months, I plan on adding additional macros to the dasControls library, including Delicious, Google Reader's Shared Items, and Facebook. If you're interested in any others, or have any ideas, please let me know.

Search Engine Optimization is high on the radar, right now. Whether it be the quest for the first Coupon site in Bing, the highest Cosmetics site on Google, or the top-ranked "Jay Harris" on every search engine, the war is waged daily throughout the internet. For companies, it's the next sale. For people, it's the next job. Dollars are on the line in a never-ending battle for supremacy.

One of the contributing factors in your Search Engine Ranking is Content. Fresh, new content brings more search engine crawls. More crawls contributes to higher rankings. Search engines like sites that are constantly providing new content; it lets the engine know that the site is not dead or abandoned. And though this new content idea works out well for the New York Times and CNN, not everyone has a team of staff writers who are paid to constantly produce new content. So we shortcut. We don't so much have to have new content as long as we make Google think we have new content. There are hundreds if not thousands of JavaScript plugins out there to provide fresh content to our readers, ranging from Picasa photos, to Twitter updates, to AdWords, to Microsoft Gamercard tags. But I have to let you in on a little secret:

JavaScript Plugins do nothing for SEO.
Nothing.
Search engine spiders don't do JavaScript.

"This must be a lie. When I look at my site, I see my new photos, or my new tweets, or my new Achievement Points; why don't the spiders see it, too?" Well, it's true. Google Spiders, and most other Search Engine Spiders, don't do JavaScript, which is why JS provides no SEO contribution; spiders do not index what they do not see. A look through your traffic monitor, like Google Analytics, will often show a disparity between logged traffic and what is actually accounted for in Web Server logs. Analytics, a JavaScript-based traffic monitor, only logs about 40% of the total traffic to this site (excluding traffic to the RSS feed), which means that the other 60% of my visitors have JavaScript disabled. A JavaScript Disabled on 60% of all browsers seems like a ridiculously high percentage unless you consider that Spiders and Bots do not execute JavaScript.

Just like Google doesn't see the pretty layout from your stylesheet, Google also doesn't see the dynamic content from your JavaScript. Pulling down HTML, (since it is all just text, anyway) is easy; there's not even a lot of overhead associated with parsing that HTML. But add in some JavaScript, and suddenly there's a lot more effort involved in crawling your page, especially since there is a lot of bad JavaScript out there. So search engines just check what has been written into your HTML. They read the the URL, the keywords and META description, but only the content as rendered by the server. JavaScript is not touched, and JavaScript-based content is not indexed.

So how do you get around this? How do you get this SEO boost, since JavaScript isn't an available option?

Use plug-ins and utilities that pull your dynamic data server-side, rather than client-side. Create a custom WebControl that will download and parse your latest Twitter updates. Create a dasBlog macro to create your Microsoft Gamertag. By putting this responsibility on the server, not only will you make life easier on your end user (one less JavaScript library to download), but you also make this new content available to indexing engines, which can only help your Google Juice.

Update:

I've been working on a set of macros for dasBlog to start pulling my dynamic content retrievals to the server. Keep an eye out over the next couple of days for the release of my first macro, a Twitter Status dasBlog macro that will replace the need for the Twitter JS libraries on your site.

This Saturday, August 1st, I will be speaking at Lansing Day of .NET 2009, at the Breslin Student Events Center at Michigan State University, East Lansing, Michigan. This session will be the same ASP.NET Page Life Cycle talk that I gave last month at CodeStock.

Dev Basics: The ASP.NET Page Life Cycle

Jay Harris / Session Level: 100
When a request occurs for an ASP.NET page, the response is processed through a series of events before being sent to the client browser. These events, known as the Page Life Cycle, are a complicated headache when used improperly, manifesting as odd exceptions, incorrect data, performance issues, and general confusion. It seems simple when reading yet-another-book-on-ASP.NET, but never when applied in the real world. In this session, we decompose this mess, and turn the Life Cycle into an effective and productive tool. No ASP.NET MVC, no Dynamic Data, no MonoRail, no technologies of tomorrow, just the basics of ASP.NET, using the tools we have available in the office, today.

If you can make it, I recommend attending LDODN09. There are some great sessions lined up, and it is all being provided free-of-charge (though the event organizers are encouraging donations). Last year's event, held at Lansing Community College, was the first Lansing Day of .NET and the first event that I was involved in organizing. It went well, and from the moment it was over I was looking forward to the next one. I'm not on the organizing committee this year, but I am still sure that this one is destined to be great as well. They rented the Breslin Center! If I knew nothing else, that would be enough.

So come out to Lansing Day of .NET this Saturday. Registration is still open.

I hope to see you there.

The first installment of this series goes back to the beginning and describes each of the events within ASP.NET Page Life Cycle. Understanding the basic fundamentals of the ASP.NET Page Life Cycle, including the order and scope of influence for each of the Page Life Cycle events, will help ensure that you are executing your custom code at the right time, and in the right order, rather than stepping on yourself by conflicting with core ASP.NET framework functionality. But this is only part of the story, since there is more to the ASP.NET Page Life Cycle than just the page, itself.

ASP.NET Page & WebControl Event Execution Order

Pages would be nothing but a sea of crazy peach gradient backgrounds without the controls to display content and to interact with the user. In addition to the order of the various page events, it is often helpful to know the order in which a page and its controls execute a single event. Does Page.Load execute before Control.Load? Does Page.Init execute before Control.Init? Does myTextBox.TextChanged fire before myButton.Click? And what about myTextBox1.TextChanged versus myTextBox2.TextChanged?

Knowing the execution order of events within the control tree will make you a better ASP.NET developer. If you cannot answer each of those questions above (and maybe even if you can), keep reading.

About the Series

When a request occurs for an ASP.NET page, the response is processed through a series of events before being sent to the client browser. These events, known as the ASP.NET Page Life Cycle, are a complicated headache when used improperly, manifesting as odd exceptions, incorrect data, performance issues, and general confusion. It seems simple when reading yet-another-book-on-ASP.NET, but never when applied in the real world. What is covered in a few short pages in many ASP.NET books (and sometimes even just a few short paragraphs), is much more complicated outside of a "Hello, World!" application and inside of the complex demands of the enterprise applications that developers create and maintain in their day-to-day work life. As close to the core as the life cycle is to any ASP.NET web application, the complications and catches behind this system never seems to get wide coverage on study guides or other documentation. But, they should.

Part 1: Events of the ASP.NET Page Life Cycle
Part 2: ASP.NET Page & WebControl Event Execution Order

Event Execution Order within the Control Hierarchy

At the core of the control-level event execution order is where the events fire with respect to the page. The majority of the events in the ASP.NET Page Life Cycle execute from the top, down, which is also referred to as outside-in. That is, the event is first executed on the page, such as Page.Load, then executed recursively through each of the page's controls, Control.Load, to the controls within controls, and so on. The two exceptions to this rule are Initialization and Unload. With these two events, the event is fired first on the child control, then on the container control, and finally on the page, known as a bottom-up or inside-out order.

But what if a control is dynamically added to the page during a later event? In this case, a control will fire events to catch up to the page (though a control will never exceed beyond what Page Event is currently executing). In other words, if a control is dynamically added during the PreInit page event, the control will immediately fire its own PreInit. However, if a control is dynamically added during the PreLoad event, it will fire PreInit, Init, InitComplete, and PreLoad, all in quick succession.

private void Page_PreInit(object sender, EventArgs e)
{
    Trace.Write("Executing Page PreInitialization");
    var textbox = new TextBox();
    textbox.Init += Control_Init;
    textbox.Load += Control_Load;
    textbox.ID += "TextBoxFromPreInit";
    form1.Controls.Add(textbox);
}

private void Page_Init(object sender, EventArgs e)
{
    Trace.Write("Executing Page Initialization (Should occur after controls)");
}

private void Page_Load(object sender, EventArgs e)
{
    Trace.Write("Executing Page Load (Should occur before controls)");
    var textbox = new TextBox();
    textbox.Init += Control_Init;
    textbox.Load += Control_Load;
    textbox.ID += "TextBoxFromLoad";
    form1.Controls.Add(textbox);
}

private void Control_Init(object sender, EventArgs e)
{
    Trace.Write("Executing Control Init for " + ((Control)sender).UniqueID);
}

private void Control_Load(object sender, EventArgs e)
{
    Trace.Write("Executing Control Load for " + ((Control)sender).UniqueID);
}

/*
Output: 

Begin PreInit		
Executing Page PreInitialization
End PreInit
Begin Init
Executing Control Init for TextBoxFromPreInit
Executing Page Initialization (Should occur after controls)
End Init
Begin Load
Executing Page Load (Should occur before controls)
Executing Control Init for TextBoxFromLoad
Executing Control Load for TextBoxFromPreInit
Executing Control Load for TextBoxFromLoad
End Load
*/

Event Execution Order for Sibling WebControls

The event execution order of parent and child controls is simple and straightforward. As if to maintain balance in The Force, the event execution order for sibling controls is a bit complicated. For siblings, this order is governed by three main and cascading criteria: the type of event that is being executed, the Page Event executing when the control was added to the page, and the index of the control within the parent's (or page's) Controls collection.

First, the event type is the primary governor of when an event is fired. Just like the order of Page Events, Initialize events always occur before Load events, and Load events always occur before Render events. The complication surrounds the several control-specific "PostBack Events," such as Click or TextChanged, as there are three PostBack event types: Changed Events, Validation Events, and actual PostBack Events. The first that fire are Changed Events, which include any event where the value changes, such as TextBox.TextChanged or DropDownList.SelectedIndexChanged. Changed events should include any custom Value manipulation for each of your form controls. Once the values are defined, Validation events are executed to assist with ensuring data integrity. Finally, once all values are defined and validated, PostBack Events, such as Button.Command or Button.Click, are executed. In most cases, these PostBack events will include the form submission logic, such as sending the email, transmitting data through a Web Service, or saving data to a database. The Changed Events type of events always fire before Validation events, which always fire before the PostBack Events types; TextBox.TextChanged before Validator.Validate before Button.Click.

If the events are the same, such as two TextBox controls that are both executing TextChanged, the second criteria to determine sibling event execution is when the control was added to the page. If a control was added in any of the Initialization events (PreInit, Init, InitComplete), it is executed first. If a control was added in any of the Load events, it is executed second. So, for the two TextBoxes, the TextChanged event for the TextBox added during Initialization will be fired before the same event for the TextBox added during Load. (txtAddedDuringInit.TextChanged will fire before txtAddedDuringLoad.TextChanged.)

If the executing event is the same, and the controls were added during the same Page Event, the final criterion for sibling execution is the index within the Controls collection. After the above two criteria are considered, events that still have equal weight are executed according to their index in their parent's Controls collection.

private void Page_Init(object sender, EventArgs e)
{
    TextBox textbox;
    textbox = new TextBox();
    textbox.TextChanged += Control_TextChanged;
    textbox.ID += "TextBoxFromInit1";
    form1.Controls.Add(textbox);
    textbox = new TextBox();
    textbox.TextChanged += Control_TextChanged;
    textbox.ID += "TextBoxFromInit2";
    form1.Controls.Add(textbox);
    textbox = new TextBox();
    textbox.TextChanged += Control_TextChanged;
    textbox.ID += "TextBoxFromInit3At0";
    form1.Controls.AddAt(0, textbox);
}

private void Page_Load(object sender, EventArgs e)
{
    TextBox textbox;
    textbox = new TextBox();
    textbox.TextChanged += Control_TextChanged;
    textbox.ID += "TextBoxFromLoad1";
    form1.Controls.Add(textbox);
    textbox = new TextBox();
    textbox.TextChanged += Control_TextChanged;
    textbox.ID += "TextBoxFromLoad2";
    form1.Controls.Add(textbox);
    textbox = new TextBox();
    textbox.TextChanged += Control_TextChanged;
    textbox.ID += "TextBoxFromLoad3At0";
    form1.Controls.AddAt(0, textbox);
}

private void Control_TextChanged(object sender, EventArgs e)
{
    Trace.Write("Executing Control TextChanged for " + ((Control) sender).UniqueID
                + " / Position: " + form1.Controls.IndexOf((Control) sender));
}

/*
Trace Output: 

Begin Raise ChangedEvents
Executing Control TextChanged for TextBoxFromInit3At0 / Position: 1
Executing Control TextChanged for TextBoxFromInit1 / Position: 2
Executing Control TextChanged for TextBoxFromInit2 / Position: 3
Executing Control TextChanged for TextBoxFromLoad3At0 / Position: 0
Executing Control TextChanged for TextBoxFromLoad1 / Position: 4
Executing Control TextChanged for TextBoxFromLoad2 / Position: 5
End Raise ChangedEvents
*/

So, to address the questions from above: Page.Load does execute before Control.Load, as the Load event is executed outside-in, however, Page.Init executes after Control.Init, as the Init event is executed inside-out. The TextChanged event on myTextBox is fired prior to myButton.Click, as control ChangedEvents are executed before control PostBackEvents. And finally, regarding myTextBox1.TextChanged versus myTextBox2.TextChanged, it depends; the order is dependent upon where the controls exist within the entire hierarchy, when the controls were created, and upon their position within the Controls collection.

The execution order of control events within the page life cycle is a complicated mess, and fortunately does not come in to play often. But for when it does, it is important to know how everything plays together. I find that most often, the order is important when dynamically adding controls to the page outside of DataBinding (though I would consider this a design smell), when creating custom WebControls, or when working with control Changed Events and validation. Still, as with before, committing this to memory (or at least a link to a reference, such as this post) will help with making you a better ASP.NET developer and with creating higher quality applications.

So what's next? Part 1 covered the base ASP.NET Page Life Cycle, and this post covers the execution order of events on the page. As this series continues, we will discuss the details of the DataBinding events, and will dig in to some tips, tricks, and traps when developing ASP.NET applications.

I enjoy being a speaker. I have learned a lot through my mentors, colleagues, and through other community speakers, and standing before a group of my peers and sharing my knowledge is one way that I can give back to the development community. By linking together my speaking and my blog, I can provide a central repository for the slide decks and demo code for my sessions and make these things available to the audience for further review. Here, you will find all of my slides and code for all past presentations, as well as information about all my past and future talks. This post will also be linked through my top navigation so that it can be easily found, and will also be regularly updated with any new schedules and slide decks.

Thank you to everyone who as attended any of my sessions, and as always, I encourage you to give me any feedback you have via SpeakerRate.

Upcoming Talks

I would love to speak at your user group or developer's conference; please feel free to contact me if you are interested.

GLUGnet-Lansing, 18 March 2010

On Thursday, March 18, 2010, I will be presenting "ASP.NET MVC: A Web Coder's Salvation" at the monthly meeting of the Greater Lansing User Group for .NET Developers in Lansing, Michigan. | Event Site

AADND, 12 May 2010

On Wednesday, May 12, 2010, I will be presenting "ASP.NET MVC: A Web Coder's Salvation" at the monthly Ann Arbor .NET Developers meeting in Ann Arbor, Michigan. | Event Site

MDSM, 23 September 2010

On Thursday, September 23, 2010, I will be presenting "ASP.NET MVC: A Web Coder's Salvation" at the monthly Ann Arbor .NET Developers meeting in Ann Arbor, Michigan. | Event Site

Presentations

ASP.NET MVC: A Web Coder's Salvation

There was a time when everything was moving towards the desktop. This Internet thing was new and cool, but there was no way it would ever last. And no one knew how to code for the web, at least not anything beyond animated lava lamps and cute "Under Construction" images. So, to make coding for the web easier, they made ASP.NET to be just like coding for a desktop, using the same patterns, the same event-based model, and the same stateful approach. But the web isn't stateful, its only events are GET and POST, and is nothing like a desktop, so we tortured ourselves for years forcing a square peg through a round hole. The time has come for redemption, and its name is ASP.NET MVC. Spend an hour discovering how coding for the web is supposed to be--how it is today--and end your misery. Salvation awaits.
Slides Coming Soon

Dev Basics: The ASP.NET Page Life Cycle

When a request occurs for an ASP.Net page, the response is processed through a series of events before being sent to the client browser. These events, known as the Page Life Cycle, are a complicated headache when used improperly, manifesting as odd exceptions, incorrect data, performance issues, and general confusion. It seems simple when reading yet-another-book-on-ASP.NET, but never when applied in the real world. In this session, we decompose this mess, and turn the Life Cycle into an effective and productive tool. No ASP.NET MVC, no Dynamic Data, no MonoRail, no technologies of tomorrow, just the basics of ASP.NET, using the tools we have available in the office, today.
Slides | Code

Continuous Integration: More than just a toolset

Does your team spend days integrating code at the end of a project? Continuous Integration can help. Using Continuous Integration will eliminate that end-of-project integration stress, and at the same time will make your development process easier. But Continuous Integration is more than just a tool like CruiseControl.Net; it is a full development process designed to bring you closer to your mainline, increase visibility of project status throughout your team, and to streamline deployments to QA or to your client. Find out what Continuous Integration is all about, and what it can do for you.
Slides

Previous Talks

ASP.NET MVC: A Web Coder's Salvation

Ann Arbor, Michigan | A2<DIV> | February 2010 | SpeakerRate
Toledo, Ohio | North West Ohio .NET User Group (NWNUG) | January 2010 | SpeakerRate
Flint, Michigan | Greater Lansing User Group for .NET Developers (GLUGnet-Flint) | January 2010

DevBasics: The ASP.NET Page Life Cycle

Flint, Michigan | Greater Lansing User Group for .NET Developers (GLUGnet-Flint) | September 2009 | SpeakerRate
Lansing, Michigan | Lansing Day of .NET developer's conference | August 2009 | SpeakerRate | Event Site
Knoxville, Tennessee | CodeStock 2009 developer's conference | June 2009 | SpeakerRate | Event Site

Continuous Integration: More than just a toolset

Lansing, Michigan | Michigan Department of IT (MDIT) | December 2009 | SpeakerRate
Lansing, Michigan | Greater Lansing User Group for .NET Developers (GLUGnet-Lansing) | November 2009 | SpeakerRate
Southfield, Michigan | Great Lakes Area .NET User Group (GANG) | January 2009 | SpeakerRate
Toledo, Ohio | North West Ohio .NET User Group (NWNUG) | January 2009
Sandusky, Ohio | CodeMash 2009 developer's conference | January 2009 | SpeakerRate | Event Site
Ann Arbor, Michigan | Ann Arbor .NET Developers (AADND) | October 2008
Flint, Michigan | Greater Lansing User Group for .NET Developers (GLUGnet-Flint) | September 2008

When a request occurs for an ASP.NET page, the response is processed through a series of events before being sent to the client browser. These events, known as the ASP.NET Page Life Cycle, are a complicated headache when used improperly, manifesting as odd exceptions, incorrect data, performance issues, and general confusion. It seems simple when reading yet-another-book-on-ASP.NET, but never when applied in the real world. What is covered in a few short pages in many ASP.NET books (and sometimes even just a few short paragraphs), is much more complicated outside of a "Hello, World!" application and inside of the complex demands of the enterprise applications that developers create and maintain in their day-to-day work life. As close to the core as the life cycle is to any ASP.NET web application, the complications and catches behind this system never seems to get wide coverage on study guides or other documentation. But, they should.

A little help on the Page Life Cycle is never a bad thing. In this series, I will go over the events that make up the ASP.NET Page Life Cycle, as well as some tips and tricks on how to get the most out of this event structure while avoiding the traps and pitfalls. Rather than pursuing broad coverage of the entire ASP.NET Framework, we'll dive deeply into the "small" portion that is the ASP.NET Page Life Cycle.

Events of the ASP.NET Page Life Cycle

I want to start at the beginning. The primary make-up of the Page Life Cycle is the events that process any ASP.NET requests. Unlike the public static void main of a WinForms application, where everything based on methods, the execution of a page request is the execution of these events. These events, which execute in a particular order, handle the entire request, including loading all of the controls, processing all of the form data, handling all user-initiated actions, and rendering the page to the web browser. Knowing the order in which these events are executed, as well as the responsibility of each event in processing your request, is important for developing solid, quality ASP.NET applications.

Start

This is where the page object is instantiated, and where the initial properties of the page are set. Page properties such as Response and Request, UICulture (similar to the UICulture property within a WinForms thread), and the value of IsPostBack are all determined and assigned. No controls are available at this time, so do not try to set the value of that TextBox control, as it doesn't exist, yet. Fortunately, no event handlers can be attached to this event, anyway, so there isn't much you can do to customize this processing or to access that TextBox's value property; "Move along. There is nothing to see here." But, be aware that this event does occur after the Constructor, so if you try to access properties such as IsPostBack prior to the Start event, they have yet to be assigned, and will likely be incorrect.

Page Initialization

During page initialization, the controls are created, initialized, and added to the Page's controls collection. This is the first time that you can access a control by its UniqueID. Do note that all control properties are set to their code values, be it from code-behind or code-in-front, regardless of what may be available in ViewState and Form Post values. Control state has yet to be restored, so ViewState and Form Post values have not yet been pushed to the controls. Finally, Initialization (specifically, PreInit) is the only time that the Theme and Master Page can be programmatically modified.

Page Load

Page Load is where control state is restored. If the request is a PostBack, rather than a new request, all available property values are restored from ViewState and Form Post data and pushed to the applicable controls. Under most scenarios, this is where you're going to get what you need from the Database, such as pulling a value from the query string and loading an item with the matching identity.

Validation

The Validation event only applies to PostBack requests, and only when Validators are present in the control collection. The Validate method is executed for each Validator present, through which the IsValid property is set for each Validator. These IsValid property values are then cascaded up to the Page's IsValid property. Be aware that even if all Validators on the page are disabled, the Validation event will still fire; if a Validator is present, Validate is executed, without regard to any other property. Also, note that the Validation event is a child of the Page's Load event, so it is executed within the Page Load event chain, after Page Load, but prior to PostBack Events and LoadComplete.

PostBack Events

Once Validation is complete (if applicable), all PostBack events are executed, including the OnChange event of a DropDownList and the OnClick event of a command button. Post Back Events are also a child of the Page's Load event, executing after Validation and before LoadComplete.

Render

Finally, once all of the data is processed and Post Back events handled, the Page is rendered within the Web Browser. The Render event consists of saving all control property data to ViewState, processing the Page and each Control into HTML, and writing the HTML to the output stream. This is the last opportunity to modify the HTML output.

Remembering the Order

If you are having trouble remembering the order, instead try and remember this simple mnemonic: SILVER; Start, Initialize, Load, Validation, Events, Render.

If you are doing a lot of ASP.NET programming, or anticipate that you will be in the near future, try to commit to memory the order of each of these events, and their scope of influence. Understanding these basic fundamentals of the ASP.NET Page Life Cycle will help ensure that you are executing your custom code at the right time, and in the right order, rather than stepping on yourself by conflicting with the core functionality.

Now that we know the order of execution on Page Events, what is the order of the Controls? Does Page.Load execute before Control.Load? How about the order of sibling controls? What is the order of myTextBox1.TextChanged versus myTextBox2.TextChanged? Also, what are some things to look out for? As this series continues, we will discuss the details of event execution order within the ASP.NET Page Life Cycle, as well as some tips, trick, and traps when developing ASP.NET applications.