Sitecore 7 Search – Searching By Inherited Template

After reading a great article this article from a former colleague (Richard Seal – Lead Sitecore Architect @ LightMaker US), I remembered that I to had solved this issue slightly differently some 12 – 18 months back using (originally Lucinq and then) the stock Sitecore 7 search. Non-the less, it fits a lot of what I have been saying in my Don’t Fight The Framework series – in particular – Please Don’t Base Your Code on Exact Templates, so I thought I would cover it again for those who don’t already know.

The problem is that Sitecore doesn’t ( / didn’t) provide a default way of searching for item’s based on their template inheritance hierarchy which means that normally in the out of the box solution you have to search on template (breaking everything I have said in my previous article above). This can be particularly useful for example if we wanted to return ‘All News Articles’ in our Site but you actually have implementations of ‘Press Release News Article’, ‘Industry News Article’ and ‘Budget News Article’

This article describes how I have achieved similar to Richard’s solution has done with Fortis (sorry Richard – I am a Glass fan πŸ˜‰ ) with the stock Sitecore 7 Search.

I do have to note that I believe Sitecore (at the time I wrote this code originally) provided a similar field in it’s default configuration, but when I wrote this, it was broken (from memory, it only returned the first three levels or something).

Continue reading

Life Through A Lens – Component Parts

So – following on the first part in my series on how I have been using Glass Mapper for Sitecore in the real world.

Glass Mapper
Just a couple of quick notes on Glass Mapper, the Glass Mapper developers have done a great job of writing tutorials on most aspects of Glass, and I expect with recent developments on the project, this will only get better, so please check them out at www.glass.lu.

Firstly – Whilst Glass supports using classes for mapping, I almost always use interfaces to represent my model objects, this is due to their multiple inheritance structure and it allowing better representation of the templates on which they are to be based.

Secondly – I almost always use the fluent configuration API – however… I almost always choose to configure this using my Glass Mapper Maps project (described below)

Finally – I like to turn the Automapping feature off for the most part, this is probably because I am a control freak :D.

Glass Mapper Maps
I have been in many discussions with the developers at Glass and I am hoping that this is one of the improvements that they will consider rolling into the product as a whole. Whether this is the case or not – here is what they are and how I use them.

Glass Mapper Maps are a neat solution to isolating the domain objects for use with Glass Mapper. Generally in practice, I start off by creating 2 projects in Visual Studio, these are:

  • xxx.Model
  • xxx.Model.Mapping

In xxx.Model, I would add my regular domain objects – so, ISitecoreItem, ITitleAndIntro : ISitecoreItem, IMetaData : ISitecoreItem

Agnostic IoC
Agnostic IoC is an abstraction layer to allow modules to utilise an unknown final IoC framework, this means that I can perform my registrations and resolves against Agnostic IoC and it in turn performs them against the container of choice. It does this by means of Nuget Packages.

With Glass Mapper, this means that I can use Glass with multiple clients complying with their restrictions of IoC container – be it Autofac, Unity, NInject, StructureMap or pretty much anything else. It also has the upshot of including it in the project, so any module development I choose can also be portable.

So now when I install Glass I need at least the following Nuget Packages

  • Glass.Mapper
  • Glass.Mapper.Sc
  • Agnostic.IoC

Wherever you actually want to perform the initialisation for Glass you also need to include the ‘Translator’ package, so for example – Agnostic.IoC.Autofac. You do not need this in any projects that are not performing the initialisation.

For a more in depth description, please visit Agnostic IoC

Conclusion

In the next post I will be looking at getting Glass Mapper up and running in your solution fully.

May I also draw your attention to the fact that the Glass Development team will shortly be offering training and consultancy on their products which I would highly recommend if you get the opportunity.

Life Through a Lens – My Glass Mapper With Sitecore

So you are here because you are either using Glass Mapper or want to know more on how to, particularly on the Sitecore platform. This series will be attempting to relate the use of Glass Mapper to real-world scenario’s which I have encountered, problems I have solved, approaches and / or idea’s on how you could use Glass Mapper in your own Sitecore implementations.

This is the first post in a series that I intend to run looking specifically at my experience of Glass Mapper, starting with what it is, how I use it and some common issues and hopefully a bit on TDD with Glass Mapper on the Sitecore Platform.

I will focus more on the MVC implementation during the course of the series, but Glass Mapper is equally potent and simple to implement when using purely Webforms (though I feel it’s testing benefits are more limited).

I would not knock other ORMs in this space and I hope not to compare Glass to it’s alternatives during the course of this series.

Continue reading

Web Forms For Marketer MVC – Blank Sitecore Tree When Displaying FormID in Presentation Details

So – a lovely short post this one. It seems there is a slight issue in templates in the first generation MVC release of Sitecore Web Forms For Marketers (2.4)

