Sitecore Best Practices: Presentation, Coding, and Configuration

The Sitecore Best Practice Blogs (http://www.sitecore.net/en/Community/Best-Practice-Blogs.aspx) obsolete this blog post.

This post about presentation and coding is one in a series of blog posts listing Sitecore Best Practices. Not all of these are specific to Sitecore, and in no specific order:

• Structure data templates to separate content elements into separate fields, but do not go overboard and destroy usability.
• Consistent design leads to usability. Usability leads to repeat visitors. Repeat visitors lead to business. A consistent Sitecore solution minimizes developer effort, unless you grant CMS users too much control of presentation.
• Subject matter experts should focus on content, not markup or any other aspect of presentation. Avoid reliance on Rich Text Editor fields. I personally would avoid reliance on the design pane of the Page Editor.
• Use editor profiles to minimize the features available in the Rich Text Editor as described in the Client Configuration Cookbook.
• Follow best practices for Web, Windows, IIS, ASP.NET, XML, XSL, SQL, .NET, CSS, JavaScript, and other technologies. For example, comment your code to describe the intent, not the implementation.
• Do not allow a single data template to contain two fields with the same name.
• Avoid excessive customization; simplify.
• Read the documentation and review interesting Sitecore Shared Source projects, but validate everything you use with your solution.
• If CMS users create inappropriate markup, consider validation as described in the Client Configuration Cookbook.
• This applies to all CMS: do not let users think that they can create Web pages in Microsoft Word.
• Remember that you can store any kind of information in an item – content, metadata, control properties, etc. For example, you can include a checkbox in a data template to control whether items should appear in the site map.
• It’s often easy and logical to define navigation based on information architecture, but you can define navigation using whatever logic you need.
• Default to implementing every presentation component as a sublayout, and especially justify the use of XSL. While XSL can have advantages, it can also have disadvantages, and it might be easier to maintain a solution that uses only .NET. There is nothing that you can do in XSL that you can’t do in .NET, and much that you shouldn’t do in XSL that you can do in .NET. For a discussion of when to use each presentation technology, see section about Choosing Presentation Technology in the Presentation Component Reference manual.
• Give each solution a unique short name or acronym corresponding to a .NET namespace, and use that name consistently in file, subdirectory, and item names.
• Name data templates after what they represent, such as News Article or Job Description.
• You can name the default section in a data template after the data template itself. For example, in a data template named News Article, you can create a section named News.
• You can name variables after data template and field names. Consider variable naming conventions when naming data templates and fields.
• You can use the Display Name property to provide a user-friendly name for any item.
• Use the key of a placeholder as the default ID or as part of the ID of the placeholder control.
• Use a source code management system to manage all code, including JavaScript, CSS, and other resources.
• Manage developer media, such as images and flash files, through the source code management system instead of using the Sitecore media library.
• For a slight performance advantage, to avoid hard-coding, and to allow moving and renaming without the need to update code, use IDs instead of paths whenever possible. For example, use the classes Sitecore.ItemIDs, Sitecore.TemplateIDs, Sitecore.FieldIDs, and develop your own ID classes.
• Use the right tool for each task. You can often implement a feature in numerous ways – as a ribbon command, a UI component, a scheduled task, an event handler, a pipeline processor, a rule, a custom editor, etc. Consider the alternatives and design the solution such that you can switch to an alternative approach if requirements change. Scheduled tasks and simple ASP.NET pages can facilitate prototyping.
• Store workflow, layout, insert options, and anything else that you can in the standard values of data templates.
• Create a data template that inherits from an existing data template and update layout details in standard values rather than applying layout details to an individual item.
• Use search indexes to lookup items rather than brute force queries.
• For performance and usability, avoid hierarchies where a single item has hundreds and especially thousands of children (treat the item hierarchy like a file system).
• Avoid using any form of the descendant axis (descendant, descendant-or-self, or //), especially to traverse a large branch.
• Store all customized files in a source code management system (SCM) and follow a proper engineering release management process. Consider storing serialization files in the SCM and media that CMS users do not manage in the SCM.
• Avoid .NET languages other than C#. Sitecore code examples are in C# and Sitecore support speaks C#.
• Use web.config include files, but avoid overriding settings in the main web.config file or conflicting with something in other include files. Maybe someone could develop a tool to identify such issues.
• Remember to apply rendering caching options and tune caches. For more information about caching, see the Cache Configuration Reference manual.
• Minimize long statements that use the ternary operator.
• Avoid the var keyword in C#.
• Avoid using statements for classes in namespaces other than System, and fully qualify use of those classes.
• Remember to hide all files in Solution Explorer, especially before debugging.
• Remember to debug by attaching to the existing ASP.NET worker process.
• Remember that you have to request a page to get ASP.NET started after various events that reset application pools.
• Remember to set the copy local property to false when you reference an assembly in the /bin directory of the solution, or Visual Studio compilation may delete assemblies.
• I believe that the Sitecore.Data.Database.GetItem() method is more efficient than Sitecore.Data.Database.Items[] method.
• When you access Sitecore.Data.Items.Item.Children, Sitecore invokes a database query. This doesn’t matter in a foreach loop, but you should put Children in a Sitecore.Collections.ChildList before iterating with a for loop.

A previous post links to one of many documents providing potential C# coding standards. A discussion of Useful Coding Practices recently appeared on slashdot.

Related resources:

• Presentation Component Reference manual.
• Presentation Component Cookbook.
• Presentation Component XSL Reference manual.
• Presentation Component API Cookbook.
• Client Configuration Cookbook.

Next in the Sitecore Best Practices blog series: Link Management.

Advertisement