Development for Ignition 3 has started!

We are working on the next iteration of Ignition, now to be called Ignition.Framework. There are going to be a number of fundamental changes to the core architecture, including even more in the way of abstractions and dependency management, more flexibility than was already there, and a reduction in the required dependencies to the toolset.

Some changes to note:

1. Instead of using the concept of Foundation.Business Feature>Presentation Feature>Project, we are moving things that are part of the framework to an even lower core Framework layer. Then, supporting class libraries can exist at Foundation, and the clear line of Stable Dependencies is maintained. It will also be marked by more strict dependency management between these layers and clear abstractions between platforms. This will drive the ability for Ignition to be able to be used for both Sitecore, Episerver, Sitefinity, SharePoint, or any other dev platform while maintaining consistent patterns and libraries.
2. We are stepping away from native support for Glass Mapper, thus removing a dependency on Glass and Castle. Instead, we are going to be providing a simple wrapper ORM out of the box and allowing for providers to be installed/used to wire op models. This means that any of the available ORMs could potentially be used including Glass, Fortis, Synthesis, etc.
3. Ignition will include default support for things like Sxa, Logging, Caching, Search, App Insights, etc. out of the box. We also plan to have a general set of components that can be used to drive content components for clients.
4. We are also looking at expanding our clientside support, integrating common UI toolsets like Typescript, Knockout, Angular, React, Webkit, and many more.

If you are interested in contributing or have questions, you can reach the ignition team at: 596a5747.Perficient.onmicrosoft.com@amer.teams.ms. Additionally, the new repository is located here: https://github.com/sitecoreignition/Ignition.Framework.

Thanks!

Greetings true believers!
If you’ve been following on Twitter and Slack, you’ve already seen that we’ve released a major revamp of Ignition. The getting-started guide can be found here: https://github.com/sitecoreignition/Ignition.Foundation/wiki
Here’s a companion video going over getting started with the new framework:

Some new features unveiled in 2.o include…

• A full restructure of our project structure with a focus on minimizing artifacts and more closely aligning our project structure with Helix.
• Massive simplification in setup! Now, everything is done with Nuget and your own projects!
• Simplification of the process of building components and simplified the way we build templates!
• Code is far easier to deploy and maintain, and every single project is self-contained!
• A clear, linear dependency chain has been changed to NO DEPENDENCIES! Your code will depend on 3rd party dll’s only, your projects are independent.

Check us out, and look for more training videos and documentation soon.

Last month in some downtime between great sessions at the 2016 Sitecore Symposium in New Orleans, I got the pleasure of meeting Derek Dysart. Derek is the creator of the Core Sampler Podcast, and is racking up an impressive collection of interviews. After talking for a bit, we decided that an interview about Ignition was in order – especially since the announcement about Helix had become such a big deal at the event.  While Ignition has existed as an open source development accelerator for a while now, a lot of people still looked at Habitat as the “official” development accelerator for Sitecore. The clarification that Helix represented the principles of good development for Sitecore and that Habitat represented an example solution, not a development platform, meant that there is a vacuum in the space that Ignition is ideal to fill.
Listen to Derek and I talk Ignition, Sitecore, and other topics in his podcast, and be sure to subscribe and listen to the other great interviews as well!
Find the interview here: http://coresampler.fm/7
Remember, you can always find me on:
Twitter: @SitecoreJon, @JonUpchurch, @Ignition_Sc
Slack: @JonUpchurch
LinkedIn: https://www.linkedin.com/in/jonupchurch

Hi all! Our team is looking forward to getting to meet and talk with everyone at the Symposium on 9/15 and 9/16! In the spirit of this, we wanted to answer some FAQ’s, one each day as we approach the event. A different member of the team will post something each day, so be sure to check them all out!
Also, remember to find us at the MVP Summit and at the event itself, and stop by our booth in the Partner Pavilion Thursday and Friday, we’re at #217!

