Originally I tried setting the media ID and the media path properties, but that didn’t quite work.  Eventually I found that you have to set the media ID, media path, source, and a custom attribute (“showineditor“).  I was surprised that it wasn’t easier to assign a media file to an ImageField object, but that’s easily resolved using extension methods introduced in .Net 3.5.  For the lazier among us, I’ve included a small snippet of code that does the important stuff.  This code is written for Sitecore 5.3, but should work on Sitecore 6.x with minor tweaking if some nicer methods haven’t already been put in place.  Obviously, production code should be made a bit robust than what’s below, which has no exception handling and assumes the item is already in editing mode.

public void AssignMediaItem(ImageField field, Item mediaItem)
{
    field.MediaID = mediaItem.ID;
    MediaUrlOptions options = new MediaUrlOptions();
    field.Src = MediaManager.GetMediaUrl(mediaItem, options);
    field.MediaPath = mediaItem.Paths.MediaPath;
    field.SetAttribute("showineditor", "1");
}

First of all, for anyone who isn’t familiar with MVC (or Model View Controller), it’s a design pattern that emphasises the separation of concerns within the application, essentially: presentation data is kept separate from the application data, which – in turn – is separated from the logic relating to data storage, manipulation and retrieval.  The result is – for the most part – an application that is surprisingly easy to maintain and adapt.

The idea is to have a controller class, which exposes several public methods – or, actions – which can be called by a web request.  These actions execute a task, often involving communication with data storage through the model layer, and then finally pass data to a view, which renders the data and returns that to the user.  Some actions may have filters that run at various stages in the request, and can alter the end result of the request (a common example is to ensure a user is authenticated before processing an action).

For the most part, I have been pleased with the ASP.Net MVC Framework.  It bears striking resemblances in many places to Ruby on Rails, however it is often apparent that the framework is in its early stages as it is not as polished as Ruby on Rails.

Filters were one thing that irritated me somewhat, however they also had some features that I thought were original.  First, I thought that the usage of filters was cumbersome and quite inelegant: filters can be placed either on an action or an all actions in a controller class by decorating the method or class with the appropriate filter attribute.  The result of this method is that your controllers can become a hodgepodge of filter attributes.  I wish I had the syntactic sugar of Ruby on Rails’ before_filter function, where it’s possible to write:

before_filter :require_admin, :only => [:delete, :create, :edit]
before_filter :require_logged_in, :except => [:login, :register]

I think that something based on the above would be a much neater way of specifying filters.

I liked having access to the “request context” from all the main parts of the application.  It serves as a rather straight-forward method of passing data between the layers and of accessing the original request information.  Something that can be difficult to do when you get deep into Rails applications: you lose the context of the request; you can’t get the original controller action or other request data.

I thought that the approach of using the ActionResult type to offload the work of processing each type of result was an excellent idea.  It actually neatly avoids a common source of errors encountered during the development or Rails applications: the “double render” error.  This error happens when, for example, a redirect is issued but then the controller continues to issue a view result also (caused because Ruby on Rails controller functions responsible for issuing results do not cause the controller action to return). Returning the ActionResult neatly avoids that issue.

Initially I took great issue with the typical method of passing data into views via the ViewData dictionary.  I didn’t like the lack of strong-typing, the messiness this introduced into the view code, nor the ease with which certain things could be omitted from the dictionary.  I’m aware that the first and last really also apply to Ruby on Rails: the first I can ignore because Ruby, unlike C#, is dynamically typed; the second however, remains equally valid.  I would like to have some sort of contract between the View and the Controller that specified what data will be supplied, although I’m aware this is heading more toward the MCP design pattern.

