Sitecore Developers: Start! Your! Ignition!

So, besides an excuse to use the old reliable “Start your engines!” trope, what is Ignition?

Ignition is an open source development accelerator designed by the team at Perficient and released to the Sitecore community as a quick-start tool for beginning Sitecore projects. It has two primary components: the Sitecore Information Architecture piece and the .NET MVC solution. All along the way, the team has set things up so that we’re using best practices for Sitecore development as well as good development practices and patterns. We embrace SOLID, and our code is designed to enable you, the consumer, to quickly extend, add onto, and test your own code.

The Sitecore Piece

Back in 2014, I presented at the Sitecore North American Symposium, a session called Get with the Experience! Information Architecting to unlock the full potential of the Experience Editor. This was where the framework really started to take shape, although it’s gone through several rebirths in code. The principles of the Sitecore Ignition Architecture are as follows:

1. There are three kinds of content in Sitecore: pure content, structured data content, and metadata.
2. The idea of the Page is outmoded in Sitecore. Pure content should be separate from a page and should be reusable. By observing the Single Responsibility Principle, a page should only contain properties that relate to a page. Examples would be information about Navigation, Metadata, Taxonomy, SEO, etc. It should not include content. A Page should be nothing more than an addressable item that provides some standard presentation into which content can be installed. Content should be atomic, and should be discrete items in Sitecore.
3. Structured data items, such as product data, personnel data, catalog info, etc. are first and foremost data and exist purely for that purpose. These items can have their own presentation and be displayed on their own because these items exist on their own. You’re not so much presenting a page as you are rendering the data itself to the browser.
4. Metadata is any item in Sitecore that supports other content and/or data. This can take the form of settings, tags, shared content, etc.
5. We architect with an Experience Editor First mentality. We do our best to keep things just as intuitive to Content Editor users, but we feel that the Experience Editor is the direction that Sitecore is really pushing and that it provides the best authoring and marketing experience when done correctly. We structure our pages via nested renderings, and make heavy use of Placeholder Settings and such to improve the editing experience.
6. We view all sites as localizable, multi-tenant-ready platforms. We encourage and enable practices that support this goal. Every site should support A/B/N testing, Personalization, and Analytics. Renderings and data should be reusable across platforms including FXM, PXM, ECM.
7. We follow the idea that content is either shared (global) or local. Local content is stored with the page in a Local Assets folder. We make use of Datasource Location and Datasource Template on our Renderings to make it easy for Content Authors in the Experience Editor to point renderings at the desired content.

The Code Piece

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

The code has undergone several rebuilds and refactors since it was initially started back in 2013. The current incarnation has been completely revamped from the beginning of 2016. We embrace the principles of SOLID very firmly. Our dependency graph is a clean line from the bottom of the solution to the top. We heavily utilize patterns like Dependency Injection, Factory, Strategy, Decorator, Builder, and more. Fully supporting the MVC platform, wherever possible we integrate with the .NET MVC platform to solve problems. Here are some of our driving principles for our code implementation:

1. Where it’s convenient and sensible, we automate as much mundane code as possible. We don’t create automation that gets in the way; rather our driving goal is to reduce the moving pieces a developer or architect needs to worry about. We do things like automatic model binding, automatic Experience Editor views with the goal of expediting component creation.
2. We aim to make basic day to day development simple enough that there is a very fast learning curve for even Junior Developers or Interns as well as seasoned developers that are unfamiliar with Sitecore. This provides more flexibility for staffing on teams that are cross-functional. Also, Front-End Developers should be empowered to easily work within Visual Studio as it should be very easy to find the files and components they need.
3. Instead of using one of the more traditional folder structures for MVC, such as separate Model, View, Controller, ViewModel folders or using some variation on Areas, we use a component model. Each component has one controller, and supports as many views as is appropriate for a given component. All files relating to the component that are unique to the component are stored in the same place. No longer is there a need to scroll and scroll for larger solutions to find the Model folder, compare it to the View, etc.
4. We keep our controllers very thin. With the aim of keeping things very simple as well as promoting code reuse, we use an Agent which is in effect a ViewModel Factory. These agents encapsulate the business logic for a component and provide a fully populated ViewModel as a result. Controllers only contain their Action methods which are typically one line of code. Agents are highly reusable, and it enables very easy use of Compatible Renderings within Sitecore.
5. We make use of extensive template inheritance in Sitecore, and model those templates using Glass Mapper as Interface models. Creating Models from templates in Sitecore is a trivial task as all that needs to be done is to implement the interfaces that correspond to the templates you inherit in Sitecore.
6. We utilize and support other open source projects in the Sitecore community. We make use of the Glass Sitecore Mapper, Sitecore Powershell Extensions, Unicorn, and more. Where possible we allow developers to choose their preference of tool and we develop the framework in a way that enables things to be swapped out as much as possible.
7. We try not to dictate how you code. We present you with as many best practices as possible, and we try to empower you to use them effectively, but you can take or leave any of them. We feel that regardless of what you keep and what you discard that we can still bring value to your solutions by way of a clean, consistent site and code structure that is extensible.
8. We support independently developed modules. Simply by referencing our Core and Data libraries (soon to be available on NuGet), you can create modules that can make use of the foundation that Ignition provides, saving time and effort even for separate projects and functionality. Separate teams can add on to a single site by working in a modular fashion this way.

There is a lot more to cover, but these are the high points. We will be releasing a lot of information and documentation to come as well as videos and more. As of this moment, the code is now available at GitHub. This is the 0.98 beta release. We plan for an 0.99 beta release on July 31, and a 1.0 release currently on August 30.

• Grab our code on GitHub at https://github.com/sitecoreignition/SitecoreIgnition.
• Join us on the Sitecore Community Slack in #ignition.
• Follow us on Twitter at @ignition_sc.

The Ignition Team:

• Solution Architect and Lead Developer: Jon Upchurch
• Architect and Developer: Corey Smith
• Developer and PM: George Chang
• Platform Evangelist: Chris Williams

Special thanks to Perficient, Inc. for their support and for letting us take this IP into the Open Source community. Ignition is managed by Jon Upchurch and Perficient under the MIT License. We encourage you to pull the code down and review it to get a feel for what we’re offering. Don’t mind our mess however, as we’re still cleaning things up, adding features, and polishing things up. Thanks, and happy coding!