Using KnockoutJS with SignalR in ASP.NET MVC

KnockoutJS is a MVVM implementation for JavaScript written by Steve Sanderson, in my opinion the author of the best ASP.NET MVC textbooks available. Simply put it lets you bind a JavaScript object model to your HTML UI using a Read more

A MongoDB Tutorial using C# and ASP.NET MVC

In this post I'm going to create a simple ASP.NET MVC website for a simple blog that uses MongoDB and the offical 10gen C# driver. MongoDB is no NOSQL database that stores information as Binary JSON (BSON) in documents. I Read more

Linq To SQL Tutorial

Check out some of my other Linq to SQL posts: EntityBase Inheritance Modifiers with SQLMetal Linq to SQL with WCF Services Linq to SQL Framework (Repository/Business wrapper) ObjectDataSource binding with server side paging and sorting Load Options Generic Framework using reflection This is a basic tutorial for Read more

Thoughts on the Sitecore Experience Accelerator (SXA)

Posted on by Joe in Sitecore | Leave a comment

The views expressed in this post are entirely my own based on my own experiences.

What is it?

Previously a module and now built in to Sitecore 9, SXA is a set of layouts and components to allow drag-drop creation of a Sitecore website without developer interaction.

The underlying grid system is defined by Sitecore. You can choose from Bootstrap, Foundation or Grid960, and also create your own grid system but what you are somewhat restricted to allow SXA to work. Through Sitecore you can design your layout adding columns and placeholders ready to drop components.

SXA comes with a library of common components that can be used out of the box and dropped onto the page.

When SXA could be a good fit

Sitecore claim SXA will get your websites up and running faster and allows backend, front-end and content to all happen simultaneously. This is somewhat deceiving as in real world scenarios I only see a small number of situations where this may be true.

One valid use case would be that a client needs to create many microsites inside their Sitecore instance without developer help, and only with simple CSS styling that can often be done by a design agency without front-end developers. Perhaps an advertising agency that needs to create many campaign microsites that need different layouts and components. Here SXA is a good fit and with a few clicks a new website could be up and running, but prior to this there would likely need to be a full development phase from a development company whereby Sitecore has been configured properly and any custom components built and deployed. After this point the advertising agency could go forward and create microsites on their own.

“SXA may be a good fit for organizations that use a lot of highly structured sites that make use of shared content. Examples include chapter sites for associations, franchisee sites, affiliate storefronts and conference/event sites.” 1

Other reasons to use SXA may be for small implementations where requirements are already met by existing SXA components or where the development team doesn’t have the time, experience or resources to take on a larger development; perhaps an organization with a single internal developer. That said in both these cases the question really should be is Sitecore the right product? You could still leverage the marketing features of Sitecore if that was beneficial, but the end result will be a cookie-cutter website which you could get from any number of other CMS systems some of which are open-source and free.

The problems with SXA

Something like SXA is trying to be a one-size fits all website generation tool and with anything of that nature there will be compromises to the quality of the finished product. The HTML generated is controlled by the SXA Grid system taking away all control from the front-end developers.

“SXA may not be a good fit for organizations that desire highly customized & intricate presentations and have highly trained front end designers/developers. If your front end team is on the (b)leading edge with React, Redux, Axios, etc. the structure of an accelerator will likely stifle their creativity and productivity.” 1

A similar issue will happen with the components in the component library. Due to the one-size fits all nature these components are bloated with libraries to make them backwards compatible, and you have no choice but to use them as is. Adding a single component to page can result in a plethora of references to JavaScript libraries bloating the page and load times. These may be minified by Sitecore, but they may not be needed at all and as a developer you are losing control.

SXA promotes a somewhat backwards website creation process. Traditionally you start with designs that are approved by a client which then go to front-end developers to create the mark-up and any other front-end functionality required for the website. The choice of any grid or templating system as well as libraries used should be driven by the design and specific requirements of the website.

With SXA with page layouts are created inside of the Sitecore user interface and with a click of a button all of the assets (CSS/JS/HTML) are output in a ZIP file ready for the front-end developers to style.

“The idea that Sitecore Developers can create a bunch of components throw it over the wall and a front end team can get everything to look perfect is naïve.” 2

The idea is that front-end developers would then add their own styles to the mark-up which is then reimported back into the Sitecore media library ready for the website to use. This is an approach that any self-respecting front-end developer would find insulting, and it based on an outdated understanding of what front-end development is. It is extremely restrictive on front-end development dictating the process and toolset that a developer can use, which is not something a CMS should be doing.

Another major concern to this approach is that all of the front-end assets are stored in the CMS. They are not properly version controlled and could be edited inside Sitecore. Of course, the exported assets could be version controlled, but they are not the exact assets used by the website. When it comes to deployments there would be a lot of additional work required. For automation you’d need to serialize the items to allow them to be deployed to other environments, and those items would be source controlled. At this point you could have the assets in two different source control repositories, one outside of Sitecore and one serialized as part of your Sitecore solution. In doing this there is a lot of overhead added for managing the assets and deployments that would not even be a consideration in a non-SXA build.

SXA documentation suggests that with SXA front-end and back-end development can happen in parallel implying that without SXA it cannot. This is not the case and a well-organized team with good communication can easily work on front-end and back-end tasks together, only here decisions on application architecture come from requirements and is not restricted by Sitecore. Everything rendered by the browser would be controlled by the development team ensuring high quality output that meets requirements.

