This afternoon, for want of anything better to do with the freezing cold outside and the housework inside, I wrote an archive calendar chalk extension for the website. It's over there on the far sidebar.

At present, it's a chalk extension and not a widget, although a widget should probably make more sense, given that it's in one of the Graffiti sidebars. However, for this first iteration I wanted to make a monthly calendar with links for those days when I'd published posts.

User stories were these:

• The calendar should show a single complete month, with days when I'd posted something displayed as links.
• The caption should show name of the month being displayed in the calendar.
• The calendar caption should show the number of posts for that month.
• Clicking on the calendar caption should go to a page listing the posts for that month. The calendar should stay the same on that new page.
• Clicking on a day (providing it has posts and is a link) should go to the page listing the posts for that exact date. The calendar on that new page should show the month for the date whose posts are being displayed.
• Underneath the calendar there should be a link to the previous month. Clicking it should do two things, first display the page for that month, and second change the calendar to display that new month.
• Also underneath the calendar there should be a link to the next month, providing that this month is not in our future (so, for example, on the home page, there is no link to the next month). Clicking it should display the page for that month, and also change the calendar to display the new month.
• Tooltips for the  links should be specific to the month or date.

Up until now, I've been using an open-source Archive Widget, but haven't been that happy with it (for a start, it produces HTML that doesn't validate, you can only show posts for a single month, etc). Since it's written in VB, I wasn't particularly enamored with fixing it (I'm a C# guy at heart) and I really wanted a month calendar. But, nevertheless, I liked the way it worked, so I resolved to use the same infrastructure (that is, the same folder /archive, the same views (at least their names), and the same request structure for passing the date along to the page).

Still to do:

• Make it a widget so that it can play in the admin setup for sidebar widgets.
• Employ some kind of caching for the lists of posts in a given month. In essence the same list is generated to display the page as is to display the month in the calendar (the calendar needs the list in order to work out which days to make links and also for the post count in the caption). So for displaying the complete page for December 2008, for example, the same query is run twice on the database. The original archive widget had caching, so I ought to implement something similar.
• Clean up the code. At the moment it's a huge violation of the SRP (Single Responsibility Principle), although no method exceeds CC 5.

I'll admit I'd started out trying to use DevExpress' ASPxCalendar control, but I ran into issues of how to host an external control inside a Graffiti view — let alone a sidebar widget. I shall have to play with that some more at a later stage (I fancy creating a page that shows the posts as a schedule using ASPxScheduler). So, for this implementation I wrote the calendar display code from scratch, although I did employ the same techniques as I used in 1991 for a Turbo Vision calendar control (scary, eh?). I used the look-n-feel that Eric Meyer has on his blog.

Now playing:
Eighth Wonder - J'ai Pas Peur
(from I'm Not Scared)

Share it:                

No sooner do I finish my quick series on customizing a Wordpress theme for Graffiti (I, II, III, IV) than I throw it all away for a — gasp — hand-written one. Yes, I got bored with the browns and went with the grays.

There were two reasons for this: first, I wanted to use the entire wide-screen browser window and avoid the dead space on either side, yet still have a non-cluttered look, and, second, I wanted to use the visual ideas present in Adobe Lightroom in doing so.

Adobe Lightroom is an application that is geared to the photographer's workflow where the image is king. Everything on the screen is deferential to that idea. So the entire display is built of shades of (dark) grays so that the image you're working on stands out. And even with those grays, it has been designed so that only the important textual information is in light grays or white, the rest blends in with the background so that it doesn't distract from the job in hand: manipulating your photos.

So I wanted that kind of behavior. For the blog, it's the content that is king, the blog posts. And so it's those that should stand out in the display, not the widgets on the side, not even when the metadata about the posts. That stuff can be there, sure, but it shouldn't distract from the real meat of the blog.

Going along with all that, I wanted to make the theme image-free. No little gradient PNGs here, no fancy-schmancy rounded corner GIFs there. Images that are displayed as part of the theme (like my photo of the Castlerigg stone circle) had to blend into the background: they're there for decoration, but should not distract.

After that, it was a case of finding the right layout for the blog. I spent an hour or so, trawling the Wordpress themes, but there was nothing there that (a) were plain enough, or (b) that were wide-screen enough.

In my travels, I came across Eric Meyer's blog. and it had the kind of layout I was looking for where, sure, there is a sidebar, but the content column filled the remaining space.

That was my layout inspiration, and with my palette of grays from Lightroom, I spent the last three evenings building and tweaking the CSS file and view files.

The hardest part was the damn tag list for each post. $post.TagList is a comma-separated string of tag names. $macros.TagList takes that string and creates a comma-separated lists of URLs to the various tag queries. I wanted a vertical list of tag URLs created as a bunch of <li> elements, but it seemed that the only way I could do this was write my own plug-in. Since I've not done this before yet, I put that idea on the back shelf. I had another idea that I fleshed out in my mind: write a javascript function that parses the taglist and creates the required list of URLs, but that was discarded in favor of a bit of CSS jiggery-pokery that styles the <a> elements in the <li> to be float:left and clear:left. As a workaround, it works very nicely as you can see, with only one small bug left, which, because of my underlying vision for the theme, is all but hidden.

Last night, just before midnight I "flipped the switch" and it went live.

There are still a few bugs, but I'll be fixing those this evening.

Share it:                

Part of the job of altering the theme for this site, or indeed writing the "theme" for an ordinary page (here's my résumé, for example), is writing or modifying the CSS file (Cascading Style Sheet) to make it look good. I've used three main resources to help me do this as efficiently as I can.

Cascading Style Sheets: The Definitive Guide by Eric A. Meyer. Yep, my copy of this is so old, it still has the old name (it's now called CSS: The Definitive Guide), No matter what it's called, Meyer does a bang-up job in explaining the nitty-gritty of the Box Model — don't leave home before you understand this in all its glory — and all of the various CSS properties and attributes. You may start reading this and get disillusioned with all the gotchas in the CSS support amongst the various browsers, but I've had great success in following Meyer's explanations and recommendations.

TopStyle 3.5. Written by Nick Bradbury, currently owned by Newsgator, but just sold to Stefan van As to ensure its further development. I've been using this product since Nick brought it out, and it really does make creating stylesheets very easy. Although it's great for static HTML pages, it's not so good for dynamic ones, and so the changes to the CSS file for the Chronicles theme were a bit hit and miss. I did get to the point where I saved off the current view of a webpage from Graffiti, just so I could fine-tune the CSS in TopStyle.

Firebug. If you are developing HTML and CSS and and indeed javascript, stop what you are doing right now and install this add-in into Firefox. (I won't even slow down to say, whaddya mean you're not using Firefox?) Firebug is great at showing you the "cascading" bit of CSS, live on a web page. You can point to an element and Firebug shows you the CSS that is being used to style that element, displaying the inheritance from the outer scope to the most inner scope. The nice thing is the padding and margins are shown in different colors, meaning to hone in on box issues straightaway. Brilliant. The javascript debugger is pretty good too, although I haven't used it that much.

And finally, to ensure my website has the latest files (and vice versa, for backup purposes)...

FireFTP. Neat-o visual FTP client implemented as a Firefox add-in. I love the visual syncing of local and remote folders (drill down through the folders in one pane and the other pane follows suit), and the drag-and-drop between panes. Nicely done.

Share it: