Building Custom SubText Controls

In my response to Jeff Atwood, I mentioned the Technorati widget control that he is now using in lieu of Trackbacks. The Technorati widget is fairly simple to implement, but you have to be able to feed it the permalink for your post for it to be able to work. Since I already had a go at creating custom controls for use in SubText, I decided that now was a good time to see if I couldn't come up with a way to create one that has access to blog entry attributes like the permalink. For your edification, here's what I found.

First Things First

Before we walk this primrose path, lets make sure that we aren't setting ourselves up for hard times later. Create a custom Skin by copying the files from your favorite built-in Skin into a new folder in the Skins directory.

Once you do this, you'll need to let SubText know about your new skin. This is done in the Admin directory by creating a "Skins.User.config" file. The easiest way to do that is to copy the existing Skins.config file and rename your copy to "Skins.User.config". They have the same structure, but having the extra config for user skins allows the SubText team to maintain the built-in skins without messing up any customizations you might be using. Make sure that you delete all the entries for skins (except the one you copied from above). Then you can tweak the template Name and and TemplateFolder attributes (highlighted below).

Once this is done and uploaded to your SubText site, you'll see your skin listed at the bottom of the skin selection drop-down in the Admin pages (that dropdown is not sorted, so the user skins will be at the bottom). Now you can modify to your heart's content and not worry about a future upgrade nailing your customization. Also, if you really mess things up, just hit Admin and set your skin back to your old starting point.

Where Things Are

The controls you'll use to customize SubText are all in the Controls folder in your custom Skin directory.

The most daunting thing about creating custom controls is figuring out how SubText handles things. You can skip the rest of this section if you don't really care and just want to get on with creating your control.

There are a couple of quirks of SubText that can help you isolate any problems that you might encounter.

  1. SubText transfers some of the controls programmatically by grabbing subcontrols of one object and copying them to the controls collection of the parent object. This is most notable for the subcontrol brought in by the PageTemplate for the "contentregion". If you pick apart your PageTemplate.ascx, you'll see a control with an ID of "MPMain". That's where this happens. The reason for this is that SubText replaces MPMain with a different control depending on what kind of page it is trying to display. Which leads to the following problem.
  2. It isn't immediately clear which control is being pulled in by MPMain for different sections of your blog. The main page (default.aspx), for example, pulls the HomePage.ascx control. It took me a while to figure this out, but now that I have, I found that the control that functions as "MPMain" is determined by a group of <HttpHandler> elements in the web.config file (technically, MPMain can be replaced with multiple controls as you can see if you actually dig out your web.config). The HttpHandler elements in web.config describe a RegEx "pattern" attribute to apply to incoming URL requests and then a "controls" attribute that describes the control(s) used. I could have saved a lot of time if I had known this up front (say by asking members of the dev team who are actually quite helpful and would probably have responded pretty quickly, really)
  3. The classes that implement many of these controls use the specific ID of some controls to populate certain attributes--mostly Text. For example, Day.ascx can have a Literal control with an ID of "PostDesc" that is populated with the descriptive elements of a post at run time (e.g. when it was posted, if there are comments, that kind of thing). Some of these are checked for existence (like "PostDesc"), but some aren't (like "PostText"). Which are checked and which aren't makes pretty good sense, though, so I don't see that as a problem. I mean, I want to see an error if my blog is unable to display the PostText of a post.

Creating a New Control

The key feature that you need in order to leverage SubText entry information is a control class defined in SubText called CurrentEntryControl. This nifty little guy has no implementation in any of the default skins, so he's easy to overlook. The key feature he possesses is that if referenced from a control that has a blog entry associated to it, it'll let you use databinding syntax within that control to access the properties of an entry. I'm not going to say how long it took me to figure this out. Let's just be happy that I have...

The Technorati embed needs your fully qualified URL (i.e. the full-on web address to reach your post--the one you'd paste into a browser's address bar to reach just that post), so the best databind expression that I found for my purposes is:

<%# UrlEncode (Entry.FullyQualifiedUrl) %>

Believe it or not, this actually works. UrlEncode is defined in the CurrentEntryControl object along with the Entry property. Again, don't ask how long it took me to figure all this out. Just for kicks, here's the Entry class properties:

Since I'm going to want the Technorati embed to function in a couple of different page contexts, I think the easiest way to implement it is to put the script in its own control. This will be pretty simple for just the Technorati embed script:

<%@ Control Language="c#" Inherits="Subtext.Web.UI.Controls.CurrentEntryControl" %>
<script src="" type="text/javascript"></script>
<a class="tr-linkcount" href="<%# UrlEncode (Entry.FullyQualifiedUrl) %>">View blog reactions</a>

That should be generic enough to function in any blog. I've put it together for you to download here if you want to save yourself some copy and pasting.

Placing The New Control

Now that we have the control we're going to use for Technorati's embed, you have to decide where you're going to use it. For me, I decided to use it both for posts on the blog's home page and for the individual posts themselves. After digging around, I decided that the best candidates for the new control were Day.ascx and ViewPost.ascx. Day is eventually referenced from the home page and ViewPost is referenced when displaying a post from archive (i.e. permalinked pages).

For the control to work, you'll need two things: a Register tag and the control tag. The Register tag lets the parent control know where to find your custom control. The control tag lets it know where to display it. My new ViewPost.ascx looks like this (my changes are highlighted):

Save those changes, upload to your server, and you're done. Just because I can, I included both of the modified controls in the download I referenced above. Pop all three into the Controls folder of your custom Skin and you should be good to go. Note that I pulled both of those controls out of the "Piyo" built-in skin, so it's very possible that they may differ from the controls in other skins.

22. December 2006 05:30 by Jacob | Comments (2) | Permalink

Trackbacks Are Dead


Jeff Atwood has a recent post on why he finally gave up and disabled Trackbacks on his blog. My blog is the tiniest fraction of his and I had to disable trackbacks just for sheer spam volume back in October (inspiring an anti-spam rant of my own).

Jeff lays the blame for Trackbacks' demise on Six Apart--the outfit that created the standard in 2002. Ah, those heady glory days when you still had to explain to people what a blog was. Trackbacks were a great idea. They still are a great idea. But Jeff is right, the simplicity of the standard has left it wide open to abuse and that abuse has killed them dead.

So my question is (to Jeff or anyone else), how would you alter the design to make the standard more robust?

My initial take on it was to alter the standard to incorporate a public key exchange and a signature. But then I realized that, hey, spammers can create asymmetric keys as well as anyone else can. In other words, the problem isn't being able to authenticate the link--it's being able to evaluate the linked post.

Jeff's current stop-gap of finding links to his posts through Technorati seems like a reasonable short-term solution. Introducing a third party is problematic, though, because it leads to inevitable issues in finding a trustworthy third party that will carry the authentication burden for you (as well as traffic and processing costs as people ping them for link verification). Indeed, Akismet (a popular stab at trackback filtering) has those same third-party screening issues and isn't substantively different from Jeff's use of Technorati.

I suspect that the problem might not even be in bad design by Six Apart, however. The thing that makes Trackbacks so popular and led them to be so widely adopted is that it allows the creation of inter-post linkages from unaffiliated sources with very little effort. I'm afraid that any solution to the trackback problem is going to necessarily involve increasing the effort of unaffiliated linking to a point where it becomes much less attractive.

A Stab in the Dark

That said, here's two thoughts about potentially rewarding avenues for solving the problem picked up from spam solutions in other realms.

First from email spam, and recognizing that I'm pretty thoroughly ignorant of the underlying mechanisms involved in Bayesian content analysis, I wonder if there might be some useful application for content analysis here. Spammers are increasingly sophisticated in overcoming content analysis, though. Trackbacks may be easier to analyze, though, because they have an easily available comparison text (the originating post). It may be easier to compare your post with that of the linker and come up with a tougher analysis than you can in, say, a lone email. I don't know about that.

Second, the key to the success of spamming is that they have such a very low cost per "signal" (email, comment, trackback, what have you). Their only incremental cost is bandwidth to find blog posts and to send trackback signals. Raising those costs can have a significant effect on spam. This is essentially the key to Captcha's success in curbing comment spam. If a trackback request prompted a user-interactive Captcha-like query, that alone may well be enough to stem the vast majority of trackback spam. Perhaps a design amendment that included a short interaction on a trackback ping would be successful in cutting spam back to manageable levels.

