Infinities Loop

If you can't beat 'em, work for 'em!

2006-08-03T01:19:00.000-07:00

Right. I'm happy to say, I've had the privledge of joining the ASP.NET team with Microsoft! As you may imagine, that has kept me busy lately. I have a few comments from readers that I haven't answered yet, but I will get to them, I promise :)

This means I'm moving my blog! Please redirect your bookmarks and RSS readers to:

http://weblogs.asp.net/infinitiesloop/

I transfered over the ViewState article since it's the most popular. I'll transfer over the rest... eventually.

I'll maintain this blog for a while. At least until the content is transfered. See you later.

TRULY Understanding Viewstate (again)

2006-07-26T00:45:00.000-07:00

It has come to my attention that many visitors here have found me via a google search related to ViewState or something similar. For example, here's a google ranking one could be proud of! Unfortunately, not all the search results link directly to the article they seek, and it is buried 6 posts back so they don't always find it. If you're interested in my article on understanding the viewstate process, this post is for you. It's received a lot of interesting comments lately, so I think it deserves a little /bump anyway :)

Bringing ViewState into the Light

2006-07-03T09:37:00.000-07:00

Download the source

YAVA (Yet another ViewState Article). For years now ViewState has remained hidden in the turbulent html source of our documents and applications. ASP.NET puts it there because, well, it isn't pretty. It's pretty ugly really.

Many ViewState Viewers are available that let you put on Base64 encoded glasses and see what's really in there. But sometimes I just want to have a good idea of what the size of my ViewState is on the various pages of my applications. If its too big, then I'll start thinking about optimizing it, which is when a decoder may come in handy. But to just get a feel for what its size is throughout my application, all I need is to look at the encoded string. But doing a "view source" every time is a pain.

ASP.NET 2.0 makes it easy to customize how ViewState is persisted. It even comes with two persisters of its own: HiddenFieldPageStatePersister and SessionPageStatePersister. Why not have a VisibleFieldPageStatePersister?

ViewState in all its glory

The cool thing about this simple persister is that it isn't just showing you what the ViewState is. The textarea is the field that the ViewState actually lives in. That means it's easy to change the ViewState for the page. Imagine you have a complex page with dozens of input fields on them, and you are trying to test a step in a process that is several steps behind those fields. It would be a pain to have to enter all those fields every time you wanted to debug. With this, you could copy the ViewState of the form at the point you'd like to return back to, and then assuming there were no server-side actions that you depend on having actually occurred, and ViewState is enabled on all the controls you need it for, you will instantly be back in that state.

WARNING: Do not let this make you think that ViewState is responsible for maintaining the state of posted input fields like TextBoxes and CheckBoxes. It isn't. Well it is, too. ViewState lets TextBoxes and such remember their state even when their value isn't naturally posted (such as when it's invisible, or people like us cheat the system as in this example). But normally TextBoxes and such remember their state simply because they are input forms, and even without ViewState their value is posted to the server. ViewState just makes it that much smarter at it (and enables things like TextChanged and CheckChanged events). So... if you have ViewState disabled on a TextBox, for example, this little trick won't restore it's state.

Here's an example. On this page, the "Click here!" button changes the label of the page, like so:

ViewState jumps by 128 bytes here

If we copy the text from the "previous" field into the "current" field, a postback occurs automagically, and the form returns to it's previous state.

Voila!

How useful this really is, I'm not sure. There's plenty of room for improvement. For example, it could be extended to track the viewstate on every postback, allowing you to "go back" and "go forward", swapping the state along the way as appropriate. It could also have a built-in ViewState visualizer, that'd be handy. I haven't tested it in all scenarios... like when ViewState encryption is enabled. It definitely won't work if you limit the size of the ViewState field. Also, since it's using an actual TextBox control that it adds to the forms control collection, it's possible that code elsewhere on your pages could accidentally manipulate or otherwise disable the control.

The simplest way to use it is to make your page inherit from the included VisibleViewStatePage class (instead of just Page).

Download the source (C#) here

Happy coding! :)

A drink from the fire hose

2006-06-20T23:43:00.000-07:00

Just wanted to give thanks to the team behind http://asp.net. A thanks for selecting my Atlas: Smart Auto Completion article as an Article of the Day!

Just to give you a clue of what that was like from this side of the screen...

Guess when it started?

Yes, the asp.net site is a veritable fire hose of traffic, and I got to take a small, brief, drink. Alas, by now my article has fallen off the list of articles of the week. And so this is also a thanks to those of you who may be sticking around (you guys are represented by the blue bars) :) It's all the nice comments I've gotten from readers that keeps me going. So definitely stop by often, because I can guarantee you there is more content to come.

Perhaps plug into my atom feed.

See ya soon!
Dave

Join the Dark Side of Visual Studio

2006-06-13T21:56:00.000-07:00

UPDATE: THIS POST HAS BEEN MOVED TO MY NEW BLOG! Please redirect your bookmarks here:

http://weblogs.asp.net/infinitiesloop/archive/2006/08/06/Join-the-Dark-Side-of-Visual-Studio.aspx

Visual Studio is without a doubt a powerful tool. With every iteration, it continues to improve upon itself. But as you happily hack away at all your applications, you are blistfully unaware of it's evil dark side that has been there since the beginning. It's true.

There are those of us who embrace the dark side. But we are out numbered...

You see, the dark side isn't how it comes by default. No... it comes all happy and bright and cheery by default, and like good little jedi programmers you accept those defaults. But the dark side is there, hidden away deep within the environment settings, reaching out and corrupting those programmers who are corruptible. Why some are corruptible and some are not is a mystery that may never be solved, but each and every programmer must give pause and consider the benefits it provides.

I know what you may be thinking. It's hard to read. Are you so sure about that? Lets compare it with the happy cheery default color scheme:

The key difference of course is the pervasive black background color. This is the environment I and many others work in every day. For me, it started way back when I used a Borland C++ IDE that had preset environment color schemes. One was called Twilight, and it looked similar to this. That color scheme was even my inspiration for this blog template (albeit it is only a variation on a standard blogspot theme, I'm ashamed to say).

Most people who see it for the first time are offended by it... but if you think about it, it really makes sense. It brings balance to the force.

The default scheme sports a bright white background color with dark text over it. But monitors these days are brighter than ever. You're presumably a programmer, so you've no doubt had those late but productive coding nights, nights that are lit by only the glow of your monitor. The glow is bright enough to light up the room and cast shadows. Not unlike... a light bulb.

So there you are, staring straight into a strong light source, looking for the few pixels on it which are not illuminated. Can you read the wattage and manufacturer letters on the head a light bulb while it's turned on? Ahhh... but what if the bulb were black, and only the letters on it were illuminated?

This bulb has no markings, but you'd bet they'd show up nice and bright and easy to read in the right image.

It seems to me the only reason a black-on-white background is so standard is because the GUI was invented to be an analogy to pen and paper. Paper is white. Your screen doesn't have to be.

Want to join the dark side? Click here to download my VS2005 environment settings. Just import them via the Tools->Import and Export Settings menu. Don't worry. If it doesn't suit you, just revert :)

If anyone is interested I can export VS2003 settings as well, but it requires an add-in since VS2003 doesn't have an import/export feature built in.

Happy coding!

UPDATE 06/19/2006

As requested... To enable exporting/importing styles in VS2003 you need an add-in called VSStyler, which you can download here:

VSStyler Add-In for VS2003

Once you have the add-in, download the dark side style export here:

The Dark Side for VS2003

Atlas: Smart Auto Completion

2006-05-25T18:50:00.000-07:00

Auto Completion without a Web Service

To get the latest version that works with Beta 2, please visit my new blog:
http://weblogs.asp.net/infinitiesloop/

If you haven't heard of the Atlas project yet, this article may not be for you. But even then, reading this may give you a clue as to the capabilities of Atlas. To quote the Atlas site,

"Atlas" is a free framework for building a new generation of richer, more interactive, highly personalized standards based Web applications.

One of the innovations Atlas brings to the table is its level of integration with the server side. It is because of this integration that makes it possible for you to take advantage of Atlas' advanced client side features without leaving the comforts of the server side of the world.

But despite this client/server integration, Atlas is still a truly client side framework, one that can be integrated with any server side back end, not just ASP.NET. Its design must take that into consideration, because everything it does must (and should) be a purely client side game. But if you are definitely using Atlas with ASP.NET, it would be nice if you could rely on deeper integration into the rich asp.net server side world. And that is what this article is all about.

Using the Auto Complete Extender

First, lets go over how the built-in stuff works. The built-in Atlas AutoCompleteExtender adds intelligent auto completion behavior to a textbox. Here's how you set one up:

First thing you need is a script manager:

<atlas:ScriptManager ID="ScriptManager1" runat="server" />

And then place a textbox and attach an AutoCompleteExtender to it:

<asp:TextBox id="txt1" runat="server"/>

<atlas:AutoCompleteExtender id="ext1" runat="server">
   <atlas:AutoCompleteExtenderProperties Enabled="true"
      ServicePath="SuggestionService.asmx"
      ServiceMethod="GetSuggestions" TargetControlID="txt1" />
</atlas:AutoCompleteExtender>

The behavior uses the given ServicePath and ServiceMethod properties to call the specified Web Service whenever suggestions are needed. The web service, written by you, can query a database or do whatever it needs to do in order to calculate the suggestions. Here is an example of a web service that provides the necessary method signature:

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class SuggestionService : System.Web.Services.WebService
{
    public SuggestionService()
    {
    }
    [WebMethod]
    public string[] GetSuggestions(string prefixText, int count)
    {
        return new string[] { "abc", "def", "ghi" };
    }
}

The prefixText parameter is the text the user has entered thus far, and the count parameter is the maximum number of suggestions you should return. And just like that, we have auto-completion!

Auto Completion via a Web Service

Going one step further

