Using Ignition

It's easy to get started with Ignition. If you need help setting up your solution, see the Getting Started page.

Working with Ignition

Projects

Per the guidelines set out by Sitecore Helix (http://helix.sitecore.net/), there are three areas that we use for projects:

1. Foundation - Class libraries and logic that is stable and referenced by other projects. For the most part, this is just the Ignition.Foundation.Core and Ignition.Foundation.CompositionRoot, but you can add your own class libraries to this area. Just be sure to include the IgnitionAutomapAttribute to your assemblyinfo.cs file so that your code gets included in the IoC wireup, etc. This segment should represent code that is the most stable in your solution, based on the Stable Dependency Principle.
2. Feature - These are Class Libraries and Web Projects that comprise the actual features of your application. These are the things that are not site specific, and often correspond to renderings or families of renderings. These can reference Foundation modules, but should not reference other things in the Feature level and nothing in the Project segment. At most, if you need a shared project, make that the ONLY project in the Feature level that is referenced by others.
3. Project - This is the segment that you use to define your Site, your primary site-related configurations and things that are shared across projects such as Header and Footer, etc.

Implementation

Working with Features is the simplest starting point. We recommend that you create a Feature for every set of related functionality in your site. For example, you might create a project for your Hero components, and another for your Call To Action components. One might hold integrations, etc. The important thing is that you are as granular as is practical and as you are comfortable. We have included scripts and configurations that make deploying your code simple, even if you have many projects, so strike a balance and get coding!

Since you should be keeping things modular, we also recommend that you only have one controller per project. If you find yourself needing another controller you should probably be making another project, but that's ultimately up to you. We don't try to force you into anything.

Key Components

There are essentially 4 main project components you need to consider:

1. The App_Config items
2. Controllers
3. ViewModels
4. Views

App_Config

Because every project should be able to work in isolation, every project should have its own configurations. We use a folder structure that isolates configurations, such as /App_Config/Include/Site/Ignition.Feature.Hero so that any configs can follow the same convention and we can avoid collisions in naming. We also use the same naming for the config files, such as Ignition.Feature.Hero.Unicorn or Ignition.Feature.Hero.

Break these out as you see fit. If you ARE using Unicorn, you'll see the Unicorn configuration file included in the project template. If you've used the optional configuration steps, you're going to just need to make sure the paths are setup in the config to match your component and you're all set. The serialization should go right through the symbolic links and things should work without further configuration.

Controllers

As mentioned before, you should generally have one controller per project. These should inherit from IgnitionController. If you do this, then you can take advantage of our View<>() overloads. There are two options for returning a view.

public ActionResult MyAction() => View<MyIgnitionViewModel>();

or

public ActionResult MyAction() => View<MyIgnitionViewModel>(a=>{/*Some work in here*/);

Version 1 assumes you're using a ViewModel that has been bound directly to your Sitecore item and requires no more configuration or setup. This will prepare your ViewModel and return it to the view.

Version 2 is for when you DO have more configuration that you need to pass in to be done for your ViewModel. This takes anything of type Action, so you can pass in a method name, a Lambda, an anonymous method, etc. This will then get applied to your ViewModel and the ViewModel will get returned. This allows you to make simple changes with almost no effort or allows you to encapsulate logic to be reused as flexibly as you decide.

The result is extremely clean and concise Controller Actions. Remember that your Action name determines the view that's used automatically. We highly suggest you take advantage of this for using Compatible Renderings, etc.

ViewModels

Currently we only support Glass Mapper, but one of our next feature sets will include the ability to use Fortis or whatever ORM you choose! For now, your ViewModels should inherit from IgnitionViewModel (Sense a theme yet?). Then, you can create your POCO model for your View. If you're using Attribute mapping, then decorate your classes with the appropriate attributes (see http://glass.lu for details on configuring Glass). If you're using Fluent Mapping, then you just need to create your mapper files and make sure they're in an assembly that has the IgnitionAutomapAttribute on it. Ignition will automatically pick it up and run your mappers at Runtime. Remember that Glass may not like it if you mixa and match mapping, so follow any instructions or guidelines from Glass Mapper on this. We have used both, but settled back on attribute mapping for most of our projects.

Other than that, your ViewModels are just that simple.

Views

Views are also simple. Just set your model type to match your ViewModel, such as:

@model Ignition.Foundation.Core.Models.BaseModels.Page

This done, the rest is your usual Razor and Glass functionality. We have included a few additional helpers here, but those will be addressed at another point.

One feature that will come in handy early on however, is Experience Editor Views. We take pride in creating a great editing experience for our users, so we often create views that add extra instructions, tips, etc to make the editing experience better. This is trivial to do with Ignition! just add _EE to the end of any View name! Our View Resolver will check to see if the user is in Edit Mode, and if it is it checks to see if the _EE version of the file exists. If it does, it servers that View with no intervention on your part.

So if you have:

MyAccordion.cshtml

MyAccordion_EE.cshtml

Ignition will serve the right one up without issue! This is really all that you need to do in code to create a component. Now, simply create the rendering in Sitecore (Controller Renderings always!) and put in your Controller name and Action name. Voila! You have a working component. *

• There's lots more to do, such as adding thumbnails, setting up placeholders, and all that, but nothing more than you'd already be doing.