The Sitecore Developer Network (SDN) forum thread linked in
the Resources section at the end of this page prompted me to write this blog
post that attempts to describe some of the issues that developers should
consider when deciding whether to use rendering parameters or data source items
in the Sitecore ASP.NET web Content Management System (CMS).
You can pass parameters any number of parameters to each of your renderings. One of these parameters is a data source item, which is just like any other item in Sitecore. You can use the data source item to pass additional parameters to the rendering. If you do not pass a data source item to a rendering, the context item is the default data source item for that rendering.
Sitecore 8 can store layout details in both versioned (__Final Renderings) and shared (__Renderings) fields in both standard values and individual items. Shared values do not provide publishing controls and preclude workflow (a publishing operation could include changes to shared fields at any time). In some cases, such as the depth of a navigational component, a shared value may be sufficient for all versions in all languages. In other cases, rendering parameters could raise technical complexities for versioning and otherwise varying rendering parameters, which could in turn present challenges and/or limitations for personalization, testing, and other logic and analysis.
Because you define your own data templates for data source items, you can indicate which (if any) field values should be shared or unversioned. Sitecore versions and supports translation of values in all fields by default; but only supports versioning and translation of rendering parameters when you use versioned layout details. Data source items support and simplify translation and versioning of all page components, and support for personalization and testing as well. Data source items can include features such as background images and color selection.
If you use a data source item for a rendering, you may need to remember to publish changes to that data source item when you publish the item that contains the rendering that uses that data source item. This also means that you can lock and workflow data source items separately from content items, which can have advantages.
You can pass any number of rendering parameters to any rendering (in fact, the data source item is a type of parameter). To optimize usability, you should implement a rendering parameters data template. In other words, whether you use rendering parameters or a data source item for the rendering (which would generally have its own data template), you will most likely want to implement a data template for storing the values passed to the rendering.
While you can use rendering parameters templates to improve the usability of rendering parameters, you cannot use the Experience Editor to edit those values inline. Instead, CMS users need to open a specific dialog for rendering parameters, which may not be the most intuitive operation.
When you change a rendering parameter in the Experience Editor, Sitecore updates the item and reloads the page in the browser. CMS users choose can make changes to multiple field values in a data source item before deciding whether to save those changes. You may want to provide inline editing features for fields of data source items that would not otherwise provide editing controls, or links to edit items to which the site might not otherwise link. One of the various possible user experiences may feel more natural for CMS users depending on the operation.
One additional concern is how you access parameters. For data source items, you access them like any other field value; you just get them from the data source item rather than from the context item. Data source items raise a small complexity for sublayouts in Web Forms (hence SublayoutParameterHelper). Without a similar utility, it can feel a little clunky to access rendering parameters in MVC.
If you have any additional considerations for determining whether to use rendering parameters or data source items, please comment on this blog post.
All good points John. Also worth noting the Edit Component Properties pop up in Experience Editor, allows people to turn on/off caching. Probably not something you want your editors to see or be able to change. Unfortunately there is no way of using security to disable that (as the code retrieving the fields runs inside a SecurityDisabler). Also, since 7.0 up1 it is possible to get the datasource in a sublayout using Attributes["sc_datasource"] bringing it in line with Attributes["sc_parameters"] (which has always worked). When using sublayouts, consider creating a base class (see www.dropbox.com/.../BaseUserControl.cs for inspiration). It saves a lot of hassle.
Learning the hard way the difference between Rendering Parameters and Datasource Items when it comes to Multivariate Testing. Are there any tips/tricks to A/B testing a Rendering Parameter/Component Property? Or is the only solution to change the template structure and associated code to use Datasource Items instead? We want to A/B test colors of text on a component but the color is a component property so it is being applied to both A and B version of the component we want to test.
@Jabare Sorry, I cannot think of anything that would help, although I assume something might be possible with custom code. I would use the data source item if possible.
A very informative post! I was able to implement rendering parameters with much ease. I have documented the same here - www.kewlcodes.com/.../Rendering-parameters-in-Sitecore-MVC-and-its-implementation-with-an-example
@Jabare if you wanted a rendering parameter value to be A/B testable you could write the control in a way that by default it first looks for a rendering parameter value, then (if specified) looks for a datasource value. That way in normal circumstances the controls always looking at the rendering parameter value, and in cases like split tests where the control has a datasource specified it will then be pulling the value from the item specified in the datasource instead
@Riaz: If I understand correctly, I have always wanted a layer that would do that for me - so I could specify things in the data source but override them with parameters. Do you have any generic way to make that happen, or do you have to do it with code each time you retrieve a value?