It's the greatest thing since the variable geometry nacelle. But, there are some limitations to this approach. Because it must call a web service, the logic for determining the suggestions is isolated from the page that contains the textbox. That means you do not have access to any state information that is available on the page. In many cases that may not be an issue. It may even be good design to isolate that logic into a web service. But because you lack that state information, you are forced to configure the web service via global means such as the web.config. For example, a connection string. What if a developer wants auto completion for different database than the one the rest of the application is using? What if the suggestions that you want to show depend on the value of another control on the page, such as a date range that should limit the search results of the query? Or maybe you have a "product category" dropdown and the textbox should only suggest results for products that are in that category? What if you are a control developer (like me) and you want to create a custom textbox control that has auto completion built into it -- how will you effectively package together your custom control and the web service? Why should I have to create a web service to provide auto completion at all?

Why can't I wield the power of auto-completion all within the page itself?

Yes... Let's do that. Presenting the SmartAutoCompleteExtender and the SmartTextBox. In creating these two controls I had a strategy in mind:

Create an Auto Complete extender that uses a CALLBACK rather than a web service. This will allow all the logic to calculate the suggestions to live on the same page.

Support a Web Service too, for flexibility.

Utilize the existing auto complete behavior script, so I don't have to write complex JavaScript.

Raise an Event in the Extender control when suggestions are needed. The event model will allow users of the extender to provide suggestions easily within the page and multiple listeners could potentially work together to create suggestions from different sources.

Create a TextBox with a built-in Auto Complete extender, so users of that control can provide auto completion without even knowing what Atlas is

This being my first custom extender for Atlas, I did run into a few problems. But in less than a day I was able to piece these controls together. If I had to do it again, already having learned all the lessons that I did, I could probably do it on the order of a few hours. This is a testament to the extensibility of Atlas. More on that later.

First, let us look at the SmartAutoCompleteExtender. To use it I must register my custom control assembly and namespace with the obligatory Register directive at the top:

<%@ Register Assembly="Infinity.Web" Namespace="Infinity.Web.UI.WebControls" TagPrefix="i88" %>

i88 is a nice tag prefix I like to use. Now lets replace the built in atlas extender with the smart one:

<i88:SmartAutoCompleteExtender Enabled="true" id="ext1" runat="server">
 <i88:SmartAutoCompleteProperties
            TargetControlID="txt1" />
</i88:SmartAutoCompleteExtender>

Notice there's no ServicePath or ServiceMethod specified. This extender uses an event on the server side instead. But if you wanted to use a web service, it supports that too:

<i88:SmartAutoCompleteExtender Enabled="true" id="ext1" runat="server">
 <i88:SmartAutoCompleteProperties
            TargetControlID="txt1"
            Mode="WebService"
            ServicePath="SuggestionService.asmx"
            ServiceMethod="GetSuggestions" />
</i88:SmartAutoCompleteExtender>

But, we're more interested in the event. Just to keep these code lines shorter (screen real estate is prime on this blog .. I need a better medium!), create a namespace alias in your code behind:

using I88=Infinity.Web.UI.WebControls;

Then you can hook into the event on the extender like so:

protected override void OnInit(EventArgs e)
{
 this.ext1.AutoCompleteCallback += new I88.EventHandler(ext1_AutoCompleteCallback);
 base.OnInit(e);
}

AutoCompleteCallback is the event that fires when the client side needs suggestions. Now for the event handler itself:

void ext1_AutoCompleteCallback(object sender, I88.AutoCompleteEventArgs args)
{
 int count = args.Count;
 string prefix = args.Prefix;

 args.CompletionItems = new string[] { prefix + "A", prefix + "B", prefix + "C" };
}

The event argument passed to the event handler contains three properties:

Count - The maximum number of suggestions that should be returned

Prefix - The characters entered so far into the textbox

CompletionItems - a string array of suggestions to be set by you.

Just for demonstration and to prove it is working, we take the prefix and create three suggestions by adding "A", "B" and "C" to it. Here we go:

Look ma, no web service!

Excellent. The beauty of this is that it really was not very hard to do. I was able to reuse the existing javascript behavior that is defined for the built-in AutoCompleteExtender. The custom behavior javascript simply creates an instance of the built in behavior and lets it do all the dirty work. All that was required is to hook into the timer object it uses by replacing its event handler with my own, and replacing existing methods with your own is easy to do with javascript. To do the actual callback, it uses asp.net's built-in javascript function for that, too: WebForm_DoCallback. By passing it the ID of the extender control, and implementing ICallbackEventHandler in the extender control, its easy to raise the auto complete event.

Going one step further, again

Indeed why stop there... wouldn't it be nice if you didn't even need to create an extender? Why can't auto complete be a built-in feature of the textbox itself? Man you sure are demanding. Fine...

Get rid of the extender declaration. Then replace the TextBox with, well... the i88:SmartTextBox:

<i88:SmartTextBox ID="txt1" runat="server" EnableAutoComplete="true" />

Don't forget the EnableAutoComplete="true" attribute, because by default it is disabled. You might wonder why I didn't call this control "AutoCompleteTextBox" instead. Well because I don't believe in naming controls (or classes) after their features. The SmartTextBox might one day be extended to support many other advanced features, of which Auto Completion would be just one. Just planning ahead a little. "Smart" may not be the best name either, but its the best I could come up with ok? :)

Internally, the SmartTextBox creates a SmartAutoComplete extender for you. It also surfaces a property that allows you to have access to all the same properties the extender does. So once again you can use a web service or a callback, whatever floats your boat:

<i88:SmartTextBox ID="txt1" runat="server" EnableAutoComplete="true"
 AutoComplete-Mode="WebService"
 AutoComplete-ServicePath="SuggestionService.asmx"
 AutoComplete-ServiceMethod="GetSuggestions" />

But as before, we're only interested in the callback mode for this article. The SmartTextBox also surfaces the event itself -- so if all you knew about was the SmartTextBox control, you could quickly and easily add custom auto completion to it, without ever hearing the word "Atlas" muttered. Change the event handler like so:

protected override void OnInit(EventArgs e)
{
 this.txt1.AutoCompleteCallback += new I88.EventHandler(txt1_AutoCompleteCallback);
 base.OnInit(e);
}

void txt1_AutoCompleteCallback(object sender, I88.AutoCompleteEventArgs args)
{
 int count = args.Count;
 string prefix = args.Prefix;

 args.CompletionItems = new string[] { prefix + "A", prefix + "B", prefix + "C" };
}

And put it into action... remember to type at least 3 characters, because the default minimum length is 3. That is a property you can change if you like.

Look ma, no web service AND no Extender!

Yes I cheated -- this screenshot is exactly the same one as before. But that's because it looks exactly the same anyway. Even the 'view source' on the page looks exactly the same. The only difference is the declaration in the form.

Download the source code here!

I should also mention that the project type is the Web Application project option introduced by Microsoft, described in detail and available for download here. If you don't have it already, you should. It will be baked in on the first service pack for VS2005 anyway. If you'd rather not, then you'll have to rebuild the project file, or perhaps you can change the project type guid so it's a class library project instead. Sorry for the confusion.

Use the source however you like... change it, trash it, claim it as your own, I don't mind :) All I ask is you send some friends over to this tiny corner of the internet. I enjoy having readers. :)

Happy coding!

UPDATE 06/08/2006:

Someone pointed out a bug with the project on the asp.net forums. Click here to read the post. I have re-uploaded a new project with the fix.

I also added a new property to the extender: EnableCache (boolean). You see, the built in behavior has a nice little performance feature built into it. Once it requests suggestions for prefix "abc", it remembers them in a cache variable on the client. So if you type in "abcd", wait for the auto complete to occur again, then delete the "d", the behavior is able to recall the suggestions it already calculated without calling the webservice or performing another callback. But this presents a problem in callback mode if you try to use this custom extender in the ways it is advertised, where the suggestions may depend on the state of other controls on the page. The state of those controls may change, and the cache of suggestions will be wrong. And so it was simple to add the EnableCache property. Normally you should leave this option alone. Only disable the cache if you know you might give different suggestions for the same prefix text, because the values are dependant on other controls.

And finally, I have also included a sample web application that uses the SmartTextBox in callback mode. It also contains a RadioButtonList, and the suggestion items vary based on the selected value of the list.

Thanks to ethos42 for the bug report!
Download the Source Code here!

UPDATE 06/10/2006:

Unfortunately for me but fortunate for you guys, jjradke pointed out another bug. The event will fail to fire if you place the textbox within a naming container (for example within a template column of a datagrid, among other things). The bug was due to it using the ClientID instead of the UniqueID... which has been fixed!! If you already downloaded the source you can easily patch your copy by changing this line (approximately line 90 in the SmartAutoCompleteExtender.cs file)

writer.WriteAttributeString("id", this.ClientID);

To this:

writer.WriteAttributeString("id", this.UniqueID);

Thanks for the bug report!

UPDATE: 08/24/2006:

I'm sorry to have put you guys through downloading from FilePlanet. The link eventually broke, but thankfully I've found a more suitable home for the source code. The download links should work once again.

The CodeExpressionBuilder

2006-04-25T17:57:00.000-07:00

UPDATE: THIS POST HAS BEEN MOVED TO MY NEW BLOG! Please redirect your bookmarks here:

http://weblogs.asp.net/infinitiesloop/archive/2006/08/09/The-CodeExpressionBuilder.aspx

A very exciting new feature in ASP.NET 2.0 is Expression Builders. Expression builders allow for some pretty interesting interaction with the ASP.NET compilation model.

For example, new to ASP.NET 2.0 is the ability to reference appSettings declaratively. Lets say you wanted the text of a button to be based on a value in the appSettings section of your web.config. Piece of cake:

<asp:Button id="cmdSubmit" runat="server"
 Text="<%$ appSettings: ButtonText %>" />

This is made possible by the built in AppSettingsExpressionBuilder. Lets say you wanted to display a localizable string, which is stored as a resource. In ASP.NET 1.1 it was sort of a pain. No longer:

<%$ resources: ResourceKey %>
That's the ResourcesExpressionBuilder hard at work. Nice!

