Jay Harris is Cpt. LoadTest

dasControls v1.0, a Twitter Status Macro for dasBlog

Jay Harris — Thu, 01 Oct 2009 02:33:55 GMT

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.

Technorati Tags: dasBlog,dasControls,Open Source,CodePlex,SEO,Twitter

Misconceptions on JavaScript Plugins and SEO

Jay Harris — Mon, 31 Aug 2009 12:47:29 GMT

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.

Technorati Tags: JavaScript,SEO,Twitter

Speaking at Lansing Day of .NET 2009 on ASP.NET Page Life Cycle

Jay Harris — Tue, 28 Jul 2009 23:18:18 GMT

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.

Technorati Tags: Lansing Day of .NET,Day of .NET,Speaking,Events,ASP.NET,Page Life Cycle

Dev Basics: ASP.NET Page Life Cycle, Part 2 [WebControl Execution Order]

Jay Harris — Tue, 14 Jul 2009 22:26:15 GMT

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.

Technorati Tags: ASP.NET,Page Life Cycle,Event Life Cycle,Dev Basics,Back to Basics

Speaking Engagements

Jay Harris — Tue, 30 Jun 2009 03:53:45 GMT

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 Flint, 10 September 2009

On September 10, 2009, I will be presenting "Dev Basics: The ASP.NET Page Life Cycle." at the monthly Flint, Michigan meeting of the Greater Lansing Users Group for .NET developers.

West Michigan, 13 October 2009

On October 13, 2009, I will be presenting "Dev Basics: The ASP.NET Page Life Cycle." at the October meeting for the West Michigan .NET User Group in Grand Rapids, Michigan.

Presentations

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

Past Talks

August 2009

Dev Basics: The ASP.NET Page Life Cycle @ Lansing Day of .NET 2009 | SpeakerRate | Event Site

June 2009

Dev Basics: The ASP.NET Page Life Cycle @ CodeStock 2009 | SpeakerRate

January 2009

Continuous Integration: More than just a toolset @ NWNUG Monthly Meeting
Continuous Integration: More than just a toolset @ GANG Monthly Meeting
Continuous Integration: More than just a toolset @ CodeMash 2009

October 2009

Continuous Integration: More than just a toolset @ AADND Monthly Meeting

September 2008

Continuous Integration: More than just a toolset @ GLUGnet-Flint Monthly Meeting

Technorati Tags: Speaking,Presentations

Dev Basics: ASP.NET Page Life Cycle, Part 1 [Events]

Jay Harris — Tue, 23 Jun 2009 03:53:57 GMT

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.

Technorati Tags: ASP.NET,Page Life Cycle,Event Life Cycle,Dev Basics,Back to Basics

Speaking at CodeStock 2009 on ASP.NET Page Life Cycle

Jay Harris — Mon, 18 May 2009 13:27:01 GMT

Next month, I will be speaking at CodeStock, a developer conference in Knoxville, Tennessee, held June 26-27. We will be discussing the ASP.NET Page Life Cycle, to help get over the fears and troubles with validation, event handing, data binding, and the conflicts between page load and page initialization.

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.

It's a long drive from Michigan to Knoxville, but the conference is worth the trip (the first of two Tennessee conferences I will be attending this year). A few other local speakers will be making the trip to Knoxville, as well. Check out the full session list for more information, and while you are at it, register for the event if you haven't already done so; the cost is only $25 if you sign up before the end of May. I was there last year for the first CodeStock, and I had a great time; I'm excited about this years event, not only because I am speaking, but to see what other new things that people are talking about, catch up with friends, and to meet new people in the community.

I hope to see you there.

Technorati Tags: CodeStock,Speaking,ASP.NET

Virtues and Villainy of Robots.txt

Jay Harris — Fri, 15 May 2009 13:31:37 GMT

You may have heard of Robots.txt. Or, you may have seen requests for /Robots.txt in your web traffic logs, and if the file doesn't exist, a related HTTP 404. But what is this Robot file, and what does it do?

Introduction to Robots.txt

When on a web server, Robots.txt is a file that directs Robots (a.k.a. Spiders or Web Crawlers) on which files and directories to ignore when indexing a site. The file is located on the root directory of the domain, and is typically used to hide areas of a site from search engine indexing, such as to keep a page off of Google's radar (such as my DasBlog login page) or if a page or image is not relevant to the traditional content of a site (maybe a mockup page for a CSS demo contains content about puppies, and you don't want to mislead potential audience). Robots request this file prior to indexing your site, and its absence indicates that the robot is free to index the entire domain. Also, note that each sub-domain uses a unique Robots.txt. When a spider is indexing msdn.microsoft.com, it won't look for the file on www.microsoft.com; MSDN will need its own copy of Robots.txt.

How do I make a Robots.txt?