In looking at those two ideas, it occurs to me that the main problem with a Bayesian solution is that it places the burden (both in implementing the Bayesian algorithms and in processing the incoming links) squarely on the target of the spam. This can lead to an unwanted side-effect by leaving your blog much more open to another Internet dirty trick--denial of service attacks. Frankly, you don't even have to deny service to affect a lot of private bloggers--attacks that increase their bandwidth usage would be as unwelcome to many as a full-on denial might be. After all, it doesn't cost you extra hosting fees when your blog goes down.

So maybe that means I only really have one thought/solution/suggestion. Bayesian analysis would be cool for the AI geeks, but not terribly practical in the constrained environment confronting most bloggers. I wonder what it'd take to create a Captcha mechanism in trackback notification?

21. December 2006 11:59 by Jacob | Comments (2) | Permalink

Hacking SubText

Okay, I've had SubText up and running for a week and some now, so naturally it is time to tinker. In poking around, I'm not as happy with SubText's integration model as I was with DasBlog's. DasBlog exposed a number of "macros" that you could use to insert certain internal values into your own stuff. I kind of liked their model because once you registered your own code, you could reference your macros from DasBlog stuff as well (bear in mind that I didn't actually implement DasBlog, so my impression could be off).

That said, as long as you don't need to access things like entry links or other internal blog workings, it's pretty easy to modify a "Skin" in SubText to add new stuff. SubText reads a main ASP.Net Web User Control called PageTemplate.ascx that holds essentially the format for the other Web User Controls that a SubText site uses. Which subcontrols are used are pretty much determined by this PageTemplate control and the controls it references. This structure made it pretty easy for me to add a new embed control I wanted to play with.

The Technorati Embed

There are a number of sites that offer badges, embeds, and other tools intended for their users to simultaneously spruce-up their own sites and provide free advertising for the service involved. The Technorati search feature on the right is an example and was my first foray into modifying my blog template. With Technorati, the tag I need to use to expose a Technorati search link is this:
<script src="" type="text/javascript"></script>

To pop it on there, I just added that code right in the PageTemplate.ascx file where I thought it'd do some good (using a text editor). Straightforward, but inelegant.

The Great Games Experiment Embed

 For my next trick, I wanted to see how SubText would handle it if I mimicked their own structure to create a new control. To do this, I created a couple of things that are way more complicated than they needed to be. I mean, technically, all I needed to do to pop the user embed onto my site is copy the badge tag from their site in the same place I put the Technorati stuff. The tag isn't all that complicated:
<iframe src="" height="140" width="204" scrolling="no" frameBorder="0" />

Doing so would produce this handy "badge":

But I'm a geek and I wanted to test some stuff out, so instead of simply pasting a bunch of html, I created a .Net project and two custom web user controls. One of the controls creates a user badge. The other control creates a game badge. The result of this project is that you can drag one of these controls onto an ASP.Net page and set the "UserName" property (or "Game" property for a game badge) and it'll take care of the rest. The active html would look like this:
<cc1:GreatGamesUserEmbed ID="GreatGamesUserEmbed1" runat="server" UserName="Jacob" />

Somehow, I managed to get that to work. As long as you've registered my assembly for the right tag prefix, you're golden.

But that wasn't quite enough for me, oh, no. Simply adding that control to PageTemplate would be kind of hokey and out of place, so I went one further. Following the pattern of the other controls, I created a GreatGames.ascx file under the Controls directory and referenced that instead. It's a simple file, but then, most of those Control files are. It creates a section that fits in much better on the right side bar and groups the Great Games badges together more naturally.

And wonder of wonders, it worked first time. Love when that happens.


SubText doesn't have any documentation that I could find detailing these steps, so making these modifications required mucking about in the code to follow their flow during page delivery. If I get the gumption later, I'll re-write this as a more generic how-to in creating very basic SubText add-ins because the community needs something like this. Also, I saw a couple of interesting objects that look like you can extend them for more complicated things (like controls that access the SubText data, I'll bet). I'm sure that Phil Haack and others could point those out. In fact, they're nice enough folk on their dev email list I'd bet they'd be happy to answer questions if I took the time to ask.

Also, if you want those Great Games controls, download the source code. It's nothing fancy, but does the job. Or, if you just want the binary, download that instead. The source code project includes my GreatGames.ascx file as well so you can see an example of implementing them. Let me know if you do anything interesting with them.

14. December 2006 18:34 by Jacob | Comments (1) | Permalink


<<  February 2017  >>

View posts in large calendar