There's also a ConnectionStringsExpressionBuilder so you can refer to Connection Strings defined in the new connection strings section in the web.config. That is extremely helpful when working with the new declarative data controls:

<asp:SqlDataSource id="data1" runat="server"
   ConnectionString="<%$ ConnectionStrings: MyConnectionString %>"/>

Wow.

Now lets take it one step further. Have you ever seen this exception?

The dreaded "Server tags cannot contain <% ... %> constructs" exception.

That's because you probably tried to do something like this:

<asp:Label id="lbl1" runat="server" Text=<%= CurrentUserName %> />
Perhaps you tried to fix it by putting it in quotes:
<asp:Label id="lbl1" runat="server" Text="<%= CurrentUserName %>" />
... Only to be thwarted once again, as the literal text, including the <%= %> construct, ended up in the page:

Putting <%= %> in quotes doesn't help much.

If all you want to do is show the result of this code as a string, you could quite simply just get rid of the label:

<%= CurrentUserName %>
That would work. But for purposes of this example, lets assume that doesn't work for you. Perhaps you need the label server control for some other reason, or perhaps you need to set a string property of some other type of server control in this way.

The problem is you have incorrectly, although intuitively, tried to assign the property of a server control using the <%= %> construct. Unfortunately that is simply not supported by ASP.NET, 1.1 nor 2.0. If you ask around about your problem, someone may tell you that you will have to convert to using the <%# %> databinding construct instead. That is advice that I have given myself, I even eluded to it in my previous blog post. That will work. But it requires that you are calling DataBind() on the control, AND, it will cause you to BLOAT VIEWSTATE... and you KNOW how much I hate bloating viewstate!

It seems like it should be a common need... all you want is to assign the default value for a control to something a little dynamic. Something that can't be represented with a literal. Something with some logic behind it. You can just go ahead and assign the value in your code-behind, say.. in the OnInit method.. but that too will bloat viewstate. I'm afraid there's no super simple solution unless you don't mind disabling viewstate on that control. That may work in some scenarios, but sometimes you really need the ViewState enabled! What's a web developer to do?