Robots.txt is a simple text file. You can create it in Notepad, Word, Emacs, DOS Edit, or your favorite text editor. Also, the file belongs in the root of the domain on your web server.

Allow all robots to access everything:

The most basic file will be to authorize all robots to index the entire site. The asterisk [*] for User Agent indicates that the rule applies to all robots, and by leaving the value of Disallow blank rather than including a path, it effectively disallows nothing and allows everything.

# Allow all robots to access everything
User-agent: *
Disallow:

Block all robots from accessing anything:

Conversely, with only one more character, we can invert the entire file and block everything. By setting Disallow to a root slash, every file and directory stemming from the root (in other words, the entire site) will be blocked from robot indexing.

# Block all robots from accessing anything
User-agent: *
Disallow: /

Allow all robots to index everything except scripts, logs, images, and that CSS demo on Puppies:

Disallow is a partial-match string; setting Disallow to "image" would match both /images/ and /imageHtmlTagDemo.html. Disallow can also be included multiple times with different values to disallow a robot from multiple files and directories.

# Block all robots from accessing scripts, logs,
#    images, and that CSS demo on Puppies
User-agent: *
Disallow: /images/
Disallow: /logs/
Disallow: /scripts/
Disallow: /demos/cssDemo/puppies.html

Block all robots from accessing anything, except Google, which is only blocked from images:

Just as a browser has a user agent, so does a robot. For example, "Googlebot/2.1 (http://www.google.com/bot.html)", is one of the user agents for Google's indexer. Like Disallow, the User-agent value in Robots.txt is a partial-match string, so simply setting the value to "Googlebot" is sufficient for a match. Also, the User-agent and Disallow entries cascade, with the most specific User Agent setting is the one that is recognized.

# Block all robots from accessing anything,
#    except Google, which is only blocked from images
User-agent: *
Disallow: /
User-agent: Googlebot
Disallow: /images/

Shortcomings of Robots.txt

Similar to the Code of the Order of the Brethren, Robots.txt "is more what you'd call 'guidelines' than actual rules." Robots.txt is not a standardized protocol, nor is it a requirement. Only the "honorable" robots such as the Google or Yahoo search spiders adhere to the file's instructions; other less-honorable bots, such as a spam spider searching for email addresses, largely ignore the file.

Also, do not use the file for access control. Robots.txt is just a suggestion for search indexing, and will by no means block requests to a disallowed directory of file. These disallowed URLs are still freely available to anyone on the web. Additionally, the contents of this file can be used to against you, as it the items you place in it may indicate areas of the site that are intended to be secret or private; this information could be used to prioritize candidates for a malicious attack with disallowed pages being the first places to target.

Finally, this file must be located in the root of the domain: www.mydomain.com/robots.txt. If your site is in a sub-folder from the domain, such as www.mydomain.com/~username/, the file must still be on the root of the domain, and you may need to speak with your webmaster to get your modifications added to the file.

Other Resources:

The Web Robots Pages : http://www.robotstxt.org
Wikipedia : http://en.wikipedia.org/wiki/Robots.txt

Technorati Tags: SEO,Robots.txt

Lansing Give Camp Wrap-Up

Jay Harris — Thu, 07 May 2009 18:55:31 GMT

The event was about giving back to the community. A few weekends ago, April 24-26, 2009, the Impression 5 Science Center held the first ever Lansing Give Camp. The Lansing, Michigan event was a weekend of coding for charities, where nearly 50 area developers and over 10 volunteers gathered to donate their time and complete projects for 13 charities.

The event, which primarily took place in one large room on the first floor of Impression 5, was full of excitement and emotion. Sponsors stepped up to offer additional assistance at the last minute, all to really make the event a success. TechSmith, DevExpress, the MSU University Club, and even Impression 5 all stepped up during the final week to sponsor a meal. The remainder of the meals were covered by collaboration between Microsoft, Wing Zone, Dominos Pizza, Guido's Pizza, Panera Bread, and Dunkin Donuts. Jennifer Middlin of TechSmith and Camron Gnass of Vision Creative also covered our late-night snacks, which included Tacos and "Insomnia Cookies." Nom, nom, nom.

The biggest drama of the weekend had to be Mother Nature's visit on Saturday afternoon. A band of severe Thunderstorms rolled through Lansing on Saturday, knocking out power to the entire facility. We didn't lose any work, since everyone's laptop battery kicked in as soon as the lights went dark, but the loss of power did kill all of the wireless access points, and with it all connectivity to the source control server and to web hosting facilities. However, within minutes, Erik Larson (Director of Impression 5) was on the phone with Eric Hart (Director of the Lansing Center), and the Lansing Center responded heroically by providing us with a temporary home with power and internet access until power was restored at Impression 5. Between three teams shipping of to local coffee houses, and the rest all taking the trip across the street to the Lansing Center, everyone was able to continue working on their projects with minimal delay. I extend a huge "Thank you" to the Lansing Center for helping us get out of a jam that could have been a major detriment to the success of our weekend.