Over the last 10 years the definition of front-end development has changed a lot, going from simple styling tasks to taking on a lot of the work that would have previously been done server side to provide a better user experience. The introduction of front-end presentation libraries such as Angular and React has accelerated this making it much easier for developers to create rich web applications using more traditional software design patterns that were previously only available to back-end developers. These tools and frameworks are evolving at an amazing pace, and even though SXA does use some of them, it will not be able to keep, resulting in a website using outdated versions of libraries or outdated technology altogether.

While it is possible to create a custom grid system in SXA and create custom components there is an overhead in creating those components, and you are still restricted on what you can do. In a scenario where a lot of custom work is required then using SXA will definitely add more time to development and not reduce time as it’s intended to do. In this scenario the only feature you’d really be getting from SXA is the drag and drop functionality.


There are a small number of use cases where SXA may be a good fit as mentioned previously, but for the majority of websites using SXA will actually increase development time and reduce the quality of the end result.

Sitecore have created SXA to fill a gap in their feature set, but for a system like Sitecore which I see as more of a framework to give developers full control of what they are building, SXA while filling a need, is a step backwards and doesn’t seem to fit with the way web driven development is heading which is a more front-end/API based approach.

Clients that choose to pay for Sitecore are buying a platform with powerful features that allow developers to build websites however they chose, and I think it’s unlikely that type of customer will be looking to have a cookie-cutter style website that won’t necessarily use the latest and greatest technologies.

For Sitecore development agencies 99% of the time SXA will not be saving time and it will be very restrictive and frustrating to developers, but as mentioned there is a small number of use cases such as microsites where it could be relevant. Even in those scenarios SXA would not necessarily be the best choice because a lot of the same functionality could be created using Branch Templates and traditional Experience Editor functionality for adding components into placeholders.



Dynamic Parameters in Jenkins

Posted on by Joe in Continuous Integration, Jenkins | Leave a comment

So I came across a problem recently where I have a Jenkins job that build multiple Nuget package and pushes them to Octopus Deploy. I spent some time looking into versioning and decided I wanted my packages to be versioned using the Microsoft versioning mechanism used by MSBuild with wildcard characters in AssemblyInfo.cs.

Read more

Sitecore Webforms for Marketers Send Email with Username and Password

Posted on by Joe in Sitecore | Leave a comment

I always forgot these parameters so writing a quick blog post for easy reference. With WFFM there are parameters you can set on the Send Email Message Save Action for sending an email through an SMTP server with a username and password. The full params are:


Fix TeamCity failing to clone or pull from Git

Posted on by Joe in TeamCity | Leave a comment

I’ve had a pretty frustrating few hours today where TeamCity appeared to be very slow pulling from Git. I removed the VCS root and added it again, changed from HTTPS to SSH after which point it couldn’t even seem to pull anything from BitBucket.

After a bit of searching around I finally found my answer on stack overflow here –

By default TeamCity will only pull files <= 128mb. To change this you need to create an internal property that increases the size.

Create a new file in <Team City Data Directory>/config/ folder (c:\ProgramData\JetBrains\TeamCity\config by default) called Inside this file put the following:

Sitecore MVC Tutorial – Controller Renderings

Posted on by Joe in ASP.NET, C#, MVC, Sitecore | 1 Comment

In my previous Sitecore MVC post I showed how to create the menu for my sample website using a View Rendering. Now I’m going to turn that into a Controller Rendering in order to highlight the menu item for the current page.

Read more

Sitecore MVC Tutorial – View Renderings

Posted on by Joe in ASP.NET, C#, MVC, Sitecore | Leave a comment

This is my second Sitecore MVC post following on from Creating your first Sitecore MVC website. In this post I’ll extend what was built in that post to create a dynamic menu using a View Rendering.

Read more

Sitecore MVC Tutorial – Creating your first Sitecore MVC website

Posted on by Joe in ASP.NET, C#, MVC, Sitecore | 2 Comments

In my last post I wrote about setting up your Sitecore solution. I’m now going to extend that to creating your first Sitecore MVC website. This post will build upon the solution created in my other post using TDS and code generation. I’ll keep this post just to the basics of getting the site up an running and then will write further posts to cover the different areas of Sitecore MVC.

Read more

How to set up a Sitecore solution with TDS and Glass Mapper including automatic code generation

Posted on by Joe in ASP.NET, C#, MVC, Sitecore | 5 Comments

In this post I’m going to set up a new Sitecore solution with TDS. I’ll then enable code generation to create glass mapper compatible objects.
Read more

How to write to the Sitecore log

Posted on by Joe in ASP.NET, C#, Sitecore | 2 Comments

Sitecore uses log4net for logging. If you want to write to the log in your own code just use the following.

Sitecore.Diagnostics.Log.Error("Error message", exception);

How to set and read parameters on a static sublayout in Sitecore

Posted on by Joe in ASP.NET, C#, Sitecore | Leave a comment

In Sitecore there are two types of binding, static and dynamic. Static is when you use the Sublayout web control directly in your layout and specific the sublayout you want to use. Dynamic binding is when you use a Placeholder web control and set the sublayout that will appear in that placeholder in Sitecore via the placeholder key. When using dynamic binding you can give your sublayout a Parameters Template and set parameters in Sitecore, but how do you set parameters on a sublayout using static binding?

Read more