Here's a better example. You want, for some reason, the text value of a CheckBox to be the current date and time. For whatever reason, you can't disable viewstate on the CheckBox (say, because you need the CheckChanged event, which doesn't work without viewstate). It doesn't matter why exactly. How on Earth are you going to get the current date and time into the Text property on the CheckBox, WITHOUT BLOATING VIEWSTATE? By "Bloating ViewState", I mean causing data to become serialized in the __VIEWSTATE hidden form field when it isn't necessary to begin with. There's no reason to put the current Date and Time into serialized viewstate, is there? It's going to be reassigned on the next request. You'd just be making ASP.NET serialize it, then making the user's browser suck the serialized string down the pipe, then making them push it back down the pipe to the server on a postback, then making ASP.NET deserialize the value -- ONLY FOR IT TO BE REASSIGNED? How rude! How wasteful and inefficient. For a single control its not a big deal, what's a few bytes? But that is not a path you want to start down my friend... with that kind of mantra, your web forms will quickly grow a viewstate tumor the size of a Borg cube! Ideally, you want the functional equivalence of this:

<asp:CheckBox id="chk1" runat="server" Text="<%= DateTime.Now %>"/>
That is ideal, because the ViewState StateBag is not tracking changes when ASP.NET assigns declared attributes, so our beloved ViewState remains optimized. And, we didn't even have to disable ViewState. AND we can do it declaratively! Woohoo! Right. Well, good luck getting that to work. It won't.

The CodeExpressionBuilder comes to the rescue! Another great thing about ExpressionBuilders is that you can create your own. So, I created a CodeExpressionBuilder, one that allows you to use raw code to assign values to control properties. Using the CodeExpressionBuilder you can do this:

<asp:CheckBox id="chk1" runat="server" Text="<%$ Code: DateTime.Now %>"/>

Now that is nice. And to think the darn thing is only a few lines of code. It seems like such a useful thing to have, I don't know why it isn't included as a built in feature.

The trick is to use the CodeDom's CodeSnippetExpression to convert the given string into a CodeExpression. Here's the entire class:

[ExpressionPrefix("Code")]
class CodeExpressionBuilder : ExpressionBuilder
{
 public override object ParseExpression(string expression,
  Type propertyType, ExpressionBuilderContext context)
 {
  return expression;
 }

 public override CodeExpression GetCodeExpression(BoundPropertyEntry entry,
  object parsedData, ExpressionBuilderContext context)
 {
  return new CodeSnippetExpression(parsedData.ToString());
 }
}

To use it, or any custom ExpressionBuilder for that matter, you must register it in the web.config expressionBuilders section. Now... how you do this part sort of depends on how your project is setup. If you have a standard ASP.NET Web Site project, then you will be defining the CodeExpressionBuilder class in the app_code directory, and the "type" will just be "CodeExpressionBuilder". However, if you are creating a Web Application Project (read about it here), then the CodeExpressionBuilder is just another class in your project, with its own namespace. For that you will need to define the whole type string (or, if you define it in a reusable library, you'll need the fully qualified type and assembly name). In my case that is "Infinity.Web.Compilation.CodeExpressionBuilder". Here it is:

<compilation debug="true">
 <expressionBuilders>
  <add expressionPrefix="Code"
  Type="Infinity.Web.Compilation.CodeExpressionBuilder"/>
 </expressionBuilders>
</compilation>

And to see it in action:

<asp:CheckBox id="chk1" runat="server"
 Text="<%$ Code: DateTime.Now %>" />

ExpressionBuilders are truly a thing of beauty! Use any expression you want!

You can use any code expression want:

<%$ Code: DateTime.Now.AddDays(1) %>
<%$ Code: "Hello World, " + CurrentUserName %>
<%$ Code: CurrentUserName.ToUpper() %>
<%$ Code: "Page compiled as: " + this.GetType().AssemblyQualifiedName %>

Just be careful what combination of quotes you use. If you have literal strings in your code expression like in two of the above examples, you will need to use single quotes (') to surround the entire <%$ %> expression if it is within a server control declaration. If you don't you will get the "Server tag is not well formed" error.

In the beginning I said ExpressionBuilders were an interesting way to plug into the ASP.NET compilation model. Well this really illustrates that... put a break point in the expression builder, and debug the page. You will hit the break point once, and only once, even after you refresh the page several times. The Date and Time will continue to update, but the expression builder breakpoint will only activate the first time you hit the page. The reason is because the ExpressionBuilder is used when ASP.NET compiles the page. Once the page is compiled, that's it. That's the reason why ExpressionBuilder returns a CodeExpression, and not an actual object. In essence, the builder tells ASP.NET what code it needs to run to get the value, instead of giving it the actual value. It's the old adage, teach a man to fish, and he eats forever. How geeky is that? Too cool.

PS: The one thing this ExpressionBuilder doesn't do... it won't work in "No-Compile" pages. Seems like a reasonable limitation.

Questions? Comments? I just figured out this thing tonight and I'm all happy about it. I'm curious why this isn't a built in expression builder, its so simple yet so useful. Perhaps there's a good reason I haven't thought of. It would be awesome if an asp.net team member could provide their insight :) One of these days I hope to lure one of them into this site...

HAPPY CODING.

TRULY Understanding Viewstate

2006-03-12T19:11:00.000-08:00

UPDATE: THIS POST HAS BEEN MOVED TO MY NEW BLOG! Please redirect your bookmarks here:

http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx

If you read this blog at all, by now you've got to be sick of me talking about ViewState. I'm sorry, but its becoming increasingly clear to me that ViewState is a very misunderstood animal. I would like to help put an end to the madness by attempting to explain exactly how the ViewState mechanism works, from beginning to end, and from many different use cases, such as declared controls vs. dynamic controls.

There are a lot of great articles out there that try to dispel the myths about ViewState. You might say this is like beating a dead horse (where ViewState is the horse, and the internet is the assailant). But this horse isn't dead, let me tell you. No, he's very much alive and he's stampeding through your living room. We need to beat him down once again. No horses were harmed during the authoring of this article.

It's not that there's no good information out there about ViewState, it's just all of them seem to be lacking something, and that is contributing to the community's overall confusion about ViewState. For example, one of the key features that is important to understand about ViewState is how it tracks dirtiness. Yet, here is a very good, in-depth article on ViewState that doesn't even mention it! Then there's this W3Schools article on ViewState that seems to indicate that posted form values are maintained via ViewState, but that's not true. Don't believe me? Disable ViewState on that textbox in their example and run it again). And it's the #1 Google Search Result for "ASP.NET ViewState". Can you believe that? Ok so these are all third party sites. Microsoft articles wouldn't be wrong, would they? No. But, they aren't extremely in depth either. For example, here is ASP.NET Documentation on MSDN that describes how Controls maintain state across postbacks. The documentation isn't wrong per say, but it makes a statement that isn't entirely correct:

"If a control uses ViewState for property data instead of a private field, that property automatically will be persisted across round trips to the client.

That seems to imply that anything you shove into the ViewState StateBag will be round-tripped in the client's browser. NOT TRUE!

So it's really no wonder there is so much confusion on ViewState. There is no where I've found on the internet that has a 100% complete and accurate explanation of how it works! The best article I have ever found is this one by Scott Mitchell. There's nothing that is wrong or even ambiguous in that article, however, it is incomplete. It does not explain the relationship of controls and their child controls when it comes to initialization and ViewState Tracking, and it is this point alone that causes a bulk of the mishandlings of ViewState, at least in the experiences I've had.

So the point of this article will be to first give a complete understanding of how ViewState basically functions, from beginning to end, hopefully filling in the holes that many other articles have, but without going into a lot of technical detail on things like LosFormatting, for example, because there are plenty of sites out there that do an awesome job of that already. After a complete explanation of the entire ViewState process, I will go into some examples of how developers typically misuse ViewState, usually without even realizing it, and how to fix it.

First let me explain why understanding ViewState to it's core is so important:

MISUNDERSTANDING OF VIEWSTATE WILL LEAD TO...

Leakage of sensitive data
ViewState Attacks - aka the Jedi Mind Trick -- *waves hand* that plasma tv is for sale for $1.00
Poor performance - even to the point of NO PERFORMANCE
Poor scalability - how many users can you handle if each is posting 50k of data every request?
Overall poor design
Headache, nausea, dizziness, and irreversible frilling of the eyebrows.

If you develop an ASP.NET Application and you don't take ViewState seriously, this could happen to you:


The ViewState form field on a prominent asp.net community site.	ViewState will add your web app's distinctiveness to it's own. Performance is futile.

I could go on but that is the gist of it. Now lets move on by starting back from the beginning:

WHAT DOES VIEWSTATE DO?

This is a list of ViewState's main jobs. Each of these jobs serves a very distinct purpose. Next we'll learn exactly how it fulfills those jobs.

Stores values per control by key name, like a hashtable
Tracks changes to a ViewState value's initial state
Serializes and Deserializes saved data into a hidden form field on the client
Automatically restores data on postbacks

Even more important than understanding what it does, is understanding what it does NOT do:

WHAT DOESN'T VIEWSTATE DO?

Automatically retain state of class variables (private, protected, or public)
Remember any state information across page loads (only postbacks) (that is unless you customize how the data is persisted)
Remove the need to repopulate data on every request
ViewState is not responsible for the population of values that are posted such as by TextBox controls (although it does play an important role)
Make you coffee

While ViewState does have one overall purpose in the ASP.NET Framework, it's four main roles in the page lifecycle are quite distinct from each other. Logically, we can separate them and try to understand them individually. It is often the mishmash of information on ViewState that confuses people. Hopefully this breaks it down into more bite size nuggets. Mmmm... ViewState Nuggets.

1. VIEWSTATE STORES VALUES
If you've ever used a hashtable, then you've got it. There's no rocket science here. ViewState has an indexer on it that accepts a string as the key and any object as the value. For example:

ViewState["Key1"] = 123.45M; // store a decimal value
ViewState["Key2"] = "abc"; // store a string
ViewState["Key3"] = DateTime.Now; // store a DateTime

Actually, "ViewState" is just a name. ViewState is a protected property defined on the System.Web.UI.Control class, from which all server controls, user controls, and pages, derive from. The type of the property is System.Web.UI.StateBag. Strictly speaking, the StateBag class has nothing to do with ASP.NET. It happens to be defined in the System.Web assembly, but other than it's dependency on the LosFormatter, also defined in System.Web.UI, there's no reason why the StateBag class couldn't live along side ArrayList in the System.Collections namespace. In fact, I've often wondered why Microsoft did not do just that since the StateBag has many useful features that the other collections are lacking.

In practice, Server Controls utilize ViewState as the backing store for most, if not all their properties. This is true of almost all Microsoft's built in controls (ie, label, textbox, button). This is important! You must understand this about controls you are using. Read that sentance again. I mean it... here it is a 3rd time: SERVER CONTROLS UTILIZE VIEWSTATE AS THE BACKING STORE FOR MOST, IF NOT ALL THEIR PROPERTIES. Depending on your background, when you think of a traditional property, you might imagine something like this:

public string Text
{
  get { return _text; }
  set { _text = value; }
}

What is important to know here is that this is NOT what most properties on ASP.NET controls look like. Instead, they use the ViewState StateBag, not a private instance variable, as their backing store:

public string Text
{
  get { return (string) ViewState["Text"]; }
  set { ViewState["Text"] = value; }
}

And I can't stress it enough -- this is true of almost ALL PROPERTIES, even STYLES (actually, Styles do it by implementing IStateManager, but essentially they do it the same way). When writing your own controls it would usually be a good idea to follow this pattern, but thought should first be put into what should and shouldn't be allowed to be dynamically changed on postbacks. But I digress -- that's a different subject.

It is also important to understand how DEFAULT VALUES are implemented using this technique. When you think of a property that has a default value, in the traditional sense, you might imagine something like the following:

public class MyClass
{
  private string _text = "Default Value!";

  public string Text
  {
    get { return _text; }
    set { _text = value; }
  }
}

The default value is the default because it is what is returned by the property if no one ever sets it. How can we accomplish this when ViewState is being used as the private backing? Like this:

public string Text
{
  get
  {
    return ViewState["Text"] == null ?
         "Default Value!" :
          (string) ViewState["Text"];
  }
  set { ViewState["Text"] = value; }
}

Like a hashtable, the StateBag will return null as the value behind a key if it simply doesn't contain an entry with that key. So if the value is null, it has not been set, so return the default value, otherwise return whatever the value is. For you die-hards out there -- you may have detected a difference in these two implementations. In the case of ViewState backing, setting the property to NULL will result in resetting the property back to it's default value. With a "regular" property, setting it to null means it will simply be null. Well, that is just one reason why ASP.NET always tends to use String.Empty ("") instead of null. It's also not very important to the built in controls because basically all of their properties that can be null already are null by default. All I can say is keep this in mind if you write your own controls.

And finally, as a footnote really, while this property-backing usage of the ViewState StateBag is how the StateBag is typically used, it isn't limited to just that. As a control or page, you can access you're own ViewState StateBag at any time for any reason, not just in a property. It is sometimes useful to do so in order to remember certain pieces of data across postbacks, but that too is another subject.

2. VIEWSTATE TRACKS CHANGES
Have you ever set a property on a control and then somehow felt... dirty? I sure have. In fact, after a twelve-hour day of setting properties in the office, I become so filthy my wife refuses to kiss me unless I'm holding flowers to mask the stench. I swear!

Ok so setting properties doesn't really make you dirty. But it does make the entry in the StateBag dirty! The StateBag isn't just a dumb collection of keys and values like a Hashtable (please don't tell Hashtable I said that, he's scarey). In addition to storing values by key name, the StateBag has a TRACKING ability. Tracking is either on, or off. Tracking can be turned on by calling TrackViewState(), but once on, it cannot be turned off. When tracking is ON, and ONLY when tracking is ON, any changes to any of the StateBag's values will cause that item to be marked as "Dirty". StateBag even has a method you can use to detect if an item is dirty, aptly named IsItemDirty(string key). You can also manually cause an item to be considered dirty by calling SetItemDirty(string key). To illustrate, lets assume we have a StateBag that is not currently tracking:

stateBag.IsItemDirty("key"); // returns false
stateBag["key"] = "abc";
stateBag.IsItemDirty("key"); // still returns false

stateBag["key"] = "def";
stateBag.IsItemDirty("key"); // STILL returns false

stateBag.TrackViewState();
stateBag.IsItemDirty("key"); // yup still returns false

stateBag["key"] = "ghi";
stateBag.IsItemDirty("key"); // TRUE!

stateBag.SetItemDirty("key", false);
stateBag.IsItemDirty("key"); // FALSE!

Basically, tracking allows the StateBag to keep track of which of it's values have been changed since TrackViewState() has been called. Values that are assigned before tracking is enabled are not tracked (StateBag turns a blind eye). It is important to know that any assignment will mark the item as dirty -- even if the value given matches the value it already has!

stateBag["key"] = "abc";
stateBag.IsItemDirty("key"); // returns false
stateBag.TrackViewState();
stateBag["key"] = "abc";
stateBag.IsItemDirty("key"); // returns true

ViewState could have been written to compare the new and old values before deciding if the item should be dirty. But recall that ViewState allows any object to be the value, so you aren't talking about a simple string comparison, and the object doesn't have to implement IComparable so you're not talking about a simple CompareTo either. Alas, because serialization and deserialization will be occuring, an instance you put into ViewState won't be the same instance any longer after a postback. Microsoft decided rightfully so that this kind of comparison is not important for ViewState to do it's job.

So that's tracking in a nutshell. But you might wonder why StateBag would need this ability in the first place. Why on earth would anyone need to know only changes since TrackViewState() is called? Why wouldn't they just utilize the entire collection of items?

This one point seems to be at the core of all the confusion on ViewState. I have interviewed countless professionals, sometimes with years and years of ASP.NET experience logged in their resumes, who have failed miserably to prove to me that they understand this point. Actually, I have yet to interview a single candidate who has. And let me just say, if I interviewed you and you did get it right, and it was entirely up to me, your odds of being hired would go through the roof.

First, to truly understand why Tracking is needed, you will need to understand a little bit about how ASP.NET sets up declarative controls. Declarative controls are controls that are defined in your ASPX or ASCX form. Here:

<asp:Label id="lbl1" runat="server" Text="Hello World" />

I do declare that this label is declared on your form. The next thing we need to make sure you understand is ASP.NET's ability to wire up declared attributes to control properties. When ASP.NET parses the form, and finds a tag with runat=server, it creates an instance of the specified control. The variable name it assigns the instance to is based on the ID you assigned it (by the way, many don't realize that you don't have to give a control an ID at all, ASP.NET will use an automatically generated ID. Not specifying an ID has advantages, but that is a different subject). But that's not all it does. The control's tag may contain a bunch of attributes on it. In our label example up above, we have a "Text" attribute, and it's value is "Hello World". Using reflection, ASP.NET is able to detect whether the control has property by that name, and if so, sets its value to the declared value. Obviously the attribute is declared as a string (hey, its stored in a text file after all), so if the property it maps to isn't of type string, it must figure out how to convert the given string into the correct type, before calling the property setter. How it does that my friend is also an entirely different topic (it involves TypeConverters and static Parse methods). Suffice it to say it figures it out, and calls the property setter with the converted value.

Recall that all-important statement from the first role of the StateBag. Here it is again: Server Controls utilize ViewState as the backing store for most, if not all their properties. That means when you declare an attribute on a server control, that value is usually ultimately stored as an entry in that control's ViewState StateBag. Now recall how tracking works. Remember that if the StateBag is "tracking", then setting a value to it will mark that item as dirty. If it isn't tracking, it won't be marked dirty. So the question is -- when ASP.NET calls the SET on the PROPERTY that corresponds to the ATTRIBUTE that is DECLARED on the control, is the StateBag TRACKING or isn't it? The answer is no it is not tracking, because tracking doesn't begin until someone calls TrackViewState() on the StateBag, and ASP.NET does that during the OnInit phase of the page/control lifecycle.

This little trick ASP.NET uses to populate properties allows it to easily detect the difference between a declaratively set value and dynamically set value. If you don't yet realize why that is important, please keep reading.

3. SERIALIZATION AND DESERIALIZATION

Aside from how ASP.NET creates declarative controls, the first two capabilities of ViewState we've discussed so far have been strictly related to the StateBag class (how it's similar to a hashtable, and how it tracks dirty values). Here is where things get bigger. Now we will have to start talking about how ASP.NET uses the ViewState StateBag's features to make the (black) magic of ViewState happen.

If you've ever done a "View Source" on an ASP.NET page, you've no doubt encountered the serialization of ViewState. You probably already knew that ViewState is stored in a hidden form field aptly named _VIEWSTATE as a base64 encoded string, because when anyone explains how ViewState works, that's usually the first thing they mention.

A brief aside -- before we understand how ASP.NET comes up with this single encoded string, we must understand the hierarchy of controls on the page. Many developers with years of experience still don't realize that a page consists of a tree of controls, because all they work on are ASPX pages, and all they need to worry about are controls that are directly declared on those pages... but controls can contain child controls, which can contain their own child controls, etc. This forms a tree of controls, where the ASPX page itself is the root of that tree. The 2nd level is all the controls declared at the top level in the ASPX page (usually that consists of just 3 controls -- a literal control to represent the content before the form tag, a HtmlForm control to represent the form and all its child controls, and another literal control to represent all the content after the close form tag). On the 3rd level are all the controls contained within those controls (ie, controls that are declared within the form tag), and so on and so forth.

Each one of the controls in the tree has it's very own ViewState -- it's very own instance of a StateBag. There's a protected method defined on the System.Web.UI.Control class called SaveViewState. It returns type 'object'. The implementation for Control.SaveViewState is to simply pass the call along to the Control's StateBag (it too has a SaveViewState() method). By calling this method recursively on every control in the control tree, ASP.NET is able to build another tree that is structured not unlike the control tree itself, except instead of a tree of controls, it is a tree of data. The data at this point is not yet converted into the string you see in the hidden form field, it's just an object tree of the data to be saved.

Here is where it finally comes together... are you ready?

When the StateBag is asked to save and return it's state (StateBag.SaveViewState()), it only does so for the items contained within it that are marked as Dirty. That is why StateBag has the tracking feature. That is the only reason why it has it. And oh what a good reason it is -- StateBag could just process every single item stored within it, but why should data that has not been changed from it's natural, declarative state be persisted? There's no reason for it to be -- it will be restored on the next request when ASP.NET reparses the page anyway (actually it only parses it once, building a compiled class that does the work from then on).

Despite this smart optimization employed by ASP.NET, unnecessary data is still persisted into ViewState all the time due to misuse. I will get into examples that demonstrate these types of mistakes later on.

POP QUIZ

If you've read this far, congratulations, I am rewarding you with a pop quiz. Aren't I nice? Here it is:

Let's say you have two nearly identical ASPX forms: Page1.aspx and Page2.aspx. Contained within each page is just a form tag and a label, like so:

<form id="form1" runat="server">
<asp:Label id="label1" runat="server" Text="" />
</form>

They are identical except for one minor difference. In Page1.aspx, we shall declare the label's text to be "abc":

<asp:Label id="label1" runat="server" Text="abc" />

...And on Page2.aspx, we shall declare the label's text to be something much longer (the preamble to the Constitution of the United States of America):

<asp:Label id="label1" runat="server" Text="We the people of the
United States, in order to form a more perfect union,
establish justice, insure domestic tranquility, provide
for the common defense, promote the general welfare,
and secure the blessings of liberty to ourselves and
our posterity, do ordain and establish this Constitution
for the United States of America." />

Imagine you browse to Page1.aspx, you will see "abc" and nothing more. Then you use your browser to view the HTML source of the page. You will see the infamous hidden _VIEWSTATE hidden field with encoded data in it. Note the size of that string. Now you browse to Page2.aspx, and you see the preamble. You use your browser to view the HTML source once again, and you note the size of the encoded _VIEWSTATE field.

The question is: Are the two sizes you noted the same, or are they different?

Before we get to the answer, lets make it a little bit more involved. Lets say you also put a button next to the label (on each page):

<asp:Button id="button1" runat="server" Text="Postback" />

There is no code in the click event handler for this button, so clicking on it doesn't do anything except make the page flicker. With this new button in place, you repeat the experiment, except this time when browsing to each page, you click the Postback button before looking at the HTML source. So the question is once again...

Are the encoded ViewState values the same, or different?

The correct answer to the first part the question is THEY ARE THE SAME! They are the same because in neither of the two viewstate strings are any data related to the label at all. If you understand ViewState, this is obvious. The Text property of the label is set to the declared value before it's ViewState is being tracked. That means if you were to check the dirty flag of the Text item in the StateBag, it would not be marked dirty. StateBag ignores items that aren't dirty when SaveViewState() is called, and it is the object it returns that is serialized into the hidden _VIEWSTATE field. Therefore, the text property is not serialized. Since the Text is not serialized in either case, and the forms are identical in every other way, the sizes of the encoded viewstates on each page must be the same. In fact, no matter how large or small of a string you stuff into that text attribute, the size will remain the same.

The correct answer to the second part is again, THEY ARE THE SAME! In order for data to be serialized, it must be marked as dirty. In order to be marked as dirty, it's value must be set after TrackViewState() is called. But even when we perform a postback, ASP.NET recreates and populates the server controls in the same way. The Text property is still set to it's declared value just like it was in the first request. No other code is setting the text property, so there's no way the StateBag item could become dirty, even on a postback. Therefore, the sizes of the encoded viewstates on each page after a postback must be the same.

So now we understand how ASP.NET determines what data needs to be serialized. But we don't know how it is serialized. That topic is outside the scope of this article (are you missing an assembly reference?), so if you're really interested in how it works, read up on the LosFormatter.

Finally on this topic is DESERIALIZATION. Obviously all this fancy dirty tracking and serialization wouldn't do any good if we couldn't get the data back again. That too is outside the scope of this article, but suffice it to say the process is just the reverse. ASP.NET rebuilds the object tree it serialized by reading the posted _VIEWSTATE form value and deserializing it with the LosFormatter.

4. AUTOMATICALLY RESTORES DATA

This is last on our list of ViewState features. It is tempting to tie this feature in with Deserialization above, but it is not really part of that process. ASP.NET deserializes the ViewState data, and THEN it repopulates the controls with that data. Many articles out there confuse these two processes. Defined on System.Web.UI.Control (again, the class that every control, user control, and page derive from) is a LoadViewState() method which accepts an object as parameter. This is the opposite of the SaveViewState() method we already discussed, which returns an object. Like SaveViewState(), LoadViewState() simple forwards the call on to it's StateBag object, calling LoadViewState on it. The StateBag then simply repopulates it's key/object collection with the data in the object. In case you are wondering, the object it is given is a System.Web.UI.Pair class, which is just a simple type with a First and Second field on it. The "First" field is an ArrayList of key names, and the "Second" field is an ArrayList of values. So StateBag just iterates over the lists, calling this.Add(key, value) for each item. The important thing to realize here is that the data it was given via LoadViewState() are only items that where marked dirty on the previous request. Prior to loading the ViewState items, the StateBag may already have values in it. Those values may be from declarative properties like we discussed, but they may also be values that were explicitly set by the developer prior to the LoadViewState call. If one of the items passed into LoadViewState already exists in the StateBag for some reason, it will be overwritten. That right there is the magic of automatic state management. When the page first begins to load during a postback (even prior to initialization), all the properties are set to their declared natural defaults. Then OnInit occurs. During the OnInit phase, ASP.NET calls TrackViewState() on all the StateBags. Then LoadViewState() is called with the deserialized data that was dirty from the previous request. The StateBag calls Add(key, value) for each of those items. Since the StateBag is tracking at this point, the value is marked dirty, so that it may be persisted once again for the next postback. Brilliant!

Whew. Now you are an expert on ViewState management.

IMPROPER USE OF VIEWSTATE

Now that we know exactly how ViewState works, we can finally begin to understand the problems that arise when it is used improperly. In this section I will describe cases that illustrate how a lot of ASP.NET developers misuse ViewState. But these aren't just obvious mistakes. Some of these will illustrate nuances about ViewState that will give you an even deeper understanding of how it all fits together.

CASES OF MISUSE

Forcing a Default
Persisting static data
Persisting cheap data
Initializing child controls programmatically
Initializing dynamically created controls programmatically

1. Forcing a Default

This is one of the most common misuses, and it is also the easiest to fix. The fixed code is also usually more compact than the wrong code. Yes, doing things the right way can lead to less code. Imagine that.

This usually occurs when a control developer wants a particular property to have a particular default value, and does not understand the dirty tracking mechanism, or doesn't care. For example, lets say the Text property a control is supposed to be some value that comes from a Session variable. Developer Joe writes the following code:

public class JoesControl : WebControl
{
  public string Text
  {
    get { return this.ViewState["Text"] as string; }
    set { this.ViewState["Text"] = value; }
  }

  protected override void OnLoad(EventArgs args)
  {
     if(!this.IsPostback)
     {
        this.Text = Session["SomeSessionKey"] as string;
     }

     base.OnLoad(e);
  }

}

This developer has committed a ViewState crime, call the ViewState police! There's two big problems with this approach. First of all, since Joe is developing a control, and he has taken the time to create a public Text property, it stands to reason that Joe may want developers that use his control to be able to set the Text property to something else. Jane is a page developer that is attempting to do just that, like so:

<abc:JoesControl id="joe1" runat="server" Text="ViewState rocks!"/>

Jane is going to have a bad day. No matter what Jane puts into that Text attribute, Joe's control will refuse to listen to her. Poor Jane. She's using this control just like you use every other ASP.NET control, but this one works differently. Joe's control is overwriting Jane's Text value! Worse than that, since Joe sets it during the OnLoad phase, it is marked dirty in ViewState. So to add insult to injury, Jane is now incurring an increase in her page's serialized ViewState size for doing nothing more than putting Joe's Control on her page. I guess Joe doesn't like Jane very much. Maybe Joe's just trying to get back at Jane for something.

Well, since we all know which sex rules this world, we can assume Jane ends up getting Joe to fix his control. Much to Jane's delight, this is what Joe comes up with:

public class JoesControl : WebControl
{
  public string Text
  {
    get
    {
      return this.ViewState["Text"] == null ?
         Session["SomeSessionKey"] :
         this.ViewState["Text"] as string;
    }
    set { this.ViewState["Text"] = value; }
  }
}

Look at how much less code we have here. Joe doesn't even have to override OnLoad. Because the StateBag returns null if the given key does not exist, Joe can detect whether his Text property has been set already by checking for null. If it is, he can safely return his would-be default value. If it's not null, he happily returns whatever value it is. Simple as can be. Now when Jane uses Joe's control, not only is her Text attribute honored, she no longer incurs a hit on her ViewState size, either. Better behavior. Better performance. Less code. Everyone wins!

2. Persisting static data

By Static, I mean data that never changes or is not expected to change during the lifetime of a page, or even during the users session. Lets say Joe, our would-be shoddy asp.net developer, has been tasked with adding the current user's name to the top of a page in the company's eCommerce application. It's a nice way of telling the user, "hey, we know who you are!" It makes them feel special and that the site is working. Positive feedback. Lets say this eCommerce application has a business layer API that allows Joe to easily get the name of the currently authenticated user: CurrentUser.Name. Joe completes his task:


(ShoppingCart.aspx)
<asp:Label id="lblUserName" runat="server"/>

(ShoppingCart.aspx.cs)
protected override void OnLoad(EventArgs args)
{
   this.lblUserName.Text = CurrentUser.Name;
   base.OnLoad(e);
}

Sure enough, the current user's name will show up. Piece of cake, Joe thinks. Of course we know Joe has committed another sin. The label control he is using is tracking it's viewstate when it is assigned the current user's name. That means not only will the Label render the user name, but that user name will be encoded into the viewstate hidden form field. Why make ASP.NET go through all the work of serializing and deserializing the user name, when you are just going to reassign it after all? That's just rude! Even when confronted, Joe shrugs at the problem. It's only a few bytes! But it's a few bytes you can save so easily. There are two solutions to this problem. First... you could just disable viewstate on the label.

<asp:Label id="lblUserName" runat="server"
EnableViewState="false"/>

Problem solved. But there's an even better solution. Label has to be one of the most overused controls there are, bested only by the Panel control. It comes from the mindset of Visual Basic Programmers. To show text on a VB Form you needed a label. Labels are supposed to be the ASP.NET WebForm counterpart, so it's only nature to think you need a label to display a text value that isn't hardcoded in the webform. Fair enough, but that's not true. Label's render a <span> tag around their text content. You must ask yourself whether your really need this span tag at all. Unless you are applying a STYLE to this label, the answer is NO. This would suffice just fine:

<%= CurrentUser.Name %>

Not only do you get to avoid having to declare a label on the form (which means less code, albeit designer-generated code), but you've followed the spirit of the code-behind model: separation of code from design! In fact, if Joe's company had a dedicated designer responsible for the look and feel of the eCommerce site, Joe could have simply passed on the task. "That's the designers job", he could have balked, and rightfully so. There is another reason why you might THINK you need a Label, and that is when something in the code behind may need to programmatically access or manipulate that label. Ok, fair enough. But you must still ask yourself whether you really need a SPAN tag surrounding the text. Introducing the most underused controls in ASP.NET: The LITERAL!

<asp:Literal id="litUserName" runat="server"
EnableViewState="false"/>

No span tag here.

3. Persisting cheap data

This one is a superset of #2. Static data is definitely cheap to get. But not all cheap data is static. Sometimes we have data that may change during the lifetime of an application, possibly from moment to moment, but that data is virtually free to retrieve. By free, I mean the performance cost of looking it up is insignificant.

A common instance of this mistake is when populating a dropdown list of U.S. States. Unless you are writing a web application that you plan on warping back in time to December 7, 1787 (here), the list of US States is not going to change any time soon. However, as a programmer that hates to type, you certainly wouldn't want to have to type these states by hand into your web form. And in the event a state does rebel (we can only dream... you know who you are), you wouldn't want to have to perform a code change to strike it from the list.

Our proverbial programmer Joe decides he will populate his dropdown list from a USSTATES table in a database. The eCommerce site is already using a database, so its trivial for him to add the table and query it.

<asp:DropdownList id="lstStates" runat="server"
DataTextField="StateName" DataValueField="StateCode"/>

protected override void OnLoad(EventArgs args)
{
   if(!this.IsPostback)
   {
      this.lstStates.DataSource = QueryDatabase();
      this.lstStates.DataBind();
   }
   base.OnLoad(e);
}

As is the nature of databound controls in ASP.NET, the state dropdown will be using ViewState to remember it's databound list of list items. At the time of this ranting, there are a total of 50 US States. Not only does the dropdown list contain a ListItem for each and every state, but each and every one of those states and their state codes are being serialized into the encoded viewstate. That's a lot of data to be stuffing down the pipe every time the page loads, especially over a dialup connection. I often wonder what it would be like if I explained to my grandmother the reason why her internet is so slow is because her computer is telling the server what all the US States are. I don't think she'd understand. She'd probably just start explaining how when she was young, there were only 46 states. Too bad... those extra 4 states are really wearing down your bandwidth. Damn you late comers! You know who you are!

Like the problem with static data, the general solution to this problem is to just disable viewstate on the control. Unfortunately, that is not always going to work. Whether it does depends on the nature of the control you are binding, and what features of it you are dependant on. In this example, if Joe simply added EnableViewState="false" to the dropdown, and removed the if(!this.IsPostback) condition, he would successfully remove the state data from viewstate, but he would immediately run into a troubling problem. The dropdown will no longer restore it's selected item on postbacks. WAIT!!! This is another source of confusion with ViewState. The reason the dropdown fails to remember it's selected item on postbacks is NOT because you have disabled viewstate on it. Postback controls such as dropdownlist and textbox restore their posted state (the selected item of a dropdown ist 'posted') even when viewstate is disabled, because even with viewstate disabled the control is still able to post its value. It forgets it's selected value because you are rebinding it in OnLoad, which is after the dropdown has already loaded it's posted value. When you databind it again, the first thing it does is throw that into the bit bucket (you know, digital trash). That means if a user selects California from the list, then click on a submit button, the dropdown will stubbornly return the default item (the first item if you don't specify it otherwise). Thankfully, there is an easy solution: Move the DataBind into OnInit:

<asp:DropdownList id="lstStates" runat="server"
DataTextField="StateName" DataValueField="StateCode" EnableViewState="false"/>

protected override void OnInit(EventArgs args)
{
   this.lstStates.DataSource = QueryDatabase();
   this.lstStates.DataBind();
   base.OnInit(e);
}

The short explanation for why this works: You are populating the dropdown list with items before it attempts to load it's posted value. Now the dropdown will behave just like it did when Joe first designed it, only the rather large list of states will NOT be persisted into the viewstate hidden field! Brilliant!

More importantly, this rule applies to any data that is cheap and easy to get to. You might argue that making a database query on every request is MORE costly than persisting the data through viewstate. In this case I believe you'd be wrong. Modern database systems (say, SQL Server) have sophisticated caching mechanism and are extremely efficient if configured correctly. The state list needs to be repopulated on every request no matter what you're doing. All you've done is change it from being pushed and pulled down a slow, unreliable 56kbps internet connection that may have to travel for thousands of miles, to being pulled over at worse a 10 megabit LAN connection a couple hundred feet between your internet server and database server. AND if you really wanted to improve things, you could cache the results of the database query in the application. You do the math!

4. Initializing child controls programmatically

Let's face it. You can't do everything declaratively. Sometimes you have to get logic involved. That's why we all have jobs, right? The trouble is ASP.NET does not provide an easy way to programmatically initialize properties of child controls correctly. You can override OnLoad and do it there -- but then you're persisting data that probably doesn't need to be persisted into viewstate. You can override OnInit and do it there instead, but that suffers from the same problem. Remember when we learned how ASP.NET calls TrackViewState() during the OnInit phase? It does this recursively on the entire control tree, but it does it from the BOTTOM of the tree UP! In other words, as a control or webform, the OnInit phase of your child controls occurs BEFORE your own. A control will begin tracking viewstate changes in this phase, which means by the time your own OnInit phase begins, your child controls viewstate are all already tracking!

Lets say Joe would like to display the current date and time in a label declared on the form.

<asp:Label id="lblDate" runat="server" />

protected override void OnInit(EventArgs args)
{
   this.lblDate.Text = DateTime.Now.ToString("MM/dd/yyyy HH:mm:ss");
   base.OnInit(e);
}

Even though Joe is setting the label text in the earliest event possible on his webform, it's already too late. The label is tracking viewstate changes, and the current date and time will inevitably be persisted into viewstate. This particular example could fall under the cheap data issue above. Joe could simply disable viewstate on the label to solve this problem. But here we are going to solve it a different way in order to illustrate an important concept. What would be nice is if Joe could declaratively set the label text to what he wants, something like:

<asp:Label id="lblDate" runat="server" Text="<%= DateTime.Now.ToString() %>" />

You may have intuitively attempted this before. But ASP.NET will slap you in the face for it. The "<%= %>" syntax can not be used to assign values to properties of server-side controls. Joe could use the "<%# %>" syntax instead, but that isn't very different than the databinding method we've already covered (disabling viewstate and databinding it every request).

The problem is we would like to be able to assign a value through code, but allow the control to continue to work in exactly the way it normally would. Perhaps some code is going to be manipulating this label, and we want any changes made to it to be persisted through ViewState like they normally would be. For example, maybe Joe wants to give the users a way to remove the date display from the form, replacing it with a blank date instead:


private void cmdRemoveDate_Click(object sender, EventArgs args)
{
   this.lblDate.Text = "--/--/---- --:--:--";
}

If the user clicks this button, the current date and time will vanish. But if we solved our original viewstate problem by disabling viewstate on the label, the date and time will magically reappear again on the next postback that occurs, because the label's viewstate being disabled means it will not automatically be restored. That's not good. What on Earth is Joe supposed to do now?

What we really want is to declaratively set a value that is based on logic, not static. If it were declared the label could continue to work like it normally does -- the initial state wouldn't be persisted since it is set before viewstate is tracking, and changes do it would be persisted in viewstate. Like I said... ASP.NET does not provide an easy way to accomplish this task.

For you ASP.NET 2.0 developers out there, you do have the $ sign syntax, which allows you to use expression builders to declare values that actually come from a dynamic source (ie, resources, declared connection strings). But as far as I know, there's no expression builder for "just run this code" so I don't think that helps you either.

Also for ASP.NET 2.0 developers, there's OnPreInit. That is actually a great place to initialize child control properties programmatically because it occurs before the child control's OnInit (and therefore before it is tracking viewstate) and after the controls are created. However, OnPreInit is not recursive like the other control phase methods are. That means it is only accessible on the PAGE itself. That doesn't help you what-so-ever if you are developing a CONTROL. It's too bad OnPreInit isn't recursive just like OnInit, OnLoad, and OnPreRender are, I don't see a reason for the inconsistency.

The root of the problem is simply that we need to be able to assign the Text property of the label BEFORE it beings tracking its viewstate. We already know the page's OnInit event (the first event that occurs in the page) is already too late for that. So what if we could somehow hook into the Init event of the label? You can't add an event handler in code for that, because the soonest you can do it is in your OnInit which is after the source event has already occurred. And you can't do it in the constructor for the page, because declared controls are not yet created at that point. There are two possibilities:

1. Declaratively hook into the Init event:

<asp:Label id="lblDate" runat="server" OnInit="lblDate_Init" />

This works because the OnInit attribute is processed before the label's own OnInit event occurs, giving us an opportunity to manipulate it before it beings tracking viewstate changes. Our event handler would set its text.

2. Create a custom control:


public class DateTimeLabel : Label
{
  public DateTimeLabel()
  {
    this.Text = DateTime.Now.ToString("MM/dd/yyyy HH:mm:ss");
  }
}

Then instead of a regular label on the form, a DateTimeLabel is used. Since the control is initializing it's own state, it can do so before tracking begins. It does it during the constructor if possible, so that a declared value will be honored.

5. Initializing dynamically created controls programmatically

This is the same problem as before, but since you are in more control of the situation, it is much easier to solve. Lets say Joe has written a custom control that at some point is dynamically creating a Label.


public class JoesCustomControl : Control
{
  protected override void CreateChildControls()
  {
    Label l = new Label();

    this.Controls.Add(l);
    l.Text = "Joe's label!";
  }
}

Hmmm. When do dynamically created controls begin tracking viewstate? You can create and add dynamically created controls to your controls collection at almost any time during the page lifecycle, but ASP.NET uses the OnInit phase to start viewstate tracking. Won't our dynamic label miss out on that event?

No. The trick is, Controls.Add() isn't just a simple collection add request. It does much more. As soon as a dynamic control is added to the control collection of a control that is rooted in the page (if you follow its parent controls eventually you get to the page), ASP.NET plays "catch up" with the event sequence in that control and any controls it contains. So let's say you add a control dynamically in the OnPreRender event (although there plenty of reasons why you would not want to do that). At that point, your OnInit, LoadViewState, LoadPostBackData, and OnLoad events have transpired. The second the control enters your control collection, all of these events happen within the control.

That means my friend the dynamic control is tracking viewstate immediately after you add it. Besides your constructor, the earliest you can add dynamic controls is in OnInit, where child controls are already tracking viewstate. In Joe's control, he's adding them in the CreateChildControls() method, which ASP.NET calls whenever it needs to make sure child controls exist (when it is called can vary based on whether you are an INamingContainer, whether it is a postback, and whether anything else calls EnsureChildControl()). The latest this can happen is OnPreRender, but if it happens any time after or during OnInit, you will be dirtying viewstate again, Joe. The solution is simple but easy to miss:


public class JoesCustomControl : Control
{
  protected override void CreateChildControls()
  {
    Label l = new Label();
    l.Text = "Joe's label!";

    this.Controls.Add(l);
  }
}

Subtle. Instead of initializing the label's text after adding it to the control collection, Joe initializes it before it is added. This ensures without a doubt that the Label is not tracking viewstate when it is initialized.

Actually you can use this trick to do more than just initialize simple properties. You can databind controls even before they are part of the control tree. Remember our US State dropdown list example? If we can create that dropdown list dynamically, we can solve that problem without even disabling its viewstate:


public class JoesCustomControl : Control
{
  protected override void OnInit(EventArgs args)
  {
     DropDownList states = new DropDownList();
     states.DataSource = this.GetUSStatesFromDatabase();
     states.DataBind();
     
     this.Controls.Add(states);
  }
}

It works amazingly well. The dropdown list will behave as if the states are simply built-in list items. They are not persisted in ViewState, yet ViewState is still enabled on the control, meaning you can still take advantage of its ViewState dependant features like the OnSelectedIndexChanged event. You can even do this with DataGrids, although that depends on how you are using it (you will run into problems if you are using sorting, paging, or using the SelectedIndex feature).

BE VIEWSTATE FRIENDLY

Now that you have a complete understanding of how viewstate does it's magic, and how it interacts with the page lifecycle in asp.net, it should be easy to be ViewState Friendly! That is the key really... ViewState optimization is easy as pie when you understand what is going on, often times resulting in even less code than the non-friendly code.

Have any suggestions, comments, error reports? Please leave a comment or send me an email!

Composite Controls made easy

2006-02-14T18:26:00.000-08:00

Scott Gu has an interesting article in his blog, pointing to another article in MSDN, about creating Composite Controls.

Its a great read, a must read, even.

I just have one problem with it. Near the beginning of the article there is some sample code as follows:

public class LabelTextBox : WebControl, INamingContainer
{
   public string Text {
      get {
         object o = ViewState["Text"];
         if (o == null)
              return String.Empty;
         return (string) o;
      }
      set { ViewState["Text"] = value; }
   }
   public string Title {
      get {
         object o = ViewState["Title"];
         if (o == null)
              return String.Empty;
         return (string) o;
      }
      set { ViewState["Title"] = value; }
   }
   protected override void CreateChildControls()
   {
      Controls.Clear();
      CreateControlHierarchy();
      ClearChildViewState();
   }
   protected virtual void CreateControlHierarchy()
   {
       TextBox t = new TextBox();
       Label l = new Label();
       t.Text = Text;
       l.Text = Title;
       Controls.Add(l);
       Controls.Add(t);
   }
}

This is supposed to be an example of how you can use composite controls to make your life easier. This one allows you to set a label to a textbox, which redners before the textbox. Great use of compositing.

Except for one little detail...

Before I explain the problem let me just say... details like this are really frustrating. ASP.NET is very powerful, but with that power comes some responsibility. It is very easy to do things the "wrong" way. It's also very, very easy to do things the right way, but you have to know the difference. And knowing the difference means having a fairly deep understanding of how the framework, well, works. This and my previous post on ViewState are just two examples of these mundane yet crucial details.

And now on to the juicy stuff...

My problem with the example code is really a state management thing. When it creates the textbox and label, it "copies" the Title and Text properties, which are ViewState-based properties of the composite control, into them. That raises some red flags to me, because as soon as you are finished copying the values into the child controls, your public properties are now completely disconnected from them. If someone, somewhere, for some reason, changes your Title or Text property value after this code occurs, it's too late. They will be dumb-founded as to why your control refuses to listen to their instructions (it will still render to 'old' value).

THE SOLUTION

The solution is so elegant in my opinion, I'm not sure why this isn't official recommended practice for compositing. I call it "delegating the properties". It means, don't store the state yourself, use the child control itself to store the state. The real problem was we had the value of our properties stored in two locations -- our ViewState, and our child controls' ViewState. Using the child control itself to store the state means it will always be in just one place, a place where we the parent and the child control can agree on. Here's how:

private TextBox txtFoo;
public MyControl()
{
  this.EnsureChildControls();
}
public string Text
{
  get { return this.txtFoo.Text; }
  set { this.txtFoo.Text = value; }
}
protected override CreateChildControls()
{
  this.txtFoo = new TextBox()
  this.Controls.Add(txtFoo);
}

The Text property does nothing more than access the textbox's Text property. No longer do we need to 'copy' the value into the textbox -- its already there!

The important thing about this trick is to simply call EnsureChildControls() in your constructor. That's so the textbox will exist should someone try to set the Text property (which is very early on if they set it declaratively). Alternatively, you could call EnsureChildControls() within the get and set like so:

public string Text
{
  get
  {
   this.EnsureChildControls();
   return this.txtFoo.Text;
  }
  set
  {
   this.EnsureChildControls();
   this.txtFoo.Text = value;
  }
}

However, if you have several properties that do this, its much easier to just do it in the constructor. Less lines of code result.

Happy control building!!!

ViewState: Misunderstood monster or fluffy sleeping kitten?

2006-02-09T00:01:00.000-08:00

The former!

Let me explain something to guys. ViewState is more complicated than you think it is. That's why you all abuse it so much :) Let me demonstrate:

public class MyControl : Control
{
  public string Text
  {
    get { return (string) this.ViewState["Text"]; }
    set { this.ViewState["Text"] = value; }
  }

  protected override void OnLoad(object sender, EventArgs args)
  {
     if(!Page.IsPostBack)
     {
        this.Text = "Hello World!";
     }
  }

  public override void Render(HtmlTextWriter writer)
  {
    writer.WriteLine(this.Text);
  }
}

What is WRONG with this picture?

Hmmmmmmm???

No.. that's not it.

You don't know?

I told you that's not it.

Give up?

That's what I thought. Sorry for my rudeness but it seems like no one on the planet knows why this is wrong. I have to deal with it every day as a lead programmer. But hey, I don't blame you. I've done this sort of thing myself. It looks perfectly harmless. You want the default value of "Text" to be "Hello World!". And why wouldn't you anyway, "Hello World!" has been serving us programmers since 1812. What better way to honor its 194th birthday than to make it the default value on your Text property?

No problem. Let it shine I say! But that's not what is wrong.

What's wrong is HOW you make it the default value. You know that HTTP is a connectionless protocol right? Well yeah, that's why Session state and ViewState were invented. To help you maintain data across those stateless requests. Brilliant, it really is! "Hello World" has never been so happy.

So let me ask you... What is this line of code for?

if(!Page.IsPostBack)

I know. It's so you don't do unnecessary work, right?

ViewState will be so kind as to save the value for you. Therefore, you'd be wasting CPU cycles if you had to set it on every request, right? Sure. What's that you say? Oh... You're also worried about overwriting the value in case someone has changed it? I see. Well that's pretty smart... I mean, afterall, ViewState is loaded before OnLoad. We wouldn't want to overwrite any precious changes to that value. Very good! Now wait just a second here...

You were on the right track, but you failed to understand the REAL problem here. The problem isn't that you would be wasting CPU cycles if you reassigned the value on every request...

Oh no. The problem is much greater than that.

The problem is that you are completely unaware of the purpose of ViewState. Did I say that already? Sorry, really I am...

Here... There's no better way than to show you.

public class MyControl : Control
{
  public string Text
  {
    get { return this.ViewState["Text"] == null ?
            "Hello World" :
            (string) this.ViewState["Text"]; }
    set { this.ViewState["Text"] = value; }
  }

  public override void Render(HtmlTextWriter writer)
  {
    writer.WriteLine(this.Text);
  }
}

What have we got here. Hmm... No OnLoad anymore.
"Hello World" has moved up into the property. If the value in ViewState is NULL we return it. That means, dun dun dun! We have a default value! And we didn't have to set it, its just THERE.

Ok... so big deal. Who cares?

I'll tell you who cares... and its not a fluffy sleeping kitten.

In the 2nd control, the value "Hello World!" is not persisted into the hidden form field "_VIEWSTATE". In the first control, it is.

Its a very... subtle... difference. But its VERY IMPORTANT!!!

I have seen controls written the "bad" way that contained dozens of properties. The result is, when someone puts this nasty control on a page, even BEFORE THE FIRST POSTBACK, their viewstate is HUGELY BLOATED with crap. If you do it the 2nd way, its just as big as if you had ZERO properties. If some unlucky Joe Programmer uses your control within a DataGrid or repeater, they'll be taking a hit once for every data item they bind.

VIEWSTATE IS NOT TO BE TAKEN LIGHTLY :)

Here's the rule of thumb that you must live and die by: VIEWSTATE IS FOR TRACKING CHANGES TO THE FORM'S STATE. Thats CHANGES. It is NOT meant to store the default values of your properties. Why on earth should it store default values? THEY'RE DEFAULT VALUES for crying out loud. Don't do it! :)