However, it was the closing ceremony at Lansing Give Camp that stole the show. There were many emotion-filled faces throughout the staff and crowd as each project conducted a presentation of their output, demoing their wares, and each charity saw dreams achieved and went home with a year of free hosting from LiquidWeb and an "everything you need to maintain your site" bag of software and books from Microsoft. Each of the attendees even went home with one or two prizes, which included books, hardware, and software from Microsoft, books from TechSmith, and software from DevExpress, Telligent, and Telleric.

It was a great event. The charities were happy. The developers were happy. It was all a huge success. And I can't wait until next year.

Lansing Give Camp in News and Blogs:

Great Lakes IT Report : Lansing GiveCamp Develops Free Software for Nonprofits
Lansing Capital Gains : Give Camp Brings $50,000 in Tech Talent to Local Charities
AM Lansing : On-Air Interview with Jay Harris on Lansing Give Camp
The Wit and Ramblings of David Giard : Lansing Give Camp Success
The Wit and Ramblings of David Giard : McWherters and Harrises on the Lansing Give Camp

Technorati Tags: Lansing,Give Camp,Charity

Attend Give Camp or the X Conference? Both!

Jay Harris — Wed, 08 Apr 2009 20:55:41 GMT

Torn between attending Lansing Give Camp or the Kalamazoo X Conference?
You don't have to choose; do both!

Give Camp or X Conference?

The first ever Lansing Give Camp is being held April 24-26. The first ever Kalamazoo X Conference is being held April 25. The sessions of the X Conference offer a great opportunity for learning and for improving your craft. For $20, you can't beat that. But Lansing Give Camp is a weekend of giving back to the community by helping out local charities. Coding for a cause; you can't beat that, either. Two amazing events, slightly more than an hour from each other, are being held the same weekend. It's like a bad case of deadlocked threads. Kalamazoo or Lansing? Lansing or Kalamazoo? How do you choose between them?

You don't have to choose. Go to both.

Spend the weekend in Kalamazansing!

Kalamazoo X Conference and Lansing Give Camp have partnered together. Lansing Give Camp will have special projects that will accommodate X Conference attendees. Kalamazoo X Conference is waiving its registration fee for anyone attending Lansing Give Camp. Friday night, come out to Give Camp. Saturday morning you can grab a shower (thanks to a partnership with the Lansing YMCA), and head out to Kalamazoo. When the event is over, finish out the weekend back in Lansing, coding for a cause. It's almost like one big event, spread between two Michigan cities. Kalamazansing.

I want to go to Kalamazansing!

Sign up Lansing Give Camp at http://www.lansinggivecamp.org. The registration form includes an option to sign up for the X Conference, too. We'll take care of the rest.

Technorati Tags: X Conference,Kalamazoo,Lansing,Give Camp,Kalamazansing

Lansing Give Camp 2009, April 24-26

Jay Harris — Wed, 08 Apr 2009 16:50:07 GMT

On April 24th-26th, 2008, the local software development communities will pool their talents to put together the first ever Give Camp in Lansing Michigan. The event will be hosted at the Impression 5 Science Center in downtown Lansing. For more information, please visit the event's web site, http://www.lansinggivecamp.org.

Lansing Give Camp

April 24-26 at the Impression 5 Science Center
200 Museum Drive, Lansing, MI 48933
http://www.lansinggivecamp.org

What is a Give Camp?

A Give Camp is a weekend-long event where software developers, designers, and database administrators donate their time to create custom software solutions for non-profit organizations. This custom software could be a new web site for the nonprofit organization, a small data-collection application to keep track of members, or an application for the Red Cross that automatically will email a blood donor three months after they've last donated blood to remind them that they are again eligible to donate blood. The only limitation for a Give Camp project is that it must be scoped to be completed within a weekend.

During the event, developers are welcome to come and go as they please. The event will continue 24/7 from Friday afternoon through Sunday afternoon, and developers can choose to go home in the evenings or camp out for the entire weekend. Showers are not available at the Impression 5 facility, but the Lansing YMCA--just down the street--is donating their facilities throughout the weekend for any Give Camp attendees.

How can I help?

If you are a developer and are interested in attending, please go to the event web site and register for the event. We are looking for developers of all skill levels to help out, from students to senior developers, and for developers of all skill sets, including designers, developers, database administrators, and more. If you can code, we want you there!

What about Sponsorship?

Lansing Give Camp is seeking cash donations of any amount, or the sponsorship of a meal. A meal sponsorship would entail funding breakfast, lunch, or dinner for roughly 100 volunteers. Typical meals would be sandwiches, pizza, or BBQ. As consideration for your donation, your organization’s logo will be added to the Give Camp web site, along with mention during the opening and closing sessions.

Technorati Tags: Lansing,Give Camp,Charities