Automatically set the language of the content editor

In a recent build we had a request from the client to automatically set the language of the content editor based on where in the tree they were viewing. The rules for selecting the language were quite simple:

– sitecore
— Content
— English site – field with value for default language set to be ‘en’
— French site – field with value for default language set to be ‘fr-fr’

If the user was making changes within the English site, they wanted the Content Editor to default to ‘en’. If they were editing within the French site, they wanted the Content Editor to default to ‘fr-fr’.

With the help of support, the following solution was suggested:

  1. Create your own class inherited from Sitecore.Shell.Applications.ContentManager.ContentEditorForm
  2. Add a new method:
  3. Edit \sitecore\shell\Applications\Content Manager\Default.aspx, changing the sc:CodeBeside reference to point to your new class:

    Note, you need to keep the CodeBeside reference on one line as per the out the box version (the other controls are eg DataContext, RegisterKey etc)
  4. Edit \sitecore\shell\Applications\Content Manager\Content editor.js, adding a call to your new method. This needs to happen in the onTreeNodeClick method after LoadItem.

Moq – the basics

During a recent XP programming course we made use of the Moq’ing framework. I’d not used this before so tried to come up with some example moq basic tests. There are several tutorials on the internet which offer up the basics so do hunt around. Hopefully the following provides some simple examples for people to get started with.

The following code relies on the following assemblies:

The real crux of TDD is that you program your functionality to interfaces – here we have a simple interface and dto:

Note the importance of the virtual property in MyObject will be highlighted in the tests. In the following examples not all the tests pass – this is intentional! Failing tests are included to demonstrate specific features of Moq. Apologies for the long dump of test code – the idea is really to copy it into a test class and let NUnit do the work.

Here is the expected results when evaluated in NUnit: