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");
}

I have had the good fortune of receiving an offer of employment from a London-based company, specialising in both Sitecore and ASP.Net MVC solutions (so, right up my street).  I’ll be starting there in February next year.  I’m really excited about it and am looking forward to getting stuck in.

As for what this means for me, it does mean that I’ll be moving to London in a few months.  Until then I’ll be commuting by train from Coventry, which isn’t quite as bad as it sounds – the train to Euston takes only an hour, and then there’s a short tube trip.  All very manageable in the short term.  Once everything settles down, I’ll start the process of moving (again).  Fortunately I haven’t quite unpacked from last time, so there isn’t quite as much work to be done this time around!

Right now I’ve got a fair bit on my plate as I’m currently following up a couple of issues with my new place with the lettings agent which are dragging along somewhat, but not to the point where I want to go into details on here at the moment.

While a lot of the stuff in there was spam, there were a few comments that were genuine.  I know the comments are held in the queue for a few days before actually being deleted, so I’ve gone back as far as I can.  I’d just like to quickly apologise to anyone who has posted a comment and not had it show up; it’s nice to get some feedback and I do appreciate it.  I’m also going to be more vigilant in the future, and try to make sure I check it every so often.

Version 6 brings some excellent new features to the table; some which have been present in many other CMS products and others which are pretty unique.  I’m looking forward to working with it in July/August, which is when I’ve been scheduled to redevelop the bit10 website (the final designs for which have been described as “funky but clean”).  We’ll see how it goes; expect to hear more on the topic of Sitecore when the project is done.

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.

Anyhow, you’ll need:

1. 8oz dark chocolate (I use fairly cheap Tesco own 74% cocoa solids bars)
2. 8oz butter
3. 12oz castar sugar
4. 4 large eggs
5. 6oz flour

To make the brownies is pretty easy:

1. Preheat your oven to about 180°C
2. Break the chocolate up and melt with the butter.  Personally, I find it easier to do this in the microwave – pop it in for 30 seconds then stir and repeat until the chocolate is all melted.
3. While you’re doing that, put the sugar into a big bowl, add the eggs and whisk.
4. Gradually mix the chocolate into the egg and sugar mixture (keep in mind that, at this point, the mixture will start to cook so don’t take ages)
5. Gradually mix in the flour.
6. Pour the mixture into a baking tray.  I use silicon baking trays, which are flexible and non-stick; if you don’t have one of these, consider greasing the tray or using greaseproof paper.
7. Bake in the pre-heated oven for approximately 30-40 minutes (or until cooked).

Couldn’t be easier, and it makes plenty.  If you want gooier centres, then you can probably reduce the cooking time or generally tweak the ratios.  Just don’t forget to let them cool before you try to dig in!

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());
        }
    );
}

If anyone had asked me how to put these three things together a week ago, I would have cringed; my next reaction would be to suggest upgrading to PHP5, using Apache, and one flavour or another of Linux.  Unfortunately that wasn’t possible at this point so, armed with the usual developer tools (that is, the F1 key and Google), I set out to get things set up… after all, how hard could it be?

While I’m sure I didn’t say that last bit out loud, I must have tempted fate as I spent the next day or so spouting obscenities at my poor computer whilst flitting about the internet looking for solutions to one problem or another.  My first suggestion is that you read the instructions in the PHP manual thoroughly; I glanced over them filled with false bravado based on having installed it on Apache many times, but didn’t really take note of the specifics.  This proved to be my downfall, as points five and nine of the general considerations were especially important.

Once everything had been done, though, it still didn’t work – requests just resulted in a 500 error code.  After investigating the issue, I found that (on some machines) installing a particular version of ActivePerl on a machine can break IIS.  This is because it adds an application mapping for the “.plx” file extension, but doesn’t enter an executable path; and this just breaks the server.  Since I didn’t need to be able to serve these files, I deleted the mapping and this made everything work.  If you do need to serve this sort of file then I would imagine that entering the appropriate path in the mapping would also solve the problem.

So, I hope that helps someone.

I think I might start looking at some proper accreditations in the near future, as they can only help my career prospects, and I think they’d really be quite interesting.  The question is whether I’ll have to cough up the money myself or if it will be covered under CPD…

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.

Aside from that, it was all fairly easy thankfully.  Now I just need to see about getting some extra hard disks for storage and possibly a new screen… my dual 15″ screens are getting a bit old, I just need to decide whether I want to stay with a dual screen system or get a big widescreen.  I don’t think my finances will quite stretch to two widescreens; or my desk space for that matter.

Add in a nice OEM version of Vista and I’ve got a new favourite toy.

Aside from the start, which had a mild overdose of the word “Awesome” (intentionally, we later found out; I would highly recommend this film to anyone regardless of age.