Integrating XBlog into a Custom Sitecore Project – Part 2

In my last blog I had talked at a high level about how XBlog’s foundation layer was implemented as a base line to a custom news solution.  In this blog, I want to explore the nuts and bolts a bit more to give a better picture about how it all came together.

 

Quickly rebuilding the templates

SHORT –  New guids for items so that a base XBlog could be installed later.

LONG –

As mentioned previously, we wanted to use all the base line templates and fields that XBlog has to offer.  This would give us a great starting point not only with effort in creating these items, but also just having minor hiccups that come with fresh template design already vetted.  But another thought while in the process occurred.  If we use the exact same installed items that make up our templates, fields, and folders… then if the client was to ever want a straight blog install from XBlog, their environment would overwrite our customized templates.  That was a big problem with an easy solution.  I pulled up my testing environment with my client development environment and started to re-create each template.  This gave us a fresh set of guids and allowed for future use of XBlog as an install.

 

Templates and inheritance

To abide by helix standards we incorporated an “_” in front of our foundation based templates.  All of our templates with fields were created in this layer and it was determined that new customization would be added here as well.

So with our new naming (As mentioned in the first part about changing all naming from blog to article) we had our main article template named “_Article”.  This template had the common fields known to XBlog as Title, Summary, Body, Categories, Tags and Authors.  We introduced our new fields at the feature level.  This was done to help keep that division between what is new and what is XBlog to help with any cherry picked features that might be pulled later.

Some of these fields were one for Region to allow for sorting by region (more or less another tagging field).  Other fields included Editors Picks and Featured to give us even more search filtering.  And finally an Article Image to present images in our listing views that should not be housed in our body field.

We inherited our Foundation layer templates to our feature level templates and fields were merged at this point.  So in the case of our Feature template “Article”, we simply inherited the foundation layer “_Article”, then introduced the new fields at this level.  We also introduced some insert options and folders at this level.

In summary around templates, XBlog was brought in to create a foundation Article.  Then through the news feature, we took this foundation level and gave it the news spin.  This was implemented throughout for all our templates.  Here is a visual of our specific scenario.

Foundation article layer:

xblog_foundation

Feature news layer

xblog_feature

Note the use of same section names of Article Info and Article Tags.  This present us a more seamless view when authors are editing items in the content editor.

 

Rendering Parameters

In XBlog base install, returned results, and filtering options are done in configuration files.  We decided to up the game a little in our solution to bring more customization to the authors hands.  Some of the fields we introduced were results returned, sorting by date range, tag / category inclusion and exclusion, and manually inclusion of specific articles.  With this in place we started to build our search manager to implement proper search results to our views and controllers.

 

In Summary

Overall it was a fun experiment to see this in action.  The one thing that shined the most was the fact that Helix architecture has presented us with a base standard to allow us to do this.  With the previous implementation of XBlog I would have never though of doing something like this.  XBlog was developed initially as a stand along tool and before Helix.  But with the new implementation it was much more obvious that we had a fine tuned cog to fit into our machine.  Not all was used, but I think we ended up gaining a lot of value in the base implementation.  I look forward to giving this a try in another project, and I also look forward to introducing new concepts that presented themselves through this journey into XBlog.  Maybe the next one will integrate with JSS.  Time will tell!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s