Shortly after my disappointment over the ViewData dictionary, I discovered the existence of page models.  The ASP.Net MVC framework allows you to create strongly typed views by use of a page model (in most cases, a class that exposes a number of properties containing information that would normally be passed via the ViewData.  It doesn’t allow you to require values to be passed into the view, but it’s much better than the alternative.

Then finally we have the Model Binding of the ASP.Net Framework.  This is still a bit of a black art to me; I’ve not yet had time to sufficiently examine its workings, but it is rather nifty.  It enables the binding of values to objects in the controller and views; this allows controller actions to use model objects (e.g. a user object) as a parameter rather than having a parameter for each field of the user.  It also allows “sticky fields” to be implemented very easily in the View.

That’s all that’s come to mind right now – although I’m certainly sure there are other things that I’ve overlooked.  You may notice that I’ve omitted practically any reference to the Model part of MVC; this isn’t a co-incidence, it’s an avenue that I’m leaving open to the possibility of future posts given the fact that the ASP.Net MVC framework does not tie you to one particular ORM like Ruby on Rails does (generally speaking).  It would make the scope of the post far too large, and I feel that this post is pushing the bounds of length regardless.

Anyway, these are my thoughts; if anyone has some other views, contributions or corrections, I look forward to reading them in the comments.

Fortunately, after my own trip to the TinyMCE API, I spotted the init_instance_callback option, which allowed a function to be called upon the creation of a new editor.  Perfect.  The initial version of the code is below, hopefully if anyone else finds themselves in a tight spot, it might help them out.

tinyMCE.init({
    mode : 'textareas',
    theme : 'advanced',
    theme_advanced_buttons1 : 'bold,italic,underline',
    theme_advanced_buttons2 : '',
    theme_advanced_buttons3 : '',
    theme_advanced_toolbar_location : 'top',
    theme_advanced_toolbar_align : 'left',
    theme_advanced_statusbar_location : 'bottom',
    init_instance_callback : "initialiseInstance"
});

function initialiseInstance(editor)
{
    //Get the textarea
    var container = $('#' + editor.editorId);

    //Get the form submit buttons for the textarea
    $(editor.formElement).find("input[type=submit]").click(
        function(event)
        {
            container.val(editor.getContent());
        }
    );
}

Even though I’m not paying for it, it’s definitely well worth the money that they charge for the normal plans.  It’s great coming home and knowing that you’ve got something to watch that you haven’t seen before.  The choice of films is great, and as long as you get plenty of films on your “to rent” list, you’ll never be stuck without.

I think there’s a perpetual 30 day free trial offer on as well, check it out.

I think that this site has something to offer to everyone by way of advice. It would be difficult to have a look through there and not find something pertinent. I’m certainly going to make use of some of the advice on there. Absolutely fantastic.

Not a new idea by any means, in terms of the way it works, although the metric is a good one.  I’d like to see how this copes with a full copy of Wikipedia.  It would be interesting to say the least.

[link]

Along with version 2 comes built in support for widgets, so I’ve finally been able to put up a nice little widget containing my Google Reader starred items. Yay!

How to automatically back up your computers with rsync – Lifehacker

I saw this article pop up in google reader on Thursday, and realised that it was actually a pretty good idea. My DreamHost account comes with 200GiB of disk space and 2TiB of bandwidth. Additionally, these both grow in size every week by 1GiB and 16GiB respectively, so I’m hardly even losing data by backing stuff up. You’ll also need some kind of linux server that you can upload to, you may want to consider creating a DreamHost account.

Unfortunately, it’s not really as easy as it looks if you use Windows. I wanted to back up the My Documents folder, which as you might be aware, is a “special folder” (along with My Music, Shared Documents, etc.). Special folders will contain a file called desktop.ini that contains information about the folder (its name and icon, for example). However, according to KB326549, Windows likes to do something a little… unorthodox with the folder permissions – Windows will only look for the desktop.ini file if the folder is marked as read-only. Actually setting the folder as read-only, though, doesn’t actually make the folder read-only: in its infinite wisdom, Windows typically ignores the flag.

So, you might be thinking: “Why does that matter?” right now. Well, in order to run rsync, you will need to install Cygwin, which is (more or less) something that lets you compile unix programs and run them on Windows. Before you run away at the mention of the word “compile”, don’t worry – Cygwin comes with many programs pre-compiled for you, rsync and ssh included. You can get Cygwin here. I think it’s a pretty handy way of backing my stuff up.

HTTP, as most will recognise as the protocol we use to fetch resources when we browse the web, has some rudimentary built-in authentication facilities, and although the idea of using these with RSS is not new, it surprises me that the technique is not more widely used.

Advantages of using authentication with RSS feeds provide several possible applications: firstly, it allows sites to provide “members-only” content; secondly, it allows users of a site to select content based on their interests (provided the site had such functionality); thirdly, and of more import to sites than to users, it would allow targeted advertising to be delivered to users.

The easiest way to implement authenticated HTTP would be to respond with a 200 response upon receipt of either correct auth data, or no auth data. In the latter case, the server would send out the public RSS feed; in the latter, the server would obviously send out the private version. In the case of incorrect auth data being provided, the server responds with a 401 response, just like any other authenticated transaction.

The downside to the above method is that the user won’t be made aware if a personalised service is available. If we slightly fudge the meaning of the 401 response, we can do the following: on recepit of either incorrect auth data, or no auth data, the server responds with a 401, and the body of the document contains the public version of the feed. When the server receives correct auth data, the server sends the personalised data with a 200 response.

In this manner, the client knows if a personalised version is available, because it knows that it sent no auth data, but feed data has been received. Furthermore, it knows if personalisation is not available, since it will just receive the 200 reply if it doesn’t send any auth data.

I’m sure there are other methods of providing the same service, these just strike me as the most intuitive that don’t require separate URLs for subscribers and non-subscribers.

Google Reader is a web-based feed aggregator. It’s still in beta, so there are a few bugs here and there, but by and large it’s quite a nifty little piece of software. Interface-wise, it looks rather like GMail, RSS items are listed rather like e-mails would be, and you have the ability to apply your own tags to the news items. The feeds themselves act like folders, and can be sorted in their own folder hierarchy.

A nice little feature of Google Reader, though, is that you can mark items that you particularly like as “shared”, and these shared items can then be viewed by other people, with the link, or can be displayed on your own website.

On the subject of bugs, the only one that causes me any real annoyance is that, occasionally, one item, or several contiguous items from a feed will be duplicated. Now and then, a little red bubble will appear top centre saying “Oops there’s been an error”, but nothing obvious happens; once in a while the interface will just refuse to load, but this is always fixed by a refresh.