I feel much better now. Thank you! :)

Blog, how I miss thee

2005-08-10T21:38:00.000-07:00

I haven't forgotten about you. I've just been busy, that's all. I promise I'll never leave you my dear blog. I have a picture of us that time we went to Vegas on my desk at work. Those were such good times, weren't they? It constantly reminds me of you. You are so reliable... whatever happens I know that you will be there for me, just waiting to hear of my daily struggles. And I know that whatever I tell you will be kept between you and me... for no one in cyberspace knows you exist! Oh blog, what would I do without you? This I do not know.

Understanding Infinity

2004-07-12T17:42:00.000-07:00

The vastness of the universe is certainly well beyond human comprehension. Just the size of the city you live in is already stretching the limits of your imagination. Truly, even with a birds eye view, you cannot grasp the scale of distance you see before you. Our minds were only intended to process the immediate surroundings, anything beyond a certain distance and size is simply unimportant. But we do have the desire to understand... and an inkling of an imagination to start with.

For me, it is this concept alone that drives my artistic side. I'm not talking about arts and crafts, I'm talking about abstract thinking. I love to probe the limits of my imagination in as many different ways as I can. That is really what drives me to create poetry, when I'm motivated anyway... I want to throw together a combination of words that inspire thought. I want to pry open the ceiling of our imagination, into possibilities unknown. It's a difficult task, maybe impossible. Even if I create a work of prose that I can be proud of, that I think just might be good enough to spark a sense of curiosity in someone else's mind, I cannot know whether it is simply my desire to succeed which is fooling me into believing that I have. I am locked within the confines of my mind, utterly incapable of observing it from a suitably subjective distance.

Writing is indeed one of my main outlets of artistic energy, but that same set of neurons that gives me that outlet is probing for another way out... I've tried creating electronic music. I feel as if I have the capability of creating something worth listening to, something that could vex your mind as much if not more than my words could (however much that is). But my ability to throw together notes has proven to be... uninspiring.

When I was a pre-teen I spent many summer months probing my more traditional artistic abilities with pencil and paper, even with photography. Tracing was fun, but simply for the fleeting moments in which I could fool myself into believing I had created an original piece of art. I was helpless to create anything but straight-edged perspective drawings. They were easy because you could get away with using only a ruler as a guide -- even a toddler could draw a straight line. I merely had to decide where the lines would go. Its those pesky curves and the shading that are beyond my analytical mind, which is constantly wondering what precise angle and thickness to execute.

But with computers, you can accomplish more with less skill. Now a toddler can not only draw a straight line, she can draw a perfectly straight line. She can choose from all possible visible colors. She can add shading, gradients, even add perspective. Surely with these powerful tools at hand, I can produce something worth thinking about? Unfortunately, no. Computers provide an infinitely broad set of tools, but it still takes a human mind to create depth with them. Why? Because it is the human mind which will be consuming the artwork, no other reason. And so probing the depths of your mind is a prerequisite to producing art worth thinking about. But probing the depths of your mind isn't enough, either. I can sit here in silence and feel the deepest of emotions about the universe around me, but unless I can harness that energy and push it out through my extremities onto some kind of physical medium, you might just think I'm a really quiet person.

