New Version of SingleUserBlog

by Matt 18. November 2006 17:29

Hey, look at me - I'm dog-fooding! I've just uploaded a new version of SingleUserBlog, the first since before it went open source, way back at the start of September. There have been quite a few changes to the code since then; just check out the list on codeplex.

Some of the changes I made have just been migrating changes I'd already made into the mainstream codebase (hence only just upgrading), but the most exciting changes are new ones.

We've got Windows Live Writer support, including uploading images:

Friendly urls are also very cool - instead of http://sticklebackplastic.com/Posts/Post.aspx?postId=3a1ca8b7-8012-44f5-84a7-82556a0e373e, we get http://sticklebackplastic.com/2006/9/3/SingleUserBlog+goes+Open+Source.aspx. Much nicer.

There's even rudimentary support for attachments.

There's still plenty to do (especially making it easier to install)

The only downside to the upgrade is that the change to friendly urls has changed all the guid/links in the rss feed, so it's duplicated all of my posts in IE7's feed reader. Sharpreader hasn't had a problem with it though. Oh, and I've lost some of my web parts customisation in the sidebars - it'd be nice to get that back.

Still, good stuff, and I'm very pleased. Hopefully, I can keep it up-to-date as more changes come in.

Tags:

SingleUserBlog

Working with multiple conflicting config files

by Matt 11. September 2006 18:26

