Joel's SharePoint Architecture Blog

SharePoint Server, SharePoint Online and Office 365 Training, Architecture, Administration and Development

Do I Need To Invoke base.CreateChildControls in my WebParts?

by

This question was asked by one of my (most excellent) students this week:

In an ASP.NET Web Part for SharePoint, when I override CreateChildControls(), do I need to invoke the base?

You will see many examples on the Internet of code that does invoke the base, and many counter examples. Some of these contradictory examples are on the Microsoft MSDN site!

I decided to take ILSpy to the System.Web.dll assembly and find out once and for all.

First of all, System.Web.UI.WebControls.WebParts.WebPart does not override CreateChildControls() itself.

System.Web.UI.WebControls.WebParts

So, we must take a look at it’s ancestor: Part.

System.Web.UI.WebControls.WebParts.Part

Once again, there is no implementation for CreateChildControls() here, so we go further up the chain to System.Web.UI.WebControls.Panel:

System.Web.UI.WebControls.Panel

Still no definition of CreateChildControls(). Further up, we get System.Web.UI.WebControls.WebControl.

System.Web.UI.WebControls.WebControl

But it is not until we get to System.Web.UI.Control that we have an implementation:

System.Web.UI.Control

Hang on a moment! That’s empty!

// System.Web.UI.Control
/// <summary>Called by the ASP.NET page framework to 
/// notify server controls that use composition-based 
/// implementation to create any child controls they contain
/// in preparation for posting back or rendering.</summary>
protected internal virtual void CreateChildControls()
{
}

So, the simple answer appears to be:

No, you don’t need to invoke base.ControlChildControls() in an ASP.NET WebPart”

Understanding ASP.NET Internals – Rob Howard (Telligent Inc.)

by

Thu, 15 Nov 2007 18:07:39 GMT

weblogs.asp.net/rhoward

An excellent session from another non-Microsoft presenter. Another one of these brain-the-size-of-a-planet guys who’s career seems to flit in and out of Microsoft. Rob worked at Microsoft on all versions of ASP.NET.

How the pieces fit together

ASP.NET is not just the page model we’re all used to. It’s also a complete request / response framework. You could implement php on it if you were that way inclined.

ISAPI extensions

ASP.NET under IIS6 is simply a single ISAPI extension dll. This means you can use multiple versions of the .NET Framework alongside each other without conflicts; each lives in its own worker process.

Under the ASP.NET wp, it creates the HttpRuntime. The separate wp gives us true independence between apps on the same box. IIS6 has a kernel-level driver called http.sys, and creates a worker process w3wp.exe.

Http.sys introduces a concept called Kernel Mode Caching. This takes page cached items and stores and retrieves it from the IIS level, without drilling into ASP.NET, which gives us a lot more performance.

Role of HttpRuntime

  • Customise and Extend ASP.NET
  • Perform special authentication
  • Take over .jpg extension
  • Provide developrs a great way to innovate

ASP.NET runtime infrastructure
ASP.NET doesn’t care where it’s hosted; that is completely abstracted. HttpContext is created on hitting a page, and is flowed throughout the page lifetime. HttpHaners include all the various extension type: .aspx, .asph, .asmx.

HttpRuntime is the Request / Response infrastructure. It has access to everything you have access to in normal pages, without the Page model.

HttpRuntime can be hosted outside ASP.NET. This means you can process pages and their events outside IIS. Example of this is the Cassini web server. Another possible use would be in a tool that mirrors and flattens web sites to stage as HTML.

Interception Events
Synonymous with ISAPI filters. Can be used for request participation or termination of events etc. Interception Events can be coded with either IHttpModule components or global.asax. You can specify the order of precedence is .config. ISVs writing pluggable components would use Modules. A single project would probably use global.asax. Both provide the same functionality, but Modules are pluggable.

Handler lifecycle
It’s good to get a canonical list of events in the right order. So here they are:

  1. BeginRequest
  2. AuthenticateRequest
  3. AuthorizeRequest
  4. ResolveRequestCache
  5. AcquireRequestState
  6. PreRequstHandlerExecute
  7. Target Handler Extension (e.g. Page /.aspx)
  8. PostRequstHandlerExecute
  9. ReleaseRequestData
  10. UpdateRequestCache
  11. EndRequest

SessionState Tips

  • Turn it off if you don’t need it
  • Set it to read-only if you can
  • Only set it to read-write where you’ll be updating it

HandlerFactory

A tool to help you create different Handlers for different request types.

HttpHandler

Enables processing of Urls. Similar to ISAPI filters.

HttpContext

Encapsulates all request information. One instance created for each request, flowed throughout request lifetime. Developers can extend HttpContext.

Page Lifecycle

For completeness, here is the canonical list of events that fire in the lifetime of a page.

  1. PreInit
  2. Init
  3. InitComplete
  4. PreLoad
  5. Load
  6. Target Control Events
  7. Load Complete
  8. PreRender
  9. SaveStateComplete
  10. Render
  11. Unload

Summary
The presentation was excellent. Some detailed info, some just old hat. The Handler and Module stuff, while not new techniques, are traditionally the domain of the more hardcore ASP.NET developers. The question is why this detail, and why now? Well, my take on this is that there is a feature uplift coming: modularised ASP.NET in IIS7. This will create a whole new space for developers to play and write Modules and Handlers as first class citizens of the IIS pipeline. Microsoft wants us to play in that space, so that means getting folks used to the existing concepts now.

Technorati Profile