And it is that ability, that harnessing that I seem to be lacking completely. Because no matter what prose I create, music I compose, pictures I take, or what images I produce, they seem woefully inadequate, and they are. Not that I'm not semi-talented in at least one of these trades -- the point is I don't feel that I've conveyed the emotion at the scale I intended to. No where near it.

Anyway... recently I've felt creative again. And although you might look at this image and be impressed, you should know in advance that creating it only required a few clicks here and there. Yes, I did apply subjective randomness to it... I did try to influence its message. But it's still cookie cutter. It's my result of following a starfield photoshop tutorial, courtesy of Greg Martin, a very skilled artist.

This is my attempt to convey the infinite depth I feel inside my mind to you... this is my attempt to try and understand that depth myself. But it doesn't even get close.

My Mind's Home

(view it full screen to avoid blurriness)

Binding a DataGrid to an arraylist of strings

2004-05-25T16:03:00.000-07:00

...or any simple value type for that matter.

A friend of mine asked me this question and of course it sounds simple. All he wanted to do was:

<asp:Datagrid id="grid" runat="server">
 <Columns>
  <asp:BoundColumn DataField="..."/>
 </Columns>
</asp:Datagrid>

The question was what to put as the DataField, since he's binding an arraylist of strings, as in:


ArrayList list = new ArrayList();
list.Add("1");
list.Add("2");
list.Add("3");
grid.DataSource = list;
grid.DataBind();

