Sitecore And Umbraco – Right tool for the right job.

Inspired by this post Why is Sitecore getting so popular nowadays leaving Umbraco and Sharepoint behind I decided to explore further the reasons I think both CMS solutions can actually live happily as an eco-system as opposed to be considered competing.

First of all, I actively use both Umbraco and Sitecore as CMS solutions (though I get less call for Umbraco these days due to commercial reasons). I like both for their different reasons. I won’t even get into the reasons that Sharepoint sucks :D.

What Marina is saying is (in my opinion) true in that; I agree that Umbraco TENDS to be smaller scale implementations. I would debate the level at which that cross over between the likes of Umbraco and Sitecore are cost efficient to clients. Bear in mind – Umbraco has some big(ish) players in the marketplace, notably off the top of my head (previous or current) Heinz, Sandisk, Peugeot and Microsoft’s own

Continue reading

Simple Sitecore Tip – Right Click > Preview & Other Actions

Carrying on from the little tips post on Right Click Publishing, I had a requirement to add a few extra context menu items. I will use ‘Preview’ as the example here.

In order to give a context preview, follow these steps:

  • Change to the Core database
  • Create an item /sitecore/templates/System/Menus/Menu item called ‘Preview’
  • Set up the data in the item to look like this: Preview
  • Save your item

You can do similar with most of the item: which can usually be found here /sitecore/content/Applications/Content Editor/Ribbons/Chunks.

That’s it! 😀

PS: Please note, sure these tips aren’t rocket science, but if it helps 1 person once, my work here is done 😀

Simple Sitecore Tip – Right click > Publish Item

Ok, so I really don’t know why I get so offended by this Sitecore behaviour, but I do. Why is it I cannot right click on an item and publish it? So here is a simple way of achieving this.

In the core database copy:

/sitecore/content/Applications/Content Editor/Menues/Publish/Publish Item

To here:

/sitecore/content/Applications/Content Editor/Context Menues/Default

Job Done 😀

PS: Please note, sure these tips aren’t rocket science, but if it helps 1 person once, my work here is done 😀

Custom Permissions Pt II – Using custom permissions with Conditional Renderings In Sitecore

Following on from my previous post on Creating Custom Permissions in Sitecore. I thought I would expand this to show a typical use case a little more. More than once I have had the requirement to show ‘non-logged-in’ users an alternative version of a page (think experts exchange where you have to sign in to see the answer to a question). This by default in Sitecore is not so tricky, but you cannot simply do it by preventing read permissions to an item.

I have chosen to base this functionality on Conditional Renderings as, in Sitecore’s out of the box functionality, it already allows us to hide / change the datasource of pieces of presentation.
Continue reading

Agnostic IoC Pt II – Container Self Registration

So – here is the second in the series of introducing Agnostic IoC. In this topic I wanted to cover a standard problem that (particularly as developers of a proprietary system such as Sitecore) face regularly.

I have always (for convenience as much as anything) utilised the global.asax.cs to perform my container setup. This is particularly easy as I usually have this class inherit an interface. This conveniently allows me to cast the application instance as my ‘IContainerAccessor’ to allow me to get at the container. This (for Sitecore / Umbraco) in particular is inherently flawed in that, the vendors of third party systems also often mess with these classes – Sitecore for example (off the top of my head) have changed it in 2 or 3 of the last major releases and possibly some of the minors. I have seen (in implementations such as Glass Mapper), the use of WebActivator to overcome this too – this is a perfectly reasonable alternative.

In designing Agnostic IoC, I wanted to consider the possibility of having Agnostic scan the loaded assemblies for containeradapters and register them for itself, here is an example of the test container adapter we are going to use.
Continue reading

Don’t Fight The Framework – Sitecore’s built on Sitecore so build your site on Sitecore.

This one will be a relatively quick one ( hopefully before the girlfriend finds out I am working on our holiday 😉 ). Continuing on in the Don’t Fight The Framework series, I thought I would discuss a topic that has kind of formed the more I have worked with Web Content Management Systems such as Sitecore. As me and Simon used to band about in our development exploits (usually in a faux Danish accent) – ‘Sitecore is built on Sitecore’ and it got me thinking…

