Mike Christensen: Web Dev Guy : ASP.NET

Great ASP.NET site

mikechr — Thu, 29 Jun 2006 03:25:00 GMT

Here’s a great site for developers that aggregates a bunch of other ASP.NET blogs, making it easy to find new information all on a single site. Check it out!

http://www.dotnetslackers.com/

More about type descriptors

mikechr — Wed, 31 May 2006 02:18:00 GMT

The other day, one of my readers posed a question regarding my recent post “Data Binding to Custom Objects” – The question was essentially “Why are you writing all this code? There’s much simpler ways to do the same thing.” Well, the reader is correct. There are many ways to do this same thing. We’ll go over that in a second. First, let me take a shot at defending myself. All over the web, there’s thousands of web sites and articles, blogs and newsgroups, discussion lists and bulletin boards all about “how to do stuff in .NET.” This is great, and it helps you find the information you’re looking for to solve the problem that you currently have in front of you in your day to day jobs. However, the truly great programmers are the ones who know what’s going on behind the scenes. Managed languages such as Java, VB and C# get a lot of criticism from the more “pure programmers” who prefer to work more low level with C and assembly. Some claim there’s an entire generation of programmers who will never write their own memory manager, never create a linked list class from scratch, don’t know how a hash table works internally, don’t know how pointers really work, and don’t know the difference between memory allocated on the stack and memory allocated on the heap. I would disagree and say that it’s not the language itself that’s directly responsible for this new “generation” of programmers, but the complexity of the APIs they depend on. If you took the .NET framework out of C#, you’d have nothing more than a object-oriented language that still relies on the developer to construct these sorts of collection objects and design algorithms. This is no different than the plethora of ready made objects MFC provides for C++ Windows programmers. A language is simply an abstract way of expressing an idea, but those more familiar with the internal workings of a language will be the ones who can exact their ideas in a clear and more precise manner. Just because the .NET framework comes with a Hashtable class doesn’t mean you shouldn’t know how to write your own, and just because the .NET framework can take care of property descriptors for you doesn’t mean you shouldn’t learn how they work.

This new generation is not because of lazy programmers, or programmers who didn’t learn the basics. Programmers in general will learn what they need to do their job, and no matter how low level you get, there’s always a level of abstraction. Assembly programmers said this about C, C programmers said this about VB. Until you want to write everything in pure machine code, running in ring 0, on your own CPU design that you soldered together in your basement, you’re relying on a framework that makes your job easier. What’s to blame is this concept of “rapid application design” which VB started. It became critical to toss together these quick little applications in a fraction of the time it would take with more low level languages. IDEs started doing the boring work for you, which is great as long as you know what’s going on. Which leads me back to my original point – there’s plenty of places on the net to find out how to do something, this blog is dedicated to explaining how things works underneath. There’s only so far you will get memorizing what APIs to use where, but I promise you it’s always worth the time to really dig into something and learn what’s going on, for when you need to modify how something behaves or figure out how to fine tune something, you’ll have a pretty good idea of how to do that.

So use my article as a learning tool, this is how the data binding code works internally and this is how ADO.NET works inside. Now, if you’re simply wanting to bind a collection of simple objects to a grid, you can rely on “default type descriptors” rather than generating your own custom type descriptor as described in my article.

Take the following class:

class Company