One of the luxuries of working in a corporate environment is the uniformity (and I never thought I'd say that). You're in control of just about everything - you can ensure that all developers are using the same configuration. You can all use the same databases, the same web services, the same web sites.

Working on a distributed, open source project is entirely different. You're not in control of the environments being used. Different developers will have things set up differently. And all this is reflected in different web.config files.

There's just one teensy-weensy problem. The web.config file is under source control, which means there is only One True Copy. And if I change it to get my site working, I change it for everyone else, and break theirs.

Of course I'm talking about SingleUserBlog, and of course, this is a problem we've hit. We're all using a different config to each other, and I've already checked in a config file that won't work for everyone else.

So I've had a play around and I've come up with a solution. It's teetering dangerously close to over-engineered, but it also does the job nicely, and I learned a few things to the bargain.

Since SingleUserBlog uses Web Application Projects, it's an msbuild-based project. And the nice thing about msbuild-based projects is that you can edit the project file, add your own tasks in and Visual Studio will still quite happily run with it.

The idea is quite straightforward. Get rid of the web.config file. Create a default.config file that contains the default settings for the project - the one you'd be happy to release. Then, change the .csproj file to copy this file to web.config and use the ReplaceConfigSections task from the Web Deployment Projects add-in to replace any sections in the file with xml from external files.

The implementation is perhaps a little awkward, but it's not exactly horrible either. First, in the main .csproj file, import a MergeConfigFiles.targets file that does the heavy lifting. This new file needs to set up a UsingTask to include the ReplaceConfigSections task. It also needs to set up a few default properties, such as the name of the config files to copy ("default.config" to "web.config"). It then imports another .targets file, if it exists. This one is $(USERNAME)-MergeConfigFiles.targets. If it doesn't exist, the default.config file just gets copied, unchanged to web.config. If it does exist, it should be another msbuild project that simply sets up an ItemGroup containing ConfigReplacementFiles items. Each item points to a file that just contains xml that will replace a specific section in the web.config file. That section name is defined in the Section metadata item in the ConfigReplacementFiles item. The ItemGroup is fed into the ReplaceConfigSections task.

When a build is run, Visual Studio will copy across the default config file, then process this copy, replacing all the sections listed with the contents of all the files listed. If any of the files change, or if the default file changes, it gets rebuilt. It even deletes the web.config file on clean.

There are a couple of issues with this method, but I don't think any are showstoppers. It's perhaps not ideal to have to define this with an msbuild project file, but it's not difficult. Here's an example:

<Projectxmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <ConfigReplacementFilesInclude="compilation.config">
      <Section>system.web/compilation</Section>
    </ConfigReplacementFiles>
    <ConfigReplacementFilesInclude="authentication.config">
      <Section>system.web/authentication</Section>
    </ConfigReplacementFiles>
  </ItemGroup>
</Project>

Not exactly difficult. Another drawback is that if you change this .targets file, the changes are not reflected until the project is reloaded. Not ideal, but not major, either. Oh, and it will only work for web.config, too - the web deployment project task assumes that. Supporting app.config wouldn't be too tricky either, but would require a custom task.

One drawback that could actually cause problems is ensuring that your overrides don't override something new, or you only add new things to your overrides, but this is really just something you need to keep track of.

Another interesting drawback is that asp.net will automatically recreate the web.config file for you if it gets deleted. Somehow it knows to call the .csproj file and get it created correctly - well, mostly correctly. It did generate some things incorrectly while testing that, and it always did a full build after that anyway, so everything still worked correctly.

The only files that get into source control are default.config and the initial MergeConfigFiles.targets. The username based file doesn't get added, and neither do the local changes.

It might be easier to download an example and actually try it out. Let me know what you think.

Tags:

SingleUserBlog

SingleUserBlog goes Open Source!

by Matt 2. September 2006 18:16

After the gentlest of nudges, Darren's put SingleUserBlog on CodePlex. This should be fun. I've got a load of little changes that I want to submit, I just have to decide what goes first. A nice position to be in.

Unfortunately, setting up the new version really gives me what should be my first change. And it's not going to be an easy one.

One of the things that got me using SingleUserBlog in the first place was that it uses xml as the blog data store - my web site doesn't come with access to Sql Server, so that suits me down to the ground. But it *does* use Sql Server as the data source for Web Parts and the "remember me" part of the comments.

I've gotten around this by using a set of providers that use a Microsoft Access database, but there's a litle glitch with the Personalisation Provider (which I've got a nice big ranting post about this for later) that makes me really reluctant to submit them. I've got a bit of a hack that gets round it, but I'm sure there has to be a better way. And it's a bit clunky using Access, too. It would be much nicer if we could have a completely xml based install. Brendan created an xml based Personalization Provider that handles the issue, so perhaps this is the answer. It's a very specific provider, in that it will only work the exact way SingleUserBlog currently uses it, and again, that makes me think there should be a better way.

I'll have a think and write that nice ranting blog about rubbish APIs and see what happens.

Tags:

SingleUserBlog

More SubV2 changes

by Matt 29. August 2006 17:36

Yeah, a little more hacking (and a quick post as means of a test). The RSS feed is now outputting categories, and the author now uses the logon name (which happens to be my name) rather than the site name. I've also embedded the trackback ping url in there.

It's also getting a little hard to test the rss feed - I've subscribed to it in IE7, so when I navigate there, I actually get the new feed platform's view of my feed, which means it's all re-parsed and not the actual xml that I return. As a top tip, you can just go into notepad, go to File -> Open and type a web address, such as http://sticklebackplastic.com/Rss.ashx and wait a second or two and notepad will now open the item from IE's cache. That's a lovely little feature of the common dialog.

Tags:

SingleUserBlog

Windows Live Writer progress

by Matt 17. August 2006 16:54

Me, yesterday:

So, bugs. [...] Another biggie is editing a post and hitting publish create a new post, rather than updating the original.

Fixed.

And categories work too, and the time no longer resets to 01/01/0001. Trackbacks don't though - they currently only work for initially saved posts from the web site. Fixing this one will require moving files around between assemblies.

I'm really getting to like Windows Live Writer. I've even had my first idea for a plugin...

Tags:

SingleUserBlog

Windows Live Writer + SubV2 = Not bad, really

by Matt 16. August 2006 17:43

So, as previously noted, I've been trying to get Windows Live Writer working nicely with SubV2. Once I realised that the MetaWeblog API is actually plumbed in, I tried it all out. An hour or two of tweaks to the code later, and it's working rather nicely.

There were a couple of problems. Null data in the XMLRPC structs were not being ignored, so an exception was thrown. Also, posts weren't getting created because the security was checking that you were logged in on the website, and well, you aren't. For now, I've just commented out the check (not in the least bit dodgy!)

I've even added RSD support, so that WLW can just look at the homepage and auto-configure everything. Super.

The RSD support comes from a new http handler Rsd.ashx. Unfortunately, the xml content is written from the code. I'm not sure how to write markup in an ashx file - I just got compile errors. I presume you could wrap everything in asp.net style controls, and take it from there. (I also need to add output caching. Add another todo to the list)

Part of the wizard tries to create a post, gets the homepage and works out the styles so that it can provide a web page preview. This fails. Creating the post is fine, but the fetch of the page doesn't work out too well. SubV2 makes heavy use of caching, but some of the cache code is very broken. I've already fixed a bug where cached items don't expire (the value in the web.config is never passed in - evidence of this is that I posted a comment on one of Darren's post two days ago, and it still hasn't appeared!) and I've cleaned up a lot of issues where the cache wasn't invalidated when posts and categories were created, deleted or edited. One I haven't sorted out is invalidating the list of posts - this doesn't get invalidated. Which means that the new post created by WLW doesn't get displayed on the homepage, and the whole auto-discovery process falls on it's face. Quickest way to fix? Set the cache timeout to 10 seconds.

So, bugs. The most obscure I've found so far is if you're highlighting text with the cursor keys + shift, you're at the end of the file, you go left, you can't de-select text by going right. Another biggie is editing a post and hitting publish create a new post, rather than updating the original. And when you get the latest posts, they don't get persisted anywhere, which is a shame.

And SubV2 doesn't support the newMediaObject method, so no uploading pictures.

But all in? I rather like it. Beats editing in FreeTextBox on a web page that times out after 10 minutes. Just got to fix some of those bugs...

Tags:

SingleUserBlog

SUBv2. Nice...

by Matt 1. June 2006 10:47

I looked at quite a few blog engines before settling on this one. My needs were simple - ASP.net, no SQL Server (I'm too tight), self hosted and I need to be able to extend it and add my own pages. That rules quite a few out straight away - all the big boys (MSN Spaces, Blogger, the .Text family of .Text, Community Server and SubText). In fact, a while ago, the only contender was DasBlog.

It ticks all the boxes; the data store is xml, so that handles my no SQL Server requirement. I just plain didn't like it. It's got a funky template system where each page is implemented as a single ASP.net page that contains a single control which is a template processing engine used to generate pages. It seemed the wrong way round - ASP.net is already a template processing engine that can generate pages, why write another one?

So, I decided (foolishly) to write my own. Didn't get round to it, obviously (far too many other interesting things to waste my spare time on) and so I was really rather pleased to come across Darren Neimke'sSingleUserBlog. This looked ideal. An xml data store, ASP.net application, source code, sensible controls. Marvellous. All I had to do was upload it.

And change the CSS.

Now, I don't really like CSS, so managed to procrastinate long enough for Darren to release SUBv2, which was ASP.net 2. It used Web Parts. Oooh, shiny.

And of course, my ISP was ASP.net 1, so I got to procrastinate some more. But I upgraded a couple of weeks ago, and lo and behold, a lovely blog engine powered by the really nice SUBv2.

So, why am I telling you all of this?

Well, it's in way of warning.

I'm having great fun hacking the code base for SUBv2. Darren's done a great job, but having the source available means that I can't resist the urge to crank open the bonnet and have a root around. It's a great learning exercise for a lot of ASP.net 2 stuff, and there were just enough things I needed to tweak before I could use it to get me hooked.

And the warning? Well, there's a lot of things I've got out of this that I'm going to post about...

But mainly, this post is just to say, thanks Darren. Nice job.

Tags:

SingleUserBlog

Month List

RecentComments

Comment RSS