The basic premise is this – we as developers are often guilty of just opening visual studio and hacking away at our latest interesting issues / projects & crazy solutions to problems. I have found particularly with Sitecore you can sometimes get a feel for how successful a Sitecore solution you have developed by how much time you spend in Visual Studio ( not including Rocks before I get some clever < Insert suitable name for smart person > piping up! ). It is my opinion that the more flexible your Sitecore build is, the less time you should be spending in your development tools, and generally, if you are spending time, its to look up how you have used the rendering parameters / pipelines / data sources etc are controlled by the user interaction and potentially what templates are expected.

Continue reading

Glass Mapper – Introducing Glass Maps

This is due to be released in an upcoming module (along with the delegate mapper described here), however – here is a sneak preview of what I have been working on for Glass Mapper.

I think Glass Mapper is a fantastic and versatile ORM for Sitecore, however one of my slight bugbears with Glass Mapper as it stands is this. I want to build my POCOs as isolated as they can be. Glass Mapper has provided a fluent API which is grand, but the implementation by default leaves it a little short in my humble opinion. Out of the box, it’s a bunch of configurations that you add to the GlassScCustom (or in your own) class. In addition to this, if you want to support inheritance – say IExtendedSitecoreItem : ISitecoreItem you have to define all of the mapping for ISitecoreItem on IExtendedSitecoreItem as well. There are ways in Glass to sort this – using imports and the like, but you can end up with the framework excepting if you import the same thing twice. For me, I wanted an interface similar to that of fluent nHibernate, using a mapping generic to provide the mappings in an isolation from the original POCOs so I have created just such a thing:

Continue reading

Agnostic IoC – Released

Just a quick post to announce, the initial release candidate for Agnostic IoC is now available on the Cardinal Nightly Feed (soon to be Nuget)

The initial release provides support for the following IoC containers:

  • Castle Windsor
  • Autofac
  • Unity
  • StructureMap (experimental at present)

Other containers
Support for other containers can easily be added by creating a class deriving from the ContainerAdapter class and overriding the necessary methods. Use one of the existing ContainerAdapters as an example.

The nuget packages can currently be found on the Cardinal Nightlies Nuget Feed

Source Code
The source code can be found here Cardinal Github Page

Further Reading

Agnostic IoC Pt 1- Building Glass Mapper for Autofac, StructureMap, Windsor By Changing 1 Nuget Package

As a few of might already know, we started a project a short while back to overcome the difficulties developers face when building reusable modules for systems. This project was centered on the need to continually write our inverted dependency calls manually to avoid ties to an IoC container such as Autofac / Windsor. Recently a client of mine and also a friend have independently approached me about this subject. The former wants to commission me and Simon from the team here, to help them out on a build for a client of theirs, this client has asked that we use Autofac as the dependency container and Glass Mapper as the ORM. The second wants to be able to use Glass Mapper with their current implementation, they however use structure map.

It would have been a reasonable enough task to duplicate and modify the Windsor implementation from github twice to allow this to happen, but I fancied a challenge and thought this would be a good test of the Agnostic IoC extensions that I have written and talked about Here. After all, it is the near perfect use case for such an implementation – 1 framework with a choice of end IoC containers depending on the client.

What is Agnostic IoC?
Agnostic IoC is a set of extensions that aims to abstract the IoC container away from the final consuming implementation, you write your code against Agnostic IoC and it adapts the calls to the real IoC. You can initialise it from self discovery on adapters or simply push in your own already built container. It in many cases will not replace your own IoC implementation, it’s primary focus is to allow you to ship your reusable modules so others can enjoy them without tying them to particular versions of IoC containers. If the IoC container of your choice isn’t supported, it is quick and easy to write an additional one simply by inheriting from the abstract ContainerManager class. When consuming the application, you simply need to install the nuget package that matches your chosen IoC. If you need to get at any of the original functionality – the ContainerAdapter is a generic in its own right, you can simply cast something like myContainerManager.Container as IWindsorContainer to get back to the original container (that said – you can push your own in so not sure how much use it will be 😉 )
Continue reading