{

private string _name;

private string _address;

public string Name { get { return _name; } }

public string Address { get { return _address; } }

public Company(string name, string address)

{

_name = name;

_address = address;

}

It couldn’t be simpler, it has two string properties and a constructor. I can bind it to the Data Grid like so:

protected void Page_Load(object sender, EventArgs e)

{

List<Company> list = new List<Company>();

list.Add(new Company("Microsoft", "123 Main"));

list.Add(new Company("IBM", "333 Main"));

Grid.DataSource = list;

Grid.DataBind();

}

My grid doesn’t change, it still binds to the “Name” and “Address” property of the object. Internally, the grid still asks List<> for an enumerator, which List<> provides. Each “Company” object in the list doesn’t provide a custom type descriptor, so a default type descriptor is used. This type descriptor will look for a public method matching the names of the bound fields. Note this must be a method, not a property (if I mark _name public and bind to that, I’d get a runtime error.) This works great for the simple case, but those who used this method without first writing their own custom type descriptor would have no idea why this works, or how they can manipulate or extend this system to do exactly what they wanted. Suppose later on, I wanted to provide some dynamic array of properties, such as items created by the user, or retrieved from a database. I’d be totally lost and never know how to create my own custom type descriptors. Hopefully some people out there got some use from my post, and there will be some better, more efficient code out there because of my efforts.

Thanks for the comments,

Mike Christensen – Web Dev Guy

The Paradox of ViewState Events

mikechr — Thu, 18 May 2006 11:28:00 GMT

I thought I’d write a quick blog about a somewhat “Chicken and Egg” style paradox with viewstate events, and events that cause different controls to be rendered out on the page. As you might know, ViewState events are processed between Page.OnLoad and Page.OnLoadComplete, and if the object that the event is fired upon doesn’t exist in the page control hierarchy yet, the event is lost never to be fired again. However, what if you want to add different controls to the page depending on which event was fired, and these controls themselves have events. Most of you are going, “Huh?”

Take the DataGrid control for example. When you call DataBind(), the control creates its control hierarchy. This involves creating a header row in the grid, and the header row has a bunch of cells, each containing Hyperlink objects. These Hyperlink objects have OnServerClick events and allow the grid to change the sort direction. So we know the header row must exist before OnLoadComplete happens, otherwise the Sort event would never be fired. However, this presents us with a problem where the only solution is to create the entire grid control hierarchy twice when the grid is resorted. This can be expensive if you have either a boat load of rows, or some really expensive data binding operation going on. Can it be avoided?

Well, here’s the fundamental problem. Events fire on the child controls (such as the Hyperlink itself). If the authors of DataGrid thought more carefully about performance, they might have avoided this scenario. The way I would have designed it (and I did design our Project Web Access DHTML grid in this way) would be to have the grid implement IPostBackEventHandler. The sort commands, page commands, etc would fire an event that happens on the grid object itself, not the Hyperlinks within the grid’s child control hierarchy. This way, building the control hierarchy could wait until after all viewstate events were processed, and then we knew our final page, final sort order, final everything else and could just generate grid rows once. This would also avoid the grid’s complex “event bubbling” code which is just weird (don’t get me started.)

It would be possible to modify the DataGrid to do this by first implementing IPostBackEventHandler, then overriding the rendering of the title cells. You can do this by writing your own column classes, overriding InitializeCell, and creating your own hyperlink when itemType is ListItemType.Header. The url on the hyperlink would look something like:

link.NavigateUrl = Owner.Page.ClientScript.GetPostBackClientHyperlink(Owner, "Sort " + ID);

The RaisePostBackEvent() method on the grid would look for “Sort <ColumnID>” and fire the OnSort event, etc. Will this optimization give you a noticeable perf improvement? Probably not in most situations, but it’s something to think about when writing your own custom web controls that respond to viewstate events.

Mike – Web Dev Guy

Data Binding to Custom Objects

mikechr — Thu, 18 May 2006 09:18:00 GMT

I’m back!

I apologize for my lack of recent blogging, but this post should help make up for that. We’ll be discussing data binding to custom collection objects. After reading my blog on building your own data bound controls, you’ll know that I like to stress the importance of avoiding unnecessary conversions between one data format to another. It’s completely unnecessary to create a DataSet object simply to bind it to a grid control unless your data was already in the form of a DataSet in the first place (for example, retrieved through ADO.) If you’re building your own collection classes anyway, you might as well make them expose the proper interfaces to be bindable. Once you do that, you can simply set them directly to the DataSource property of any .NET control and you’re set.

So how does one make their collection class into a source for data binding? If you haven’t yet read my blog on building your own data bound controls, I suggest you stop now and read that first. It will explain how data bound controls work and how they actually access the data in objects they’re data bound to. You’ll then have a pretty good idea of how these controls work internally and what they would expect from any custom data source object.

To recap, data bound controls such as the DataGrid and GridView controls expect data sources to be Enumerable. This means they implement IEnumerable or IEnumerable<T> (in .NET 2.0.) Not only that, each item in this enumerable list is expected to support property descriptors (usually by implementing ICustomTypeDescriptor.) In the .NET framework, you can find a few examples of objects that implement ICustomTypeDescriptor such as DataRowView. One can see how this fits in, a DataTable exposes an enumerable list (the Rows object) that expose a collection of DataRowView objects which implement ICustomTypeDescriptor. When you bind to a column in this table, the grid accesses the value of each column by calling GetProperty on the type descriptor. The grid knows nothing about DataViews or ADO data types, but type descriptors allow you to look up a property of an object using a string.

So let’s get to work. First off, I’ll be using the new GridView ASP.NET control because it’s new and cool, but you can use any control that supports data binding since they all work the same. My web page will display a list of high tech companies and provide a full mailing address. So here’s my web page:

<body>

<div>

<center>High-Tech Company Phone Book</center><br />

<asp:GridView runat="Server" ID="Grid" AutoGenerateColumns="false">

<asp:BoundField HeaderText="Name" DataField="Name" />

<asp:BoundField HeaderText="Address" DataField="Address" />

<asp:BoundField HeaderText="City" DataField="City" />

<asp:BoundField HeaderText="State" DataField="State" />

<asp:BoundField HeaderText="Zip" DataField="Zip" />

</Columns>

</asp:GridView>

</div>

</form>

</body>

</html>

I swear I’m really a brilliant web designer but for this example, I’ve created the ugliest page known to man. I have a single GridView control that has some columns defined. This is exactly what I would do if I were using a DataSet as my data source. For those interested on the new GridView control, check out this blog (I hope she gives me a link back!)

I also have a code behind for this page:

public partial class _Default : System.Web.UI.Page

{

GridBinding binding;

protected void Page_Load(object sender, EventArgs e)

{

binding = new GridBinding();

binding.AddRow("Microsoft Corp", "One Microsoft Way", "Redmond", "WA", 92020);

binding.AddRow("Apple", "1 Infinite Loop", "Cupertino", "CA", 95014);

binding.AddRow("Google Inc.", "1600 Amphitheatre Parkway", "Mountain View", "CA", 94043);

binding.AddRow("IBM Corporation", "1133 Westchester Avenue", "White Plains", "NY", 10604);

Page.DataBind();

}

public override void DataBind()

{

Grid.DataSource = binding;

Grid.DataBind();

base.DataBind();

}

My class has a member variable of type GridBinding called “binding” which is set to the DataSource property of the Grid. GridBinding is a class I’ve created that holds a collection of rows of data. The class has a public method called AddRow that allows me to add a new row, passing in address information for my phone book. As you can imagine, this data structure might be created in some other way, returned via a web service, serialized in a database somewhere, or generated on the fly through some sort of user interaction. The reason I can set this object to the DataSource property of the grid is because the object implements IEnumerable.

So let’s take a look at GridBinding. You might imagine I’ve implemented some huge collection class with various methods to work with the data, but you’ve underestimated by laziness. I’ll just be storing the data using a private List<> variable and implementing IEnumerable<>.

public class GridBinding : IEnumerable<GridRow>

{

private PropertyDescriptorCollection _propDescCol;

private List<GridRow> _rows;

public GridBinding()

{

_rows = new List<GridRow>();

_propDescCol = new PropertyDescriptorCollection(new GridPropertyDescriptor[0]);

_propDescCol.Add(new GridPropertyDescriptor("NAME"));

_propDescCol.Add(new GridPropertyDescriptor("ADDRESS"));

_propDescCol.Add(new GridPropertyDescriptor("CITY"));

_propDescCol.Add(new GridPropertyDescriptor("STATE"));

_propDescCol.Add(new GridPropertyDescriptor("ZIP"));

}

public void AddRow(string name, string address, string city, string state, int zip)

{

GridRow row = new GridRow(this, name, address, city, state, zip);

_rows.Add(row);

}

public PropertyDescriptorCollection GetPropertyDescriptorCollection()

{

return _propDescCol;

}

IEnumerator<GridRow> IEnumerable<GridRow>.GetEnumerator()

{

return _rows.GetEnumerator();

}

IEnumerator IEnumerable.GetEnumerator()

{

return _rows.GetEnumerator();

}

So let’s walk through this. First, I have a PropertyDescriptorCollection called _propDescCol. This is a collection of PropertyDescriptor objects. A PropertyDescriptor object is an object that knows how to get a specific property on a certain type of object. If you have a DataRowView object, this object contains a PropertyDescriptor for each column in your row, and the PropertyDescriptorCollection allows you to find the PropertyDescriptor you need when you try to access a property on this row. I could have a PropertyDescriptorCollection in each of my rows, but since they’re all the same, I’ve moved this into the GridBinding class for efficiency (so they’ll only be created one time.)

Next, I have a List<> of GridRows. My GridRow class allows me to store a specific row of information. I can add as many rows as I want using the AddRow method.

In the constructor, I create a new PropertyDescriptorCollection and create a PropertyDescriptor for each property that I want to allow users to bind to. I pass in the name of the property on the constructor, and this is what you’ll use when you’re binding to that property in the grid control.

I’ve also added a method called GetPropertyDescriptorCollection() that allows the GridRow object to retrieve the PropertyDescriptorCollection object.

Lastly, to fulfill the requirements of the IEnumerable<> interface, I’ve implemented GetEnumerable as both a normal and generic method. This simply returns the IEnumerator from my List<> class since I’m using this to store all my rows.

Pretty simple so far, right?

Next, let’s look at the GridRow object:

public class GridRow : ICustomTypeDescriptor

{

private GridBinding _binding;

private string _name;

private string _address;

private string _city;

private string _state;

private int _zip;

public string Name { get { return _name; } }

public string Address { get { return _address; } }

public string City { get { return _city; } }

public string State { get { return _state; } }

public int Zip { get { return _zip; } }

public GridRow(GridBinding binding, string name, string address, string city, string state, int zip)

{

_binding = binding;

_name = name;

_address = address;

_city = city;

_state = state;

_zip = zip;

}

System.ComponentModel.AttributeCollection ICustomTypeDescriptor.GetAttributes()

{

return new System.ComponentModel.AttributeCollection(null);

}

string ICustomTypeDescriptor.GetClassName()

{

return null;

}

string ICustomTypeDescriptor.GetComponentName()

{

return null;

}

TypeConverter ICustomTypeDescriptor.GetConverter()

{

return null;

}

EventDescriptor ICustomTypeDescriptor.GetDefaultEvent()

{

return null;

}

PropertyDescriptor ICustomTypeDescriptor.GetDefaultProperty()

{

return null;

}

object ICustomTypeDescriptor.GetEditor(Type editorBaseType)

{

return null;

}

EventDescriptorCollection ICustomTypeDescriptor.GetEvents(Attribute[] attributes)

{

return new EventDescriptorCollection(null);

}

EventDescriptorCollection ICustomTypeDescriptor.GetEvents()

{

return new EventDescriptorCollection(null);

}

PropertyDescriptorCollection ICustomTypeDescriptor.GetProperties(Attribute[] attributes)

{

return _binding.GetPropertyDescriptorCollection();

}

PropertyDescriptorCollection ICustomTypeDescriptor.GetProperties()

{

return ((ICustomTypeDescriptor)this).GetProperties(null);

}

object ICustomTypeDescriptor.GetPropertyOwner(PropertyDescriptor pd)

{

return this;

}

This is a bunch of code, but you can ignore most of it. ICustomTypeDescriptor supports all sorts of stuff that most of the data bound controls in .NET don’t take advantage of. The first part is easy – I have properties for name, address, city, state, and zip. You must set all of these using the constructor.

Now, let’s go over the ICustomTypeDescriptor methods that we’ll be using here. The most important one is GetProperties(). GetProperties allows you to retrieve PropertyDescriptor objects for all properties or even a specific set of properties. These descriptors are returned back to you in the form of a PropertyDescriptorCollection object. My implementation returns all properties regardless of what you pass in, and as you can see, just calls GetPropertyDescriptorCollection on the GridBinding object. When the GridView control is data binding, it will call GetProperties() and then call Find Property() to seek the PropertyDescriptor for the property that you’re attempting to bind to.

So, in our case, what does GetPropertyDescriptorCollection return? Well, it doesn’t return a PropertyDescriptor object (since this class is abstract), but instead returns a collection of GridPropertyDescriptor objects. This is a class I’ve created to describe a specific property on a GridRow object. In the constructor for GridBinding, we created one of these objects for each property the GridRow class exposes. To my knowledge, there’s no property descriptors built in to .NET, and the ones used internally (such as the one used in DataRowView) are marked as internal. So let’s take a look at the code for GridPropertyDescriptor.

public class GridPropertyDescriptor : PropertyDescriptor

{

private string _propName;

public GridPropertyDescriptor(string propname) : base(propname, null)

{

_propName = propname.ToUpper();

}

public override bool CanResetValue(object component)

{

return false;

}

public override Type ComponentType

{

get { return null; }

}

public override object GetValue(object component)

{

GridRow row = component as GridRow;

if (row != null)

{

switch (_propName)

{

case "NAME":

return row.Name;

case "ADDRESS":

return row.Address;

case "CITY":

return row.City;

case "STATE":

return row.State;

case "ZIP":

return row.Zip;

}

return null;

}

public override bool IsReadOnly

{

get

{

return true;

}

public override Type PropertyType

{

get

{

return null;

}

public override void ResetValue(object component)

{

}

public override void SetValue(object component, object value)

{

//TODO: Set value on component the same way GetValue works...

}

public override bool ShouldSerializeValue(object component)

{

return false;

}

Again, most of this code can be ignored. Let’s go through each method.

First, there’s a private string called _propName. This stores which property of the GridRow this descriptor will be responsible for accessing. This is to be set on the constructor.

The main method here is GetValue. You pass in an object of type GridRow (it would be cool if PropertyDescriptor was a generic class, but it’s not so we have to cast.) Depending on the value of _propName, we return a different property on the GridRow object. If you pass in an object that isn’t of type GridRow, it would return null. Also, if you created a GridPropertyDescriptor with an invalid property name, this would also return null. Perhaps it would be best to check for this, or maybe use an enum for the property name. However, this is just an example so it’s not too important.

The other methods are pretty self-explanatory. Most of them focus on providing information about the property – what type of data it is, if you can change it, if you can serialize it, if you can reset it back to its original value, etc. The method you would need to implement if you wanted to support editing in your grid is, of course, the SetValue method. This method takes a component and a new value. To implement this, you would do the same thing as GetValue only set the value of the property in the GridRow class instead of just return it.

That’s pretty much it! When I run my page, I get the following output:

High-Tech Company Phone Book

Name	Address	City	State	Zip
Microsoft Corp	One Microsoft Way	Redmond	WA	92020
Apple	1 Infinite Loop	Cupertino	CA	95014
Google Inc.	1600 Amphitheatre Parkway	Mountain View	CA	94043
IBM Corporation	1133 Westchester Avenue	White Plains	NY	10604

It’s pretty ugly, I know, but this isn’t an article on how to create pretty grids – there’s already enough of those. Hopefully this gives you a good deal of insight about how data bound controls work and how classes such as DataRowView and Hashtable implement property descriptors to abstract property access. So next time you want to new up a DataSet just to bind to a control, think about writing your own collection class that supports being bound to a data bound control.

Enjoy!

Mike – Web Dev Guy

PS – This blog was posted using the new blog publishing feature in Word 2007, pretty cool!

Templates - Part 2

mikechr — Wed, 26 Apr 2006 11:24:00 GMT

In my last article, we talked about writing custom web controls that could render UI based on a template. Controls are able to parse properties between their opening and closing tags. These properties can set various public attributes of the control itself or populate the control’s child control collection. These properties can also be ITemplate attributes, in which case ASP.NET is able to create an instance of a template that our control can use for whatever purpose it wishes.

In this part, I’ll be discussing taking this one step further and creating an architecture that can fully abstract control UI using an ASCX file.

Many ASP.NET developers have used ASCX files to define web controls that get compiled at run time. These files behave as “mini web pages” and like web pages have HTML code, server side controls, and server side code. These are nice because they provide developers a way to encapsulate their UI in a separate file without having to “hard code” HTML elements within their code or call Controls.Add() a bunch of times. However, how can one create an instance of these ascx controls at runtime? Well, ASP.NET’s page parser has to do it some how, so how does that work? Let’s take a look.

Once you know that the Page class is actually derived from Control, it’s easy to see how an entire page is nothing more than a control with its child controls specified in an ASPX file, and a web control is the same thing with a different extension. When the page parser comes across a reference to another control, and the reference for that control points to an ascx file, the file is opened and parsed using the Page.LoadControl method. LoadControl has an overload to specify a file name to load the control from. This filename can be (well, should be) an ascx file. LoadControl returns an instance to that control.

So where can this come in handy? Well, let’s take a look at a few examples. The first is this application I’m using right now to post my blog – Community Server 2.0. This software allows blog administrators to upload files to customize the look and feel of their blog site. These files are in the forms of ascx files, and have references to server side web controls to use used as place holders for various blog content. These controls are used to render menus, links, and blog content itself. Taking a look at some of the sample templates will give you a good idea of how everything works. Now, I’ve never seen the source code for Community Server, but I can imagine they call LoadControl to load these user uploaded ascx files into memory from their base class and populate the page’s child controls.

Another example is SharePoint. SharePoint has an entire directory of control templates for their various templated controls. One is DefaultTemplates.ascx which contains a huge list of “RenderingTemplate” instances. The file is loaded in with LoadControl which returns a control collection with all the various templates from the file. Controls.FindControl() can be used to locate the specific template needed.

Should you create one big file for all your templates like SharePoint does? I don’t know, it’s up to you. But in my production code, I have about 20 templates in a single file and it takes no detectable time to parse the entire file. Only the constructors of each object would be called and memory allocation is so blazing fast in managed code, it’s probably not a big deal. But if it makes you feel better, you can create a separate file for each template.

So let’s build a control that can use an ascx file, shall we?

First, we need a control that acts as a container for the template. The template within the container can interact with the outside world through this container class, so anything you template needs access to (such as DataItem) needs to be accessible through this class. You can refer to this instance of this class using the reserved “Container” keyword, such as Container.DataItem. It’s all starting to come together in your head by now, isn’t it?

public class MyTemplateContainer : Control, INamingContainer

{

private TestControl _control;

public TestControl Control

{

get { return _control; }

}

public MyTemplateContainer(TestControl control) : base()

{

_control = control;

}

Our container control is called MyTemplateContainer and only has a single public property called TestControl. We’ll use this as a reference to the parent control that’s rendering the template.

Next, we need a control to reference withinin the ASCX file itself. This control represents a single template instance. When we call LoadControl, we create an instance of this control.

[ParseChildren(true)]

[PersistChildren(false)]

public sealed class MyTemplate : Control

{

private ITemplate _template = null;

[TemplateContainer(typeof(MyTemplateContainer))]

public ITemplate Template

{

get { return _template; }

set { _template = value; }

}

This can have any number of properties which you can set declaratively in the ascx file, but our example just has a single property called “Template”. ASP.NET will automatically set this property based on the contents of the ascx file. So what does our ascx file look like? Well how about something like this:

<%@ Control Language="C#" %>

<Test:MyTemplate ID="MyControl" runat="server">

<table>

<ASP:TextBox Text="<%# Container.Control.TestProperty %>" runat="Server" />

</td></tr>

</table>

</Template>

</Test:MyTemplate>

When we load this ascx file into memory, we create a “Control” object that has a single child control called MyControl that is of type MyTemplate. Inside the <Test:MyTemplate> tag, ASP.NET recognizes “Template” as a public property of the MyTemplate class. It parses the HTML inside the <Template> tag and creates an instance of an ITemplate object. Through the [TemplateContainer] attribute it knows that Container will be an instance of “MyTemplateContainer” so it can verify Container.Control.TestProperty is a valid expression. It would of course be possible to set other properties on the MyTemplate object and read them at runtime. You can also just as easily define other templates, such as Header templates, footer templates, item templates, etc.

Now what about our control itself? Let’s take a look at how to load this ascx file, read the templates, and use them to populate our control at runtime. Here’s what the control code looks like:

public class TestControl : Control

{

public string TestProperty = "Hello World!";

protected override void OnInit(EventArgs e)

{

Control control = Page.LoadControl("ControlTemplate.ascx");

if (control != null)

{

MyTemplate t = control.FindControl("MyControl") as MyTemplate;

if (t.Template != null)

{

Controls.Clear(); //Clear any existing controls

MyTemplateContainer TemplateContainer = new MyTemplateContainer(this);

t.Template.InstantiateIn(TemplateContainer);

Controls.Add(TemplateContainer);

}

base.OnInit(e);

}

Let’s step through this. First, we have a control called TestControl derived from Control. We can place this control on any page we want, or new up an instance of this control at runtime. This control can even be a Web Part that lives in a serialized state in a database some where. It doesn’t really matter since we load the template we need at runtime.

During OnInit, we load our template file into memory and populate our child controls. Let’s step through this:

1) We call Page.LoadControl() to load in our ascx file (defined above.)

2) LoadControl returns a single control that contains all the controls in our file. We know we only have one and we know it’s called MyControl. We know it’s of type MyTemplate so we can use FindControl to locate it.

3) If we found such a control (nobody’s been mucking with our file) and it has a valid Template property, we create a new template container.

4) Through the ITemplate interface, we instantiate our template within the template container.

5) At this point, TemplateContainer will have a populated Controls hierarchy with everything in our template.

6) Now, we simply add the TemplateContainer instance to our control’s child control collection.

Easy enough? Now we have a control that can dynamically load a file on the file system at runtime to populate its UI. This is how SharePoint allows administrators to customize web part and list UI, and this is how applications such as Community Server allow administrators to customize its UI. This allows controls that may appear on dozens of web pages on a single site to all share a common UI template that isn’t “hard coded” into compiled code. Pretty cool, eh?

One thing I thought I’d mention that I ran into when I was experimenting with this stuff initially. The code that builds an ITemplate instance from your <Template> property is not quite as advanced as the default page parser in ASP.NET. It seems you can not do stuff like bind event handlers to server side controls. For example, I cannot do this:

<table>

<ASP:TextBox OnChange="<%# Container.Control.HandleChange %>" runat="Server" />

</td></tr>

</table>

Where HandleChange is a public event that matches the delegate for TextBox’s OnChange event. Event binding is not something this parser supports. However, I would assume it would be possible to write your own “LoadControl” override that can parse the <Template> property and return your own implementation of ITemplate whose IntiantiateIn implementation can bind event handlers. If someone gets that working, I’d love to hear about that.

Let me know if you have any questions!

Mike

Templates - Part 1

mikechr — Tue, 11 Apr 2006 00:48:00 GMT

ASP.NET is, to perhaps oversimplify things, a template parser at heart. An HTTP Handler (anything that implements IHTTPHandler) can be configured to process HTTP web requests and render results for those requests back to the socket. This inferface is quite simple; IHTTPHandler::ProcessRequest is called which is given an HttpContext representing the HTTP request made to the server. ProcessRequest writes a bunch of bytes out to HttpContext.Response (an HTTPResponse object.) IIS handles the rest.

This is great abstraction because it doesn’t force people who like managed code (like me) to use ASP.NET, which might not meet their needs. Nothing would stop you from writing your own HTTP handler and completely inventing your own ASP.NET. In fact, SharePoint has its own HTTP handler that is able to build dynamic web part pages using serialized instances of “web part” controls from a content database, and map other requests to static “layouts” pages to an installation directory containing these files. There are certain charting components that can handle HTTP requests to GIF files and dynamically build a GIF image and write out the bytes to the response stream. IIS is able to map different file extensions to different IHTTPHandler classes via the web.config file.

For those not so ambitious, ASP.NET conveniently provides its own HTTP hander known as System.Web.UI.PageHandlerFactory. This is what you use out of the box and does all the work opening your ASPX files, parsing junk, building Page objects, etc.

PageHandlerFactory figures out what file you’re looking for, opens the file on disk, and parses this file. A “Page” object is created to represent the page with all of its controls. ASP.NET uses a series of server side markup tags to represent these web controls. These web controls are marked with a “runat=server” attribute. For each control it finds, the ASP.NET page parser instantiates an instance of this control, adds it to the control hierarchy, calls all sorts of various methods on it during the life cycle of the Page object, and is able to build a response stream at the end. Other static text is represented as LiteralControl objects. During the Render stage of the page, ASP.NET’s Page class simply calls Render on its top level controls which recursively call Render on each of their child controls.

ASP.NET’s template parsing code is pretty flexible, and in fact you can take advantage of this code in your own controls. You may have noticed certain web controls that have properties of type “ITemplate”. These properties are useful in declarative code in an ASPX file, but not all that useful in code behinds. One example is the Repeater control. This control can repeat some text for each item in some sort of enumerable data source, and can access properties of the current data item. For example:

<ASP:Repeater id="MyList" runat="Server">

<table>

</HeaderTemplate>

</ItemTemplate>

</table>

</FooterTemplate>

</ASP:Repeater>

This control takes a data source, enumerates through it and builds a table with the items found in the datasource. So what are “HeaderTemplate” and “ItemTemplate”? Are they built in to ASP.NET? How are they implemented? Well, you might have already spotted there are ITemplate properties on the Repeater class. ASP.NET is kind enough to build an object that implements ITemplate and set it to these properties of your control for you. So then what does the Repeater control do with them? How can it programmically access the contents of this template and do something useful with it? Also, what is “Container.DataItem” and “DataBinder.Eval?” Let’s take a look at what’s going on here.

So DataBinder is a .NET framework class that provides various data binding functionality, you may recognize it if you read my blog on building your own data bound controls. Eval is a static method that can grab a property (“MyItem”) from an object that exposes a property descriptor (Container.DataItem). If you have no idea what I’m talking about, go read the aforementioned blog. So what is Container? There is no Container class in the .NET framework. Well, Container is an object that represents the current control being generated. In the case of our Repeater control, this is a RepeaterItem object which maps to a specific item in the data source.

When Repeater is databound, it loops through its data set and for each item it finds, it creates a RepeaterItem control. RepeaterItem has a DataItem property that the Repeater control sets to the current item in the data source.

When each RepeaterItem is initialized, Repeater will build the child control collection of that RepeaterItem object by calling the InstantiateIn method of ITemplate:

myTemplate.InstantiateIn(item);

myTemplate is an ITemplate that ASP.NET set for us based on what was in the ASPX file, and item is the RepeaterItem control being initialized. Once this is called, item.Controls will be populated with all the controls defined in the template. Some of these might be other server controls, and others would be LiteralControls representing static text. This is no different than had you called Controls.Add a bunch of times. Inside my template, I can access that instance of RepeaterItem using the “Container” object. Get it?

In my next part of this two part series, I’ll be going into a bit more detail and apply some of these techniques to real world scenarios. But in the mean time, go build a template-able control and see how everything works. They’re quite cool and make it easy for developers using your control to really control the UI layout without having to recompile code and set dozens of properties programmically.

Have fun!

Mike

Too many tiers? Writing efficient multi-tier web applications.

mikechr — Thu, 06 Apr 2006 07:53:00 GMT

A while ago, we were all convinced that dividing our applications up into multiple tiers was the way to go. This was great because it allowed you to scale up the parts of your application that might represent a bottleneck, and have more control over what resources were allocated to what tier. Windows DNA was built on this concept, as well as the whole “Duwamish” architecture. The problem is, this introduces the possibility of a very “sloppy” implementation of this ideal that creates a much larger bottleneck. This is especially true when using slower mechanisms to transport data across tiers.

Suppose you have a SQL Server backend that pretty much spends its time running stored procedures and returning back datasets. You’ve written a stored proc for anything anyone might want to do. You have a middleware component that connects to your SQL backend, and this provides a programmable API to access your SQL data via web services. This abstracts your actual data store from anyone who wants to program against it, and third parties can simply call into managed APIs to get the data they need. No one needs to run some SQL statement or stored proc that might change in the next version. There are no SQL injection attacks, and other problems with front ends running SQL commands. Life is great.

Then, you have a front end written in ASP.NET. This front end calls into your web services to get the data it needs. The problem comes along when the front end (web application) is too tightly coupled with the business layer (web services). The web application might call several of these web methods during various stages of rendering a page. It might call some APIs to validate the user’s credentials, and then call a web method that returns a dataset to bind to a control, also get some menu data, etc. For each of these web service calls, a stored procedure is run. Now, we pretty much have a 1 to 1 mapping between a web service call and stored procedure call. For large data sets, a high percentage (like 40-50% of the page rendering time is simply spent deserializing these datasets across the wire. This is especially inefficient when the web server is running on the same physical machine as the business layer. ASP.NET will open up a socket, connect to IIS, “POST” in a SOAP envelope, get the results, deserializer this back into a DataSet, then return a reference to this object. While this is happening, the thread serving your web page request is blocked waiting for this result (unless you’re using synchronous web service calls, but that’s a huge challenge to design properly.) Yes, it’s true “remoting” can solve some of these problems, as well as Indigo. If you have more users hitting your site than you have available threads, this can cause all sorts of perf problems. Mean while, until the next web service call comes along, your business layer machine is sitting around twiddling its thumbs.

When this architecture was designed, the ideal situation was the higher tiers (meaning the data layer and business layer) were also the lesser used tiers. The business layer would load in all the data it needed to run, cache it and providing an in-memory representation of the data to work with. At an appropriate time, the data could be written back to the database. The presentation layer would request the data it needed from the business layer and then render it into a form suitable to display to the user. In other words, calling into your business layer wouldn’t necessarily mean a call into your data layer unless new data was needed.

For load balancing reasons, everyone seems to want their middleware components to be stateless and not have to worry about caching data and data being out of sync with the database.

Using proper abstraction means that a single call doesn’t drill down into 80 different layers every time it’s called, otherwise why even have this abstraction? The same works for “abstracting” your application into logical layers. If every call is going to drill down into every single layer every time, why have the layers?

I think a better approach for certain applications, especially those who have very simple business logic (ie: just grab some data from SQL Server) is to write business objects as sort of a “data adapter.” My data adapter knows how to get my data from a SQL connection and provide an API for me to read and manipulate it. My data adapter should be in the form of a DLL that my web application links to. The DLL knows how to connect to the SQL Server that it’s configured to use. Multiple instances of my web server, each with their “data adapters” connecting to a cluster of SQL back-ends, can be running to scale up to the demands of my users. This is still a layer of abstraction, but doesn’t have a massive bottleneck marshalling the data across the wire between tiers. If my front end is super dependent on this data access API, each call should be as lightning fast as I can make it, and that means running it in the same process so I can just return a live pointer to my object.

I could also write a separate web service that also links to my “data adapter” DLL, but provides a SOAP based interface to my API. My application doesn’t need to use this, but third parties that wish to program against my backend can easily use this interface. There’s really no reason for my own application to be accessing my own business layer via SOAP, it’s inefficient and results in blocking threads and dragging down the CPU. The amount of effort it takes to marshal a large chunk of data across SOAP is simply not worth the extra scalability that I’m not convinced I’d really have anyway. In fact, connecting two tightly coupled tiers that are both owned by me and controlled entirely by me should not be talking in an extensible human readable, 7bit protocol – especially if I’m doing this 30 times for every page I serve up.

If you’re building such an application, I’d be interested in hearing your comments as far as architectural decisions and scalability, and if you’ve done any stress testing with large amounts of data, where your bottlenecks are. It’s my opinion that flattening out these tiers into a single process running ASP.NET code and an adapter that can connect to a data backend is the way to go, especially when using SOAP. I’d love to hear your comments!

Mike

Building your own data bound controls...

mikechr — Sat, 01 Apr 2006 09:14:00 GMT

In any Web Application, you have data bound controls. The job of a data bound control is to transform your data from some arbitrary format into the format it probably should have originally been stored in. In fact, about 90% of computer code simply converts some chunk of data from one arbitrary format to another arbitrary format.

Let’s say I have some data in a SQL Server which is stored in some highly optimized format on a disk somewhere. I can read it, but I access it through a connection that gives me that data in some sort of ADO.net record set format. This is great because I can return that object from my web service. The web service will serialize the data into SOAP. SOAP is a human readable representation of data that usually won’t actually be read by any humans. SOAP is great because it’s all text based so it supports 7bit token ring networks, so you don’t have to worry about upgrading your network.

So anyway, on your web front end you’ll get the SOAP and the deserializer will parse this text and build the dataset you just had a second ago. Then, you bind that dataset to an ASP.Net DataGrid control of some sort. This article will eventually detail exactly why that is so nifty after I’m done with my rant.

When DataBind is called, the grid control will loop through your dataset using its IListSource implementation. Inside, it builds DataGridRow objects which basically store the same thing as a DataRow, but since the DataGrid isn’t necessarily binding to a DataView, it has to create its own row abstraction. The grid does this and is happy, and then later on the framework calls CreateControlHierarchy. This tells all the controls to convert their data into a bunch of System.Web.UI.Control objects because that’s what ASP.NET likes to have around.

So the grid loops through its collection of DataGridRow objects and creates a bunch of TableRow controls, each one of those having a bunch of TableCell objects depending on what columns are bound to your grid. So ASP.NET has in memory this massive tree of Control objects. What does it do with it? Well it calls a bunch of stuff on each item such as OnInit, OnLoad, and OnPreRender. Oh, and somewhere in there it loads and saves the ViewState from some massive serialized blob.

Eventually, ASP.NET calls Render on all of these controls, and all Render does is translate the data into HTML, which is simply yet another representation of that same data. HTML comes in handy because it’s human readable and easy to transmit over your 7bit token ring network. Also it’s flexible and easy to work with since the standard is bound to change (if HTML were binary, FrontPage sales would have skyrocketed.)

So this is all transmitted over a socket and dumped out to whoever happens to be listening. Ideally, this ends up being parsed by a web browser, such as Internet Explorer. Internet Explorer eats up this nice HTML and builds a DOM (Document Object Model) out of it. This is a binary representation of your control hierarchy so IE can work with it (computers don’t like human readable text because they think humans are weak and inefficient,) manipulate stuff quickly, and present an object model to anyone who cares to program against it (like all you scripters.)

IE will finally draw this data out on the screen in a matter that’s pleasing to the eyes (for those of us who wouldn’t be able to look at The Matrix in its encoded form.)

So this is nice and efficient, we only looped through the same data about 100 times and didn’t really change anything. So what’s my point with all this? I’m not sure, but it would be cool if the control hierarchy that ASP.NET creates was the same as the one that IE uses, and we could just transmit it directly over the wire. Maybe someone wants to write that ActiveX control and IIS extension? No, actually what I’m saying is that often instead of focusing on how to optimize your for loop, you should be focusing on whether that loop is needed in the first place. Ok, end of rant – onto point of article.

.NET Data Bound Controls

So ASP.Net, well – actually pretty much the entire .NET framework – is quite nifty in the fact that you can pass any control a “DataSource” and it somehow magically knows how to read it and use that to populate itself. So what is a DataSource object anyway? Well, let’s see – I can pass in a DataSet which is nice. If it’s a small chunk of data that I can hard code into my program, I can pass in an Array or an ArrayList. If I need a key value pair, I can pass in a Hashtable. All of these work, that’s cool! So I bet these data bound controls have a bunch of “if _datasource is Array then do this” and “if _datasource is Hashtable then do that” blocks. But wait, I can write my own class and implement IEnumerable or IListSource and that works too.

So how do these data controls work and what if I want to build my own? Well, I sat down and read through a bunch of ASP.NET source code such as the DataGrid, DropdownList, Repeater, etc. They’re all pretty much the same and work in the same way. So I wrote my own little control that takes a data source and just dumps out the items to the console. It looks something like this:

class Program

{

static void Main(string[] args)

{

MyControl[] controls = { new MyControl(), new MyControl(), new MyControl() };

controls[0].DataSource = new string[] { "One", "Two", "Three" };

controls[0].Render();

controls[1].DataSource = Data.GetHashTable();

controls[1].DataField = "Value";

controls[1].Render();

controls[2].DataSource = Data.GetDataTable();

controls[2].DataField = "Name";

controls[2].Render();

}

As you can probably guess, Data.GetHashTable just “new”s up a hash table and returns that. Data.GetDataTable() creates a data set from an XML file and returns that. I won’t include the source to those things because it’s not all that exiting. So I run my program and it writes out to the console:

Writing object of type: System.String[]

One

Two

Three

Writing object of type: System.Collections.Hashtable

Fish

Cat

Dog

Writing object of type: System.Data.DataTable

Apple

Banana

Orange

Pretty amazing I think. So how does my control work? The same way all other .NET data bound controls work. First off, it supports binding two types of objects – IEnumerable and IListSource. IEnumerable would be a hash table, array, ArrayList, etc. An IListSource would be a DataSet, DataTable or DataView.

The first thing my binding code does is check if it’s an IEnumerable. If so, the job is pretty easy. My control likes IEnumerables.

IEnumerable list = null;

if (_datasource is IEnumerable)

{

list = (IEnumerable)_datasource;

}

Wow, that’s great. Now we have an object called “list” which is my data source as an IEnumerable. But what if it’s an IListSource? Well, if it’s an IListSource then I want to convert it into an IEnumerable because I want to foreach through it. For those of you who aren’t fluent in C#, “foreach” is basically just short hand for calling IEnumerable::GetEnumerator() which returns an IEnumerator, then calling MoveNext() a bunch of times of that. Thus, you can only “foreach” through an object that implements IEnumerator.

So anyway, if I have an IListSource I have the following snippet of code:

else if (_datasource is IListSource)

{

IListSource listsource = (IListSource)_datasource;

IList memberList = listsource.GetList();

list = (IEnumerable)memberList;

}

Weird, what does that all do? So first, IListSource has a method called GetList(). This returns an IList. Know what’s truly amazing and comes in handy? The fact that IList is derived from IEnumerable. Using that, we can set our “list” object to an IEnumerable (which can enumerate an IListSource.)

So now we can iterate through, uhh – stuff. What stuff? I don’t know. The Array class’s GetEnumerator() implementation returns an IEnumerator that can iterate through objects in the array. Hashtable returns an IDictionaryEnumerator which represents key/value pairs. DataTable returns a collection of DataRowView objects. So I can’t just print those out to the screen. Plus, I’m not sure exactly what item I want. Wait, didn’t my “DataField” property specify what item to get? How does that fit in? How can I get a property of these objects based on a string? Well the answer to that is in Property Descriptors.

Property Descriptors are among the niftiest .NET freatures and allow you to abstract property names from the actual implementation of a class. I can say GetProperty and pass in a string, and my class knows what to return. Hashtable, DataRowView, etc all implement property descriptors which allow this to work. GetProperty on a DataRowView expects a name of a column, which is why you can set the DataField to a column name. Hashtable expects the string “Key” or “Value” which is why you can bind to a hashtable. One of these days, I’ll write a whole article on property descriptors and how can you write your own, but in the mean time we’re going to cheat and use a utility method that is part of the .NET framework. The DataBinder class has all sorts of methods that come in handy for people writing data bound controls. One of these methods is GetPropertyValue. You can pass in an object and which property you want to get, and even an optional formatting string, and it returns back a string for you. Using this, our foreach loop looks like this:

foreach (object obj in list)

{

string text;

if (_datafield != null)

text = DataBinder.GetPropertyValue(obj, _datafield, String.Empty);

else

text = obj.ToString();

Console.WriteLine(text);

}

Well there you have it. You can now write your own data bound controls that work just like the ones that come with ASP.NET! Play around with this, see what sorts of data you can bind to your control and try writing your own collection classes as well. In my “Property Descriptors” article, I’ll be writing a collection class that you can bind to the ASP.NET DataGrid if you’re too cool for DataSets. Stay tuned!

Mike