pipeline

I’m still working on the third post about configuration, I have to admit that I’ve lost a bit of drive on it. So I thought I’d change gears a little and share some information I found around rendering parameters and personalisation. For anyone who doesn’t know what rendering parameters are, I’d suggest this article by Vasiliy Fomichev, which explains them nicely.

We use rendering parameters a fair bit at Codehouse in order to allow editors to control the more presentation-oriented settings without editors needing to duplicate or clone their datasource items. For example, a call-to-action on one page might have the same content on two pages, but need a different background colour in order to fit the rest of the page. Developers often forget that the DRY principle can be applied to content too: give the editors the tools so that they don’t have to duplicate content where they don’t need to.

Recently, though, I came across a specific situation where they seemed to be a little broken.

Pipelines are a very useful feature in Sitecore, one that I make use of a great deal.Â I see a great many Sitecore website solutions that create their own processors to add to the existing pipelines (or which override existing pipeline processors), but I very rarely see solutions that have created their own pipelines. Usually I only see it in modules.Â I think that developers might be missing a trick, as there are a great many things that you can do with a simple pipeline and it provides easy extensibility throughout the project lifetime.

Pipelines, to my mind, should be used to solve a problem where you have (or will have) discrete pieces of logic that may be added to at any time.Â Often but not always, these operations occur in a particular order.Â There will usually also be one or more results of the pipeline that all of the operations will contribute towardÂ in some way. Continue reading Custom Sitecore Pipelines

Tag: pipeline

When Personalisation Breaks Rendering Parameters

Custom Sitecore Pipelines