Tomorrow night I have a presentation to make for the local C# group. So today, I was touching up the slide deck for it.

And without thinking, I noticed a few extra files cluttering my desktop.

Not being the kind of person that keeps a cluttered desktop, I quickly selected the extra items and deleted. And since I find it so annoying to have to go clear my Recycle Bin all the time, I used "shift-delete" to really nuke em good.

Then it dawned on me.

One of those files was my powerpoint deck for tomorrow. And no, no backup of it anywheres.

Luckily, I found a free delete recovery tool on the internet. Unluckily, the simple act of downloading said tool to my hard disk actually overwrote a few of the sectors where my deleted file once resided. I was able to recover it - but powerpoint could not read it since it was mangled with bits of my IE cache.

After trying everything I could think of (even commercial recovery tools), I eventually was able to get powerpoint to open it up so that I could at least read about 75% of the text. Formatting, images, and anything else was lost to the ether, and there were about 200 extra slides of gibberish... but I could at least see what I had typed previously (or most of it).

So, 4 hours of transcribing later, I have a presentation on my hands again. What sucks though is that its now 2am and I have to be up in like 4 hours to make it to work on time...

There goes daylight savings time screwin up my RSS reader with double posts on nearly every feed!

Then go vote on this bug report. Right now, in Visual Studio 2005, you can easily create a chain of hierarchical masters (child->master->master). This works great, however you cannot edit the child page in the designer in this situation. You can only edit the child page if there is only one level of master above it.

It should be obvious that anything beyond the simplest of website applications will need more than one level of master page linking. But as it stands now, we won't be able to edit the pages in the WYSIWYG editor... all html will have to be edited by hand.

Michael proposes that they not even try to show the master/master/etc content around the child container (like they do in the simple scenario that works). He is simply asking that they allow us to edit the child page in the designer - even if the inherited masterpage content is not visible.

So go vote on that bug!

I have used CSS for years now, but I never knew about this. Sure, it's sort of implied by the documentation, but I have never seen anyone come out and say "hey, this is how you organize it". So here is what I learned this weekend.

1. You can define specific hierarchies of nested tags to apply a style to. For example "DIV.outerdiv DIV.innerdiv {color:red;}" will set the font color of a div with a class attribute of "innerdiv" to red, but only if it is contained within another div with a class of "outerdiv". Thats super handy for complex layouts.

2. You can define a style more than once. The styles are then merged at runtime in the order which they are encountered (last writer of a style property wins). This means that you can seperate layout CSS from colors CSS and from text, or whatever. You can have a "colors.css" file that only contains color definitions, making it MUCH easier to update later. Super SUPER handy!

3. You can assign styles based on element IDs, not just Classes. Everyone using CSS knows you can use a style selector of ".somestyle" to apply a style to all elements with a class= "somestyle"... but most don't know that you can use a selector of "#element_id" to apply the style only to the element with id= "element_id". This is SUPERB for layout style properties. Generally, the colors/text/etc styles are used on many elements in a page, which is easily done using class="somestyle". But id values are supposed to be unique in a page, and they are all at different positions, with different layout rules (even though they share the same color/font/etc). Assigning layout style properties based on element id and other properties based on class allows you to have your cake and eat it too!

These are very simple concepts to pick up, but they have done wonders for my web design/layout abilities.

And I guess I should also give the disclaimer that I didn't know these things until I customized my dasBlog theme, and saw how it's CSS was designed. Very impressive work there.

Michael Earls is the man.

This afternoon I asked him a simple question: How do I get Master Pages type functionality without upgrading to Fx2.0 beta?

I am building a small administration application for a client, and I am tired of using "copy & paste templates" or "UserControl chunks" to build a reusable/consistent site design. I know he has done this type of thing a few times in the past, which is why I asked him.

He gave me some very concise and (most importantly) correct insights into the ASP.NET rendering engine, and where to place hooks to do what I wanted. He gave me just enough information to get it working, without giving me too much. The essentials: override the AddParsedSubobjects() method in a server control to re-parent the child page's contents to a placeholder.

While there are a few tricks and snags to overcome, that is essentially exactly what I had to do. I created a new server control, changed it to inherit from Web.UI.Page, instantiated LiteralControls for my static content, as well as a number of server controls that I needed in my base class (for example, the Coalesys PanelBar for navigation) in the new class's constructor. I did some footwork in the AddParsedSubobjects() method to relocate the child page's Form contents into a new HtmlForm that I maintain within my new class. I also had to copy the properties of the child form (enctype, name, method, etc)... so that should the child page developer decide to change any of it, their changes would carry over.

I did do a few things my own way. One of the ideas Michael gave me was to use regular expressions to construct the master page's LiteralControls (he used string constants for each Literal, which I am sure was probably a bit tedious when a change needed to be made). So instead of that approach, I added some well-known comment tags to my master page's source to demarcate the literal sections. I then used my NVEdit tool to store the entire master page as a single template resource. A simple regular expression was used to extract out all the literal sections (this was not hard at all since I used well-known comments to mark the sections). As a result, I can modify the master page layout without too much trouble (yes, it still requires a recompile). Perhaps a future exercise could be to make it fully dynamic, with the ability to use multiple master layouts on the fly. Hmm.

Anyways, the other features I added was a simple way to link external CSS (a new AddStylesheetReference(string url) method), as well as the obligatory Title property that alters the header tag appropriately. A side bonus is that the AddParsedSubobjects code is smart enough to read in existing Title and linked stylesheets from the child pages, and automatically set them with no developer code required. I will likely also extend this mechanism to support themes via CSS at a later time too. That would work nicely along with dynamic master page sourcing...

So I am now very happy. I effectively have master pages development in VS 2003. I don't have the ability to see the master while editing a child page in the designer, but I don't really care about that little bit. I can still link my child page to the site's CSS and get the right "look and feel". This is great.

Thanks again Michael!

As much as I like to gripe about AS/400's and mainframes, I gotta hand it to them. There are just some business-level tasks that a dumbed-down interface such as a 3270 or 5250 terminal provides.

It's really a grounding lesson in worker efficiency to watch a factory line worker scanning barcodes into a terminal every couple seconds, or punching the keys to enter an order - faster than you can even read the screen contents. I have never seen a web application capable of approaching that kind of worker efficiency.

Maybe this whole "rich design" craze will fade away... much like the idea of always-connected "client/server" database systems. Sometimes while I am busy building a "swiss army knife" website (is there *any* other kind that management ever asks for?), I just sit back and wonder what people will think of us in 20 years.

Will they think "man, those web applications are super-efficient"?

Or will they think "what a hunk of manure"?

My money is on the latter. There is a lot to be said for thinking through your actual processes and requirements before sitting down and banging out code. People need to start thinking about what they really need and why before jumping into development.

And choosing "web" applications over other forms as a default is crazy. The design should start simple (dumb terminal level), and then graduate to complex (windows forms), and finally to distributed (web). These are all increasing flexibility/coolness, but also greatly increasing development effort. Interestingly, they are all decreasingly efficient in terms of worker productivity when applied to real-world business processes.

Web apps belong on 1) the internet, and 2) intranet collaboration. 99% of the time they have no place in back-end businesses. It boggles me as to why people keep trying to fit this square peg in a hole it was not intended to fill.