After installing WFFM for MVC 2.4, I noticed that the FormID rendering parameter on the MVC Form rendering is incorrectly pointing at the Sitecore Tree root. I was expecting this to point at a forms folder. I don’t know if this behaviour is displayed on other versions of Sitecore – I am on 7.2 update 1 at present.

On further investigation, it appears that there is a typo in the Data Source in the rendering parameters template declaration. To fix it on mine I simply needed to follow these steps.

  1. Navigate to the template => /sitecore/templates/Web Forms for Marketers/Renderings/Interpreter Properties (ID – {2816D841-7573-4080-9418-80BAC327A539})
  2. The data source was (on my instance at least) set to: Source={D81AC026-07B6-4929-9588-40ACBDC56435}
  3. Simply Change it to: DataSource={D81AC026-07B6-4929-9588-40ACBDC56435} or {D81AC026-07B6-4929-9588-40ACBDC56435}

(On my machine at least) VOILA, problem solved πŸ˜€

Glad it’s not just me that releases code with typo’s, it happens to the best of us πŸ˜‰

Hope this helps.

Don’t Fight The Framework – Location, Location, Location

Ok, so here in the UK it is a great show on property development, but for the world of Sitecore I actually mean this (It will be common sense to some, and food for thought with others). This post is more likely to help you if you are new to Sitecore.

References to items in code

There are a number of fundamental issues I have encountered over my time with various projects, and this has been mirrored by reviews on my own / others work by Sitecore themselves. I find it an increasing source of frustration to find things like:

var myItem = Sitecore.Context.Database.GetItem(new ID("{some-id}"));

This in itself isn’t the greatest sin in the world, but certainly when working on code that was not originally your own it often makes it trickier to find instances in your code. At least in this case, if the user moves the item, then the code still works. In the following case however (which I see WAY too often for my liking), move it, you lose it.

var myItem = Sitecore.Context.Database.GetItem("/sitecore/content/somepathorother");

So, simply put – add your references to a central config, be it class / xml (please don’t) or whatever, that you can reference throughout your site. I personally like the convention of SubClasses to achieve this, such as:

public class SitecoreIds
{
   public class TemplateIds
   {
      public static ID MyTemplateId
      {
         get { return new ID("my id"); }
      }
   }

   public class Paths
   {
      public static string MyPath
      {
         get { return "/sitecore/content/mypath"; } // returning as a static property means assemblies that reference this don't 'bake it in' - personal
      }
   }
}

I still prefer to store IDs rather than Guids / String representations as I find in my experience the api more often requires ID than the guids or strings, it’s no doubt a personal thing.

Template Location
So, we have covered an approach to referencing your items, what about where they actually live.

This of course is subjective, but in my opinion I like to think of a strategy like this:

  • Sitecore has default locations for a reason – User Defined beneath Templates
  • For reusable modules development, Sitecore also has folders dedicated to just such a purpose (look under system for one example)

Rendering / Sublayout location

This is a slightly moot point, but I find it quite frustrating when I am faced with solutions where developers have not isolated the renderings into the site that they belong, this I feel often stems from the belief that either.

a) Everything will be ultimately re-usable (kudos if you can manage it)
or b) They never intended to have more than one site.

Sitecore is a multi-site platform, look up the Billy Crystal style definition of assume πŸ˜€

A simple folder structure maybe grouping sitea, siteb and shared will often suffice and make life easier for us.

I personally also find it useful to mimic the structure of the Renderings in the Sitecore database, its a personal thing but I feel it helps me stay sane.

Conclusion

It’s great that you know where your code is, for everybody else it is a learning exercise that can be made so much easier if you follow convention, it also helps a tonne in upgrade.

Web Form for Marketers MVC – Hijacked my pipeline

So finally got around to installing Sitecore Web Forms For Marketers and bang, installation process was relatively straightforward, but immediately I got a YSOD complaining that the controller could not be instantiated. In this solution we are using an IoC container to return out the controller renderings, and as such have an entry in the pipeline. WFFM MVC also ships with an entry in this pipeline that patches in Sitecore.Forms.Mvc.Pipelines.GetFormControllerRenderer before the original GetControllerRenderer that ships with Sitecore. Unfortunately in our case, not only are we are patching in our own GetControllerRenderer, but as it’s now before our pipeline entry and in inherits and fires the entry we are replaceing Sitecore have actually stopped the original controller renderer from firing.

Pipeline entries are the normal Sitecore development approach, and in true Don’t Fight The Framework style (as Sitecore have themselves) I have embraced Sitecore’s default implementation of GetController Renderer and extended it to do something subtly different, unfortunately, in this instance, it seems that Sitecore have patched in an entry that prevents future entries from firing. Below is an initial solution (that seems to work) in order to allow your additional pipeline entries to fire.

Continue reading