What indeed? There's no property on the string data type that returns the string. Doing a little google searching didn't turn up anything satisfactory. One idea was to wrap up the array list into a hashtable (where you can use Key/Value), or to make a custom class and bind that. Yuck, thats a hack! It isn't reusable at all -- and most importantly, it might be a designer messing with the aspx (or ascx) page, and they can't and shouldn't have to write code to accomplish the task. Here's what I would consider the "right" way, which requires zero code changes:


<asp:Datagrid id="grid" runat="server">
 <Columns>
  <asp:TemplateColumn>
   <ItemTemplate>
    <%# Container.DataItem %>
   </ItemTemplate>
  <asp:TemplateColumn>
 </Columns>
</asp:Datagrid>

Power-napping

2004-05-22T20:37:00.000-07:00

That mid-day dip in alertness really grabs hold of me sometimes. Sure, staying up researching longhorn until 1:30 the night before doesn't help. Neither does getting up before the sun rises (an evilness in today's world). But that mid-day dip still seems unnaturally strong. The interesting thing is it's always around 2pm at its worst... if I manage to fight through it, by 3pm I'm back up to normal, and as chip as ever. I know what you're thinking -- its the lunch! Yah I've heard that before but I don't believe it. It doesn't matter when or what I have to eat. Even if I eat nothing.

What's the deal??? Is there something in the air conditioning ducts? It's as if the human body was meant to take a nice little siesta in the middle of the day.

As far as I can tell via google that's a generally accepted idea, and many studies have shown that a 15-20 minute "powernap" once or twice a day can increase overall alertness. Say what?? Where was this study when some genious invented the 8 hour work day? <yawn>... good night.

Hello World

2004-05-22T14:42:00.000-07:00

This will be a place for my thoughts. Thoughts about the world, the universe, philosophy, yadda yadda yadda. They'll be wierd, sometimes they won't make any sense, sometimes they will be completely wrong. That's cool though... at least I've got a place to put them. Maybe someone out there will stumble upon my little island of thoughts here, probably through some completely unrelated google search, like "popcorn and fish" or "what is iodized salt", or what-have-you.

If you do happen upon this blog, be sure to drop me a comment or two... I promise I won't delete it.