Introduction
We often get asked whether Magnolia’s Standard Templating Kit is the best way to go when planning out a new Magnolia project.
This is a perfectly reasonable question: Those who have a little knowledge about Magnolia will know that the STK is an optional bolt-on module and, therefore one would naturally (and correctly) assume that perfectly good websites can be developed without it.
Furthermore, at first glance the STK can appear complex and unwieldy; which can lead techies already familiar with the non-STK approaches to question whether it’s worthwhile.
In this article we discuss some of the pros and cons associated with the STK to help you decide whether it fits the requirements of your Magnolia project.
First, some background
Prior to version 4, there was one approach to building websites that Magnolia supported out-of-the-box. Templates (created using either Freemarker or JSP) and dialogs were developed for all of the components and pages that make up the site. Any rich functionality – such as auto-generated navigation menus, links to related pages, and specialisation of content and layout for different devices and channels – had to be built manually. Whilst Magnolia – and the underlying JCR technology that we’re big fans of at Priocept – is intuitive and flexible, this approach required a lot of manual development work and configuration. Development of features that are common across many websites would have to be repeated for each and every website built or rely on proprietary libraries of components created by Magnolia development houses – neither of which is ideal.
Magnolia introduced the STK to provide standardised reusable components for these common website features and reduce the boilerplate development required when building a new website. These components are fully customisable and extensible – so any website user experience or look and feel can be incorporated and new STK components can easily be created based on any HTML/CSS/Javascript your designers can concoct. Better still, the STK also introduced a standard mechanism for encapsulating and managing website themes (look-and-feel) and enforcing clean separation of concerns between presentation and business logic. In more recent releases the STK has been enhanced further to provide standardised support for multiple channels (mobile, tablet, desktop or anything else for that matter) and multiple websites that can freely share templates, themes and content. In short, the STK is much more than a set of reusable components; the conventions and features it brings effectively transforms Magnolia from being a flexible CMS programming framework into a powerful, fully-featured CMS platform.
Should I use the STK for my project?
Most of the websites out there that have a content management requirement consist of many pages that reuse templates and components across the website to some degree. For any of these use cases, even for an STK novice, the benefits of the STK’s convention-over-configuration approach and library of reusable components is likely to outweigh the slightly steeper learning curve required to get started. Where the project has a requirement for multi-site support or multi-channel specialisation the utilising the STK becomes a no brainer.
On the other hand, for smaller or less structured website implementations where multi-channel, multi-site, and all the other good stuff just isn’t relevant – perhaps for heavily-graphical, tactical, campaign or brochureware sites – the STK may well be overkill and unnecessary.
Magnolia provide some useful and balanced arguments for and against the STK in their tech brief comparing the STK with ‘custom templating frameworks’ (proprietary libraries created by Magnolia development houses). It’s impossible to form an objective comparison here without a specific custom framework in mind, and in any case, you’re unlikely to want to build a custom framework unless you already have one or you already know that the STK won’t meet your needs.
The STK is also the official best practice Magnolia way of doing things, meaning that it is well supported and understood by Magnolia and its partner network. Any custom alternatives are not standard and therefore likely to be more costly to maintain and extend.
Conclusion
If content management is enough of a concern for your website project that you’re looking to build it in a CMS, using the STK is likely to save you time and add value. For sure there will be cases where it makes more sense to ‘go custom’, but in our experience these are the exception rather than the rule.