21
Aug
2006
Seeing Jaxon's post about fixing the search on his blog prompted me to do a search on my own blog and see what happened. I was happy to discover that it works, but the EntryDate control that I had put together was not producing any dates. This confused me.
The search results page for your blog is generated by Skin-IndividualSearchContainer.ascx. This page contains an instance of the <Blog:EntryList> control. This is where my confusion arose from, as I was certain that I had covered the EntryList case, as that is what the front page of my blog uses (verily, the front page of the site still displays dates correctly, as expected).
After rooting around a bit, I discovered the problem. The EntryList control, at its heart, relies on a Repeater to display its content. When the EntryList occurs inside of EntryListContainer, it is populated with instances of WeblogPost. However, when it occurs in IndividualSearchContainer, it is populated with instances of IndexPost. Both of these contain the post date, but I was only checking for the presence of the former. By adding support for the latter, everything is once again sunshine and rainbows.
An updated version of the assembly can be found here, complete with source code.
17
Aug
2006
Last night I decided to see if I couldn't integrate my source code formatting into Windows Live Writer using their SDK (which is really nothing more than a help file). It turns out that it is ridiculously easy to create simple plugins for this thing, and was able to create a functioning plugin in about an hour.
Since I've had a couple of people ask how I format source code for my blog, I'm going to go ahead and make it available for download. It's built for Framework 2.0, so you'll need to have that installed ahead of time. A CSS stylesheet containing the styles that I use is also included. Thanks to manoli.net for the actual source formatting code.
To use, just copy the assembly into Live Writer's plugins folder and start up the application. The new option will appear under the "Insert" menu. You will get the following dialog:
Paste/type in your code, select a language, choose line numbers and/or alternating line styles, and click OK. The resulting HTML will be dropped into your post. Just don't forget to splice the CSS into your blog's stylesheets, as the formatter does not embed the styles into the HTML tags.
Consider this unsupported. I cannot guarantee that it will not detonate your computer. Then again, I'm pretty sure it won't.
19
Jun
2006
At my office, we have that one guy who is really into the more esoteric, rarely-used parts of a development framework, yet rarely gets the opportunity to use them. A couple of weeks back, he sent me a link to an article on
Code Project regarding
custom build providers. A custom build provider allows you to extend ASP.NET 2.0's build process to add support for your own file types. Compilation of these files happens automatically when the source code changes in the App_Code directory. The compiler output is included with the output for the rest of the web application.
My conversations with this guy usually end with him bemoaning the fact that he will never have a real-world use for whatever technology he is bringing to my attention at the time. However, on this occasion, the example code provided was rather inspiring. I was able to give him an example of where we
could make use of a build provider and immediately set out to implement one. Hey, I love learning new stuff just as much as the next guy, and this was completely new to me.
The solution that I implemented was to generate a series of state objects to represent all of the services offered by our company. Each service is represented by its own table in the database and, of course, these tables are entirely heterogeneous (else they would all be one table, I assume; I didn't design the database). The operation of this code is similar to the example code in the Code Project article above, which generates a rudimentary data access layer for a given set of tables. The total time to get the code functioning was about six hours, and the end result was that I did not have to code four hundred state objects by hand.
To be honest, I didn't find the build provider itself to be terribly interesting. It is fantastically useful (if you can find a use for it) and extremely easy to implement. There really is nothing to it. There were two things that I did find interesting, however. First, I was very impressed with the speed of the thing. I thought it would take much longer to scrape four hundred tables for their schemas, generate code, and compile it. Second was the
CodeDOM which, like build providers, was entirely new to me.
CodeDOM is a namespace in the .NET Framework for generating code. Using CodeDOM seems to be somewhat similar to using System.Xml to generate an XML document. There are object representations of most code structures. Making use of these structures is a bit odd at first, but it really is to your benefit to learn how they work. This is because the CodeDOM structures will, on their own, generate language-independent code. That means that the same CodeDOM procedures can be used to generate C# and VB.NET (and J#? I think only C# and VB are supported at this time). The alternative is to use CodeDOM's
snippet support, which allows you to inline C#/VB source directly as strings. However, you do this at the expense of language portability and compile-time error checking.
I think this kind of stuff is cool as hell. I may look into throwing up some sort of tutorial, but it would likely focus more on CodeDOM, as there was significantly more work on that side than on the build provider itself.