Remember that George and Tim will be speaking on Friday!
Sitecore DevOps Goodness on Azure: Visual Studio Team Services
Speakers: George Chang and Tim McCarthy
Friday, September 16, 2016
11:45 a.m. – 12:30 p.m.
We’re giving away some cool stuff and also holding a raffle, so stop by our booth and find out more! Anyhow, here’s the first entry in our Countdown to Ignition!
Question:
What Is Ignition?
Answer:
Ignition is an open source development accelerator built by members of the Perficient team and released to the public free of charge under the MIT license. You can find it on GitHub, at https://github.com/sitecoreignition/SitecoreIgnition, and the documentation here: http://sitecoreignition.readthedocs.io/en/master/.
Ignition started simply as “how we do things” and the collective wisdom of what we’ve learned over the years of doing Sitecore implementations. Over time, it became more sophisticated and we started formalizing it, and it has evolved and morphed several times over the years. It’s based on our passion for using good SOLID development practices as well as strongly supporting all of the features of Sitecore that were getting hamstrung by practices that weren’t designed to enable them.
The end result is what we have now. A lean, mean, Sitecore machine! We’re really proud of what we’ve put together and we would love to talk more about Ignition with you. Tweet to us at any of our personal accounts, or mention @ignition_sc and we’ll all see it, so find us there and we’ll talk!

Just a reminder that the team from Perficient that created Ignition will all be at the Sitecore Symposium coming up next week! Find 3 of us at the Sitecore MVP summit and all of us at the event itself! Be sure to find @SitecoreGeorge at his talk (along with Tim McCarthy) on Friday at 11:45am! Find us at the our booth, #217! Want to plan a time to chat? Tweet one of us via @ignition_sc!  Look for us wearing the red Ignition T-Shirts!
We hope to see you there and look forward to a great event!

This is an internal training webinar that ran on the week of 6/13/2016. It included members of our Sitecore team both in Atlanta and elsewhere, and included people who had used the framework extensively as well as total newcomers.
Sitecore Ignition is an Open Source Development Accelerator and set of best practices for rapidly developing Sitecore sites. It enables easy support of the Experience Editor, and all of the marketing automation features that are so important to a modern website such as Personalization and A/B/N testing.
Check out the repository here: https://github.com/sitecoreignition/SitecoreIgnition
Check out the (still work in progress) GitBook here: http://sitecoreignition.readthedocs.io/en/master/
Ignition is sponsored and developed by Perficient under the MIT License
As always find us on Twitter:
@ignition_sc – The Ignition Team
@SitecoreJon – Jon Upchurch, Lead Architect
@SiteCorey – Corey Smith, Architect, Developer
@SitecoreGeorge – George Chang – Developer, PM
@SitecoreChris – Chris Williams – Evangelist and Social Media Manager

This is a quick getting-started video for people wanting to clone and start working with Sitecore Ignition.
Github location: https://github.com/sitecoreignition/SitecoreIgnition
Find us on #ignition on the Sitecore Community Slack
On Twitter:
@ignition_sc
@sitecorejon
@sitecorey
@sitecoregeorge
@sitecorechris
Or ask a question or comment below!

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

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!

public static IEnumerable<TemplateItem> GetAllMasters(this Item item)
{
    var nodes = new Stack<TemplateItem>(new[] { item.Template });
    while (nodes.Any())
    {
        var node = nodes.Pop();
        yield return node;
        foreach (var n in node.BaseTemplates) nodes.Push(n);
    }
}

So instead of using recursion, which can in some extreme cases cause a Stack Overflow (unlikely in this circumstance but I like this solution better), the code uses some fancy C# footwork and effectively flattens the tree into one stack frame. The magic of yield return node; remembers where we loft off after each iteration (greatly simplified – see http://stackoverflow.com/questions/39476/what-is-the-yield-keyword-used-for-in-c for a better explanation) and continues on.
Note: I don’t recommend this approach for all such situations. It’s not a magic bullet for large trees. Unless your inheritance is massive though, this should be pretty low impact. I would definitely NOT use this to traverse content items! We’re just looking at base templates here!
UPDATE [06/01/2016]
@cassidydotdk brought to my attention the fact that there is an API solution for this that’s often overlooked:

var t = TemplateManager.GetTemplate(actionItem);
t.GetBaseTemplates();

Reflection shows that this DOES give all base templates, not just the immediate ones. So ultimately using the TemplateManager is a better approach for this case, using yield return for code like this is still a powerful tool for simplifying and optimizing your code!
If you have any questions, you can always tweet it to me: @SitecoreJon or @JonUpchurch or leave a comment below!

Jon Upchurch

• Part 2: The Fantastic Voyage! Getting around in Sitecore Powershell and the Anatomy of an Item
• Part 3: Little House on the Query: How to build useful statements in Sitecore Powershell Extensions
• Part 4: By the PowerShell of Grayskull! A primer on PowerShell Commands, Commandlets, and other Tools
• Part 5: ISE, ISE, Baby!: Using the Sitecore PowerShell Extensions Integrated Script Editor
• More TBD

If you have any special requests, you can always tweet it to me: @SitecoreJon or @JonUpchurch or leave a comment below!