Template inheritance:

Template inheritance is an integral part of Sitecore which I hope that all of you Sitecore fans out there use extensively in your solutions. At Pentia, template inheritance is so vital that in practice, you will see no item.TemplateID == SomeID or item.TemplateKey = "sometemplate" in any of our code, just like you (hopefully) would never use MyObject.GetType().Name == "MyClass" in C#.
No, we always use the following extension method:

public static bool IsDerived(this Item item, ID templateId)
{
  if (item == null || templateId.IsNull || item.Template == null)
    return false;
    
  TemplateItem templateItem = item.Database.Templates[templateId];
  if (templateItem == null)
    return false;

  Template template = TemplateManager.GetTemplate(item);       
  return template != null && (template.ID == templateItem.ID || template.DescendsFrom(templateItem.ID));
}

Hierarchical inheritance:

While template inheritance is used to give all content of different types the same properties, hierarchical inheritance in Sitecore is slightly different. This is primarily used to allow a piece of content, a setting or a configuration to propagate down a branch in the tree – i.e. propogate down a number of content types which can be totally unrelated, but grouped together solely because of their content position. For example, this could be used to apply a given design theme to an entire subsite within you site. Using hierarchical inheritance, extension methods and Linq, this could be accomplished as such (pardon the train-wreck):

protected void Page_Load(object sender, EventArgs e) {
  var theme = this.GetDataSourceItem().GetAncestorOrSelf().First(i => i.IsDerived("HasTheme")).Fields["Theme"].Value;
  //...
}

GetDataSourceItem extends the ASP.NET UserControl to provide easy access to the DataSource set on a sublayout and is implemented as follows:

public static Item GetDataSourceItem(this UserControl control)
{
  Sublayout sublayout = GetSublayout(control);
  if (sublayout == null)
    return null;
  string dataSourcePath = sublayout.DataSource;
  return !String.IsNullOrEmpty(dataSourcePath) ? Context.Database.GetItem(dataSourcePath) : null;
}

GetAncestorOfSelf extends item to return a list with the item itself and all its parents – and this is naturally where the key to hierarchical inheritance lies:

public static IEnumerable<Item> GetAncestorOrSelf(this Item item)
{
  do {
    yield return item;
    item = item.Parent;
    
  } while (item != null);
}

I hope this post shows you how some simple extension methods can give you a lot of power in your solutions.

So where do we draw the line in the holy name of bending functionality and giving the customer “what they want”? Remember:

• Convincing the client to choose standard functionality is also an option.
• Each change of standard Sitecore functionality is potentially expensive – for you and for the client.
• If possible, do not replace Sitecore functionality, extend it.
• Think about what you put into Sitecore: Content and functionality can be accessed through .NET code and does not necessarily need to be added to the Sitecore DB’s or in a pipeline.
• Keep track of your customizations – source control it and document it.
• Remember that your customizations will have to upgrade with Sitecore.
• Stay true to yourself: If it feels wrong, don’t do it.

In short, just because you can does not mean that you should:-)

The website you a building today should also be the website for tomorrow and hence the website you are building should be extendable, flexible and scalable. It is absolutely possible to build a Sitecore web platform which will last many iterations – considering that you take this into account early in the process.

Select your implementation partner carefully

Your implementation partner is the single most important collaboration partner in your project. They bind everything together; requirement specifications, user experience design, hardware, software, domain knowledge and more, and is therefore crucial for the project’s success. Therefore your primary focus initially in your project should without doubt be to find the right implementation partner.

In my opinion, what you should focus on is:

Human chemistry: A website is not primarily a technological project, but a communication project. Therefore select a partner with whom you can communicate openly and freely. If you sense that they are listening, factors as for example domain knowledge is less important.

Experience: Sitecore is not a difficult tool to learn – but is takes time to master. Therefore, try to find a partner which has multiple large scale projects under its belt, and preferably with projects which has undergone a number of iterations.

Technology based: In my experience, companies which are technology based, i.e. which focuses primarily on the integration and platform parts of the solutions compared to the user experience driven companies, e.g. design agencies, makes more future proof Sitecore solutions. Therefore if you are looking for someone to build your future webplatform as opposed to just your next website, opt for a company with vast knowledge of Microsoft .NET and surrounding technologies.

References: Most implementation partners can most likely show an impressing list of references – but please do not stop there. Call their references and enquire about support, quality etc. Hearing whether their existing customers have gotten value for money is very useful.

Don’t be too specific in your requirement specifications

My suggestion is that you use your implementation partner as a sparring partner on requirements. Remember that these guys have built other solutions before yours and might bring experience, skills and functionality which will benefit you. Also, allowing multiple implementation partners to suggest different solutions to your website’s objective – as opposed to a RFP checklist – will allow you to better evaluate their creativity.

Therefore, in the specifications, try to explain the objectives you have for your company, users or editors, instead of the precise functionality. In Pentia we have had multiple requests for debate forum functionality in solutions – which in our experience is a prime example of a specific functionality which is often never used by users. By explaining which objective the clients wanted to achieve on the website, instead of the specific functionality, we could have advised better, earlier in the process and given more value to the client. By the way; in most cases we managed to dissuade the clients to actually implement the debate forum, and used the precious development time for something much more valuable.

In short: Requirements change. Therefore, being too specific and detailed about functionality already in the RFP process will most likely get you a whole lot of expensive, unused functionality.

Be open about your development budget

This is in my book a no-brainer. The only reasons for not being open about the budget are if you adopt the “they-are-all-thieves-and-robbers” attitude or if you hope to haggle your way to a cheaper website. In both cases, you are doing yourself and your website a whole lot of damage.

First of all, you have to trust your implementation partner, as they hold an immense power to make your project a success or failure. If you don’t, find another partner. Secondly, this is not a standard product you are buying. If you push your implementation partner on time or money, they have but one place to push back: quality. This basically means that your solution will be in a worse state, bringing lower reliability or higher support cost.

Therefore, a selection process is not about getting the lowest price or best solution description. It’s all about finding the implementation partner which you trust the most. And if you found that implementation partner, why not be open about mostly everything, including budget?

Bring your partners on board early

There is a lot of benefit in bringing in all your partners as early in the process as possible – this means both strategy and design partners and well as implementation and hosting partners. Each domain has something to bring to the process and can potentially save you a lot of money and hassle. Getting the implementation partner and hosting partner to talk together as early as possible can save a lot of time in the deployment process, and in my experience, by getting the implementation partner involved in the strategy and graphical design process a lot of hours can be saved in communication afterwards. Furthermore implementation partners often have prebuilt functionality which – if it fits the project – can save you a lot of time and money. The earlier this is brought forward, the easier it is to fit into any graphical design or information architecture.

A dedicated media server can be used to serve media on a separate URL, so that you can optimize performance due to limitations on the amount of connections the browser can open to the domain, which I also described in the last post. Further it can be used to optimize your server for handling media and supporting a CDN.

As mentioned it is now possible to have a separate server for media by configuration. In this scenario you might have a dedicated publishing target for media, and this should just be a standard Sitecore installation, which then only handles media by directing the DNS for your image URL to this server. For instance I have setup three Sitecore installations – one as a content manager server, one as the dedicated image server and one as content delivery server. The domain for my content management server is http://sitecore63/, the one for my image server is http://sitecore63imageserver/ and the content delivery server has the domain http://sitecore63cd/. What I then want to achieve is:

1. That my content management server serves images in the normal way, so that the editors can insert, alter and preview images without having to publish.
2. On my content delivery servers I want my images to be served by the image server.

The first goal is easy. I just leave every configuration to the standard. This means that the content management server serves media itself.
The second goal requires some configuration changes. On the content delivery servers I must make all media references point to the image server. This can be done by setting the Media.MediaLinkPrefix in the web.config to the domain name of the image server plus the media prefix I want. For instance like this:

<setting name=”Media.MediaLinkPrefix” value=”http://sitecore63imageserver/~/media/” />

This means that all media items on the content delivery server(s) will be prefixed with the above url:

<img width=”128″ height=”128″ alt=”" src=”http://sitecore63imageserver/~/media/Images/user.ashx?w=128&amp;h=128&amp;as=1“>

So in this scenario the html is delivered by http://sitecore63cd and the image is served by http://sitecore63imageserver. In the content management environment, the media is served locally. Now this is a lot easier, than the customization you needed in older versions of Sitecore.

If you want another media prefix then the standard /~/media, you also need to make the media server handle these requests as media. This is done by adding the prefix to the <mediaPrefix> element in the web.config and add the prefix to the customHandlers section in the web.config.

Whenever I create a template which uses a Sitecore Query to populate a multilist field with items, I always spend a little too much time figuring out the correct syntax for the Sitecore Query. But no longer… now that I have found the XPath Builder!

The XPath Builder is triggered in the Developer Center through the Tools menu. The application helps you build the right query and shows the result of the query:

The XPath Builder in Sitecore

Yay! What a great tool!

A new tool called Sitecore Rocks has been released in a CTP (Community Technology Preview) version – a early sneak peek. The tool, although a little rough around the edges, really shows a bright new future for Sitecore development, a future where we as developers do not need to muck about with browsers interfaces, only to connect our code, .NET pages and user controls into Sitecore. Now we can stay within in the tool we use and like, Visual Studio.

Together with the Team Development for Sitecore module from Hedgehog, this tool looks to be a must-have in the Sitecore developer toolbox.

In short, Sitecore Rocks is a Sitecore editing environment in Visual Studio. The environment naturally does not contain the complete set of features of the Sitecore content editor, but is focused on the features we as developers use. This includes for example:

• Quick and easy navigation in the content tree and on the item editor.
• Multi-item editing.
• Linking Visual Studio project to Sitecore, and automatic creating of layout related items in Sitecore from your .NET files.
• Live Sitecore log viewer.
• Job viewer allowing you to examine running tasks in Sitecore.
• Edit rich text fields in Visual Studio HTML editor/designer.
• Easy interface for layout management.

You can watch a video of Lars Fløe Nielsen presenting some of the Sitecore Rocks features here.

In my view, the tool is very nice and definitely a vision of what’s in store for us as developers, but the tool is still in the early phase and still has a lot of unused potential. Personally I feel that one of the most promising features is the ability for everybody to extend the functionality, and hopefully this will create a flood of shared source plug-ins with really useful features. Of the top of my head, I can mention countless possibilities, so drop a comment if you have a lot of time on your hands

The tool is available through the Visual Studio 2010 Extension Managers Online Gallery – just open it up in Visual Studio and search for “Sitecore” – or download Sitecore Rocks from the MSDN:

Besides these new features  a huge amount of bug fixes has been included. Some of them quite important; some of them quite funny…

Almost two years ago I wrote the blog post What TODO? In short I described the somewhat weird way of marking TODO’s by the kernel develepors at Sitecore. Well guess what… In Sitecore 6.3 they thought they would finaly do something about it. It has now…. been marked as obsolete (?!).

“The Sitecore.Todo class has been marked as obsolete. (323278)”

I must admit it made me laugh again. Why not just remove it, when you decide to do something about it?

So here goes:

1) Using the descendant axes in xpath expressions:

This one I especially look for, when I am looking at a site which doesn’t perform. It may be used in some cases, but very often I find that a developer has used this to generate relations between content and thereby iterating over the complete content tree. This works fine in development where there are a few hundred content items. However in production where thousands of items are created this simply breaks the performance of the site – especially after publishing which clears the HTML cache.

The descendants can be accessed in multiple ways. In XSLT it normally looks like this:
<xsl:for-each select=”$sc_currentitem/descendant-or-self::item”>
</xsl:for-each>Or like this:
<xsl:for-each select=”$sc_currentitem//item”>
</xsl:for-each>

In C# using the Sitecore API it is most often accessed like this:

item.Axes.GetDescendants()

2) XSLT Import:

This is related to a point in the post about code reviews on Sitecore, where I argue that overcomplicated functionality and logic in XSLTs, is a problem. If you need to do an import of another XSLT in your rendering, you probably do it to call a method or in another way try and reuse functionality. If you want to do this, don’t use XSLTs! XSLTs should only – if you really want to use them at all – hold simple presentations.
XSLTs can be imported like this:

<xsl:import href=”YourOtherXslt.xslt” />

3) Explicitly accessing the master database

Although this can be needed in some cases and especially in scheduled tasks or other backend functionality, most often it is because the developer haven’t thought the issue through or if they have made a wrong decision of how data entered by the user should be stored.
The master database is most often used like this in c#

Database masterDatabase = Database.GetDatabase(“master”);

If you see a call like this, your solution is most likely not ready for staging, where there is no access to the master database from the content delivery server. You should generally use something like this:

Database database = Sitecore.Context.Database ?? Sitecore.Context.ContentDatabase;

This means you operate on the context database and on the content delivery databases this will be the web database and in preview you will use the master database, which is probably what you want.
If you need to write something to the master database, you first need to decide if this is a good idea at all. If you write to the master database from your frontend, you make yourself vulnerable for malicious attack, as people from the outside can enter data into the master database. Normally we handle user entered data in a custom database or parse all user created content to ensure that the master database won’t be flooded with data.
If you really need to access the master database, you should create a service that handles access to the master database, so that your solution is ready for staged environments.

4) XSLT extension over 100 lines of code:

This point is closely related to point number 2, but I really see a lot of issues with XSLTs which have been used wrong and this creates a lot of issues later on in the project lifecycle. If you have an XSLT extension with over a hundred lines of code, chances are, that the developer made a wrong decision when creating the XSLT; instead he/she should have created a sublayout.
XSLT extensions are functional programming and you should use an object oriented approach, so my advice is not to use XSLTs at all, unless you are doing something really simple. Otherwise your solution will become harder and harder to maintain, as utility methods like the XSLT extensions are very hard to understand and couplings in the renderings themself are difficult to map.
You can find all registered XSLT extensions in the web.config under xslExtension and it looks something like this:

<xslExtensions>
  <extension mode=”on” type=”MyNamespace.XslHelper, MyAssembly” namespace=”http://www.example.net/helper” singleInstance=”true”/>

5) Clearing of cache

This may seem obvious to some, but I have seen surprisingly many methods, which cleared the entire Sitecore cache including the data and item cache. If you see this in your code and it is needed, chances are, that you have an architectural issue in your solution. It should most rarely be needed to clear the cache, unless it is after a publish and Sitecore handles this automatically. I have heard many reasons for clearing the cache including an issue, where the developer argued that it was necessary, as he wrote directly to the Sitecore database with a SQL statement, and then Sitecores cache wasn’t updated.
If you experience something like this, the issue is of cause not the cache, but that you don’t use the Sitecore API to read and write data from the database.
The caching is most often cleared like this:

CacheManager.ClearAllCaches();

This is just some of the things I have seen many times, but I know there are many other bad code smells when developing Sitecore solution. Do you have any other code smells to share?

Not only had he added some very nice features but he had rewritten some of the code so the application is more stable and extendable. So I really appreciate his work!

The new features are:

• Possibility to browse indexes defined in the new search section in the web.config
• Rebuild indexes through the IndexViewer (which is really nice, as you can’t rebuild the new type of indexes any other way)
• Optimize indexes.
• Improved usability and look-and-feel of the application

So go take a look at the changes at http://trac.sitecore.net/IndexViewer 

If you want to see some screenshots of the new features, take a look here

What I would like to add next, is extended search functionality.

In the first episode we interview Sitecore CTO John West. We talk about Dreamcore and Sitecore in general. Check it out at: http://learnsitecore.cmsuniverse.net/en/podcasts.aspx

Enjoy!

Pentia Professional Services and the Sitecore MVP’s of Pentia, invites all Sitecore MVP’s to attend an evening event before the Dreamcore 2010 by Sitecore conference – and absolute free.

The purpose of the night is primarily networking and social get-together, but during the evening we will provide an opportunity for you to share your best case stories, as well as join in a roundtable discussion on the future of the Sitecore platform, e.g. covering topics such as: “In which direction do we want Sitecore to move“, “What are the successes and failures of the Sitecore platform today“.

The event will take place Tuesday the 18th of May at 5pm, the evening before the Dreamcore conference. It is hosted at Pentia’s charming domicile located a stone-throw from the Dreamcore venue, and is concluded by a dinner at Copenhagen’s premiere steak gourmet restaurant, MASH.

If you are a Sitecore MVP, and want to get together with your peers and discuss the platform you love – Sitecore – then sign up now!

Read more on the agenda, venue and how to signup, at the Pentia website.

To be honest I think this is somewhat unambitious considering the power of the product. Sitecore has always excellented in focusing on keeping presentation as layer on top of the content. The demos I have seen have focused on the presentation layer strictly. This is all fine and I find the options given to the non-technical personal impressive, but in my opinion the product has a lot more to offer than that. I think that we in the future will see the analytics, personalization etc. applied to content as well as the presentation.

The past – hierarchical sites

So what do I mean by this? Well, most of the sites I work on, the real resource on the site is good and relevant content. The issue is then how do we present and structure this best for the user of the site? (Well most of the time this is the issue; I have actually worked with clients who think the most important job is to structure the content well for the content authors.) Anyway the focus on the information architecture and structure has always been inwards and out and how the content authors can deliver the content in the right structure.

This is the case of a hierarchical site. In these types of sites content authors try to force the content into a hierarchy, which dimensions often are dictated by the design of the navigation parts on the frontend. However content is rarely strictly hierarchical. Content is often more relational and is relevant in multiple places in the hierarchy and should be presented several places. If this doesn’t happen automatically the content authors will have a lot of maintenance and will have to consider where content should be presented on the frontend each time they create it. Further the hierarchy often resembles something that the website users don’t know anything about – such as the organizational structure of the company. So hierarchical sites tend to be hard to maintain and the users of the website are more often than not, going to have problems finding the content they are looking for. (A great example is the SDN. Who can find something on that site without using the search functionality?)

The present – Taxonomy driven websites

To accommodate this issue we have seen more and more request for taxonomy driven sites and have implemented them with success. In these types of sites the navigation of the site is controlled by tags. Content is created centrally by the content authors and they will have to tag the content with terms indicating what the content is about. The content is then automatically shown relevant and often multiple places on the site, depending on how the hierarchy of the tags is structured.

The limitation of this is still that the approach is inwards and out. The content authors and the information architects still have to create the hierarchy based on the presumptions about the users.

The future – behavior driven websites

And this is where OMS comes into the picture. Imagine if we could construct sites, which are completely outwards and in. The information shown on the websites is structured by how the users behave and not by what the content authors think is a good structure. The information OMS has gathered about the each user can be used and he will automatically be presented for relevant content based on previous experiences with similar profiles. Further imagine that the web analysts and marketers can create goals in OMS and then the content structure on the site will change, so that it will present the structure which gives the most conversions based on the behavior of other users or profiles, which have made a conversion. I call this a behavior-driven website and I would love to be given the opportunity to implement it.

So what is the difference from what we have already heard about the product? In my opinion personalization, behavioral targeting etc. should be based at content level and not only at presentation level. For instance take the functionality for A/B testing. This is based on different presentations, but in a behavior-driven website the A/B testing is applied to the content – in Sitecore that would be an Item. Imagine creating two versions of an item and then test the different content to see which brings most conversions. Imagine that the hierarchy of the site isn’t based on organization structure or tags defined by the authors, but from whatever structure bring most conversions for the profile the user matches. This can’t be handled in presentations – only at content level. Imagine that content authors never need to worry about where content should be placed, it is automatically placed where analytics from real users says is the best place. Now this would really be cool and I am sure it can be achieved with OMS and that is why having live analytics data together with your CMS is going to change how we build sites… Or so I hope

Does this make sense outside my brain?

One of the issues with publishing can be performance. When you publish one or more items the HTML cache is cleared, which means that if you have some performance heavy presentations, it will increase the loading time of the page, until the cache has been rebuild. Further if you use the staging module and it is configured to it, all the data caches are cleared as well. This can cause the site to take up to 30 seconds to reload your pages – especially if they are data heavy. You can read more about Sitecore Caching here and read about the issues with cache and the staging module here.

Note that Sitecore recently released a staging module which supports partial item caching, but the HTML cache is still cleared. You can read more about the new module on Alex Shybas blog.

I don’t know if performance impact when publishing is specific to Sitecore or is generally a problem in most CMS’, but I reckon it is the later. However Sitecore has a special problem with regards to caching. As Sitecore isn’t page based as many other CMS’ (this is also one of its biggest advantages), it makes it difficult to have a partial cache clearing – especially with regards to HTML cache. A page can be constructed by several content items, and there are no immediate binding between a page and the items, which it is constructed of, so all HTML caches needs to be cleared even though you just publish one item.

Another issue is the usability for content authors. Some of our clients were complaining about being queued all the time when they initiated a publish and it could take a very long time before they got their content published. What often happened was that when they initiated a publish, the modal dialog reported, that they were queued. Instead of waiting for it, they closed the window and continued editing. A few minutes later they would initiate another publish, but was once again told that they were queued. When this process repeated itself for the 50 active content authors, you can imagine the queue could get quite big.

Another thing we stumbled upon was, that some content authors used publishing instead of preview. Every time they wanted to view their work in progress to check if it looked alright frontend-wise, they published the item and viewed the page as if it was already completed and ready for actual publish.
I know we are not the only Sitecore partner experiencing this, as I have talked to other implementation partners and received questions about it on Learn Sitecore.

So why do I suggest it isn’t a problem? Well… we aren’t really experience any issues with our clients or with performance issues caused by publishing anymore. This is a result of more than one thing, but the primary solution was to use scheduled publish.

I don’t know why, but using this publishing strategy this can be a really big issue for clients. We often heard remarks like: “We need to publish content immediately”… But common! I really haven’t worked with many organizations, where this is an actual issue. What content do these organizations have, which is so important, that they can’t wait 15 minutes (at tops) to be published? I have consulted clients with huge sites, which is absolutely critical to the business and the funny part is that these companies rarely have a need to have immediate publishing. They are normally used to having a longer waiting period for the rest of their web services due to replications tasks between 100s of servers and rebuilding of caching. So why do the smaller companies have a bigger need for immediate publishing? The short answer – they don’t!

So what do we do to convince our client to use scheduled publish? We do more than one thing: First of all we explain to them, what impact publishing has. Then we allow a single or a few admins to have publish rights, so that they can have immediate publishing. Further we set the “do not publish” mark on all newly created items, so that they won’t be accidently published while they’re not finished. The authors will have to unclick the setting, when they think the item is ready for publishing.

Finally we have developed something, which in my opinion is rather cool! We acknowledged that people respond best to waiting time, if they have an indication of when the waiting will come to an end. This fact is also one of the reasons why they have timers on traffic lights in Copenhagen:

7 seconds to green light

We decided to use the same strategy for scheduled publishing. If the content authors would know, when the next scheduled publish is due, they would be much more satisfied with the idea of not having immediate publishing. So we – in Pentia – developed a timer which is shown in the task bar in Sitecore: 

The scheduled publish timer in action

The “Trinvis udgivelse” is Danish and mean incremental publish. So this timer tells the content author, that there is 12 minutes and 48 seconds to the next incremental publish. The functionality also supports multiple timers, so on some solutions we also use it to indicate, when an import from an external database is due and so forth. Cool, right?

These things combined we really don’t have any issues, with convincing our clients to use scheduled publishing.

The maturing OMS

The Online Marketing Suite is a great addition to Sitecore, and has some very cool features and a lot of potential for enhancing all of our solutions in the future. The product has some shortcomings and parts which could need enhancing, though. From a developer point of view, the documentation is limited, and there is no API for extracting data in a summarized or aggregated way – which leaves us to extract data directly from the SQL database using LINQ, SQL or stored procedures. But from my point of view, the most urgent need is best practices and tools for hosting the system. Switching the Analytics.Enabled to true in an out-of-the-box OMS will quickly generate a fairly large (huge) database, and sets some requirements on the hosting servers. Therefore, tools for administrators to handle databases (monitoring, truncating, etc.) as well as documentation for our hosting partners is looked forward to. There is a lot of focus from Sitecore and the community’s side on OMS, so I am confident that the already great product will make quantum leaps in 2010.

Scalable editor environment

One of the most anticipated enhancements of Sitecore has been the possibility to scale the backend/master server. This will allow not only better performance and active failover in the editor environment, but scaling of solutions running directly on the master database without publishing. An example of this type of solution is the Sitecore Intranet Portal. We have had customers requesting this possibility since version 4, and Sitecore codename “Twin Peaks” which introduced this feature, was on the Sitecore 2009 roadmap. Maybe 2010 will be the lucky year.

Enhanced presentation content

With Sitecore 6, the concept of a Page Designer was introduced. This makes it possible for editors or administrators to visually add or rearrange content on a page as well as edit properties on layout elements in a structured manner via property pages – cool features and great selling points. The problem with these features is that it touches upon one of the cornerstones of the Sitecore CMS architecture: The separation of content and presentation. By allowing property pages which saves content on the presentation layer, and allowing editors to change and save layouts directly on individual items, Sitecore has introduced a feature which makes it vital for developers to draw an exact line between content and presentation, and potentially pushes an rather large support burden on to the partners. We look forward to Sitecore best practices and tools to help us with this.

Greater testability

The close relationship between Sitecore and .NET has made it possible to transfer a lot of knowledge, methodology and design principles between the two platforms. Time has shown that not only Sitecore has adopted new.NET patterns, but also that .NET has implemented some of Sitecores (Just think of ASP.NET master pages in .NET 2). One of the great problems with both traditional ASP.NET and Sitecore is the support for unit testing and mocking. .NET has introduced ASP.NET MVC – which in many ways aligns with the content/presentation paradigm in Sitecore – and with this, enhancing support for unit testing. I’m sure many Sitecore developers look forward to a similar push from Sitecore in 2010.

Dreamcore conference

2010 has already introduced the Dreamcore conference – a three day conference hosted by Sitecore North America with developer and business tracks. Arranging this kind of conference on a regional basis, is not only a testimony to the success of Sitecore but fills a growing need in the community for Sitecore to communicate best practices and examples. Especially the developer part of the conference has been desired for some years, and rumors say that a similar conference is under way on our side of the pond. Now let us just hope that the conference brings real world examples and industry best practices instead of more Sitecore sales pitches. 2010 will tell.

No matter what 2010 brings, I am confident it will give us a lot of new cool Sitecore stuff.

Another one of the dynamic types of data we all works with each day, is Sitecore. The structure, i.e. templates and fields, we are coding up against changes constantly, and Sitecore provides a string based way to access specific items and fields and values in fields. Some of these dynamic types are exposed via classes in the Sitecore API, e.g. the fields type classes in the Sitecore.Data.Fields namespace. In Pentia we have a concept we call Sitecore wrapper classes, i.e. classes which we custom write to provide a proper interface to items of a given template. Writing these classes are tedious and potentially error-prone, which is why we are working on code generator for generating these classes (similar to e.g. LINQ to SQL). But with dynamics in .NET 4, we have a way of eliminating these classes completely, while still maintaining a proper syntax – and hopefully Sitecore will implement this to our common advantage. Here is an example of how code from the current version could look in a future version of Sitecore:

//BEFORE: .NET 3.5 Framework, Sitecore 6
public string GetContextItemDocumentImage() {
  Item item = Sitecore.Context.Item;
  ImageField field = ((ImageField)item.Fields["DocumentImage"]);
  return field.Src;
}

//AFTER .NET 4 Framework, Sitecore 7?
public string GetContextItemDocumentImage()
{
  dynamic item = Sitecore.Context.Item;
  return item.DocumentImage.Src;
}

Note that although the syntax differs, the actual functionality executed in both example would be the same. So, what does it require from Sitecore to do this? The secret lies in the System.Dynamics. IDynamicMetaObjectProvider interface or more easily, the DynamicObject class. This interface and class allows the derived class to provide its own resolving to e.g. members access and method calls via a number of virtual methods. The methods are Try based, which means that you should return false if the functionality is not supported, or e.g. a method with an invalid method is called. Some of the most important virtual methods which can be implemented via DynamicObject are:

An example of the above Sitecore 7 (:-)) implementation could therefore be:

namespace Sitecore.Data.Items
{
  public class Item : DynamicObject //...and other interfaces
  {
    //...
    public override bool TryGetMember(GetMemberBinder binder, out object result)
    {
      dynamic field = Fields[binder.Name];
      if (field != null) {
        result = field;
        return true;
      }
     	return base.TryGetMember(binder, out result);
    }
    //...
  }
}

Let this be an inspiration to Sitecore for the next version – I for one truly hope we see something like this in the product.

The reason of this behavior is that the HTTP standard says that only two simultaneous connections between a client and a server should be allowed. This was specified to save servers from heavy IO load, when files where requested. Browsers like IE7 and Firefox 2 lives up to this standard and only allow 2 connections, while new browsers like IE8 and Firefox 3 allows 6 connections.
To ensure that the HTML can be fully loaded independently and without waiting for other downloads and to remove the load from the primary web server; a dedicated image server can be used. This server holds all files and uses a different domain (for instance images.mydomain.com). All files used on the page can then be fully referenced and thereby be downloaded from a different domain. Eg <img src=”http://images.mydomain.com/image1.jpg alt=”image1”/>. As the images are now on a different domain, these can be requested independently of the server providing the HTML and more simultaneous connections can be opened.

But how is this possible in Sitecore where the media library controls all the images?

One of the easiest ways is to have another publishing target for the media. In that way you will have two frontend servers: One serving the normal requests and one serving all media items. You can easily set up another publishing target and for instance use the staging module to clear the cache. Read more on SDN if you want to know how to set it up.

The remaining problem is: How do we ensure that all media items gets prefixed with another domain? Unfortunately there isn’t a simple setting for this (it will probably come in a future a release of Sitecore – I hope ). However there is a simple solution to the problem as links are expanded by the LinkProvider, which can be overridden. More precisely the links are expanded in the LinkProvider.ExpandDynamicLink method, so we need to override this replacing the media path:

namespace TestApplication
{
  public class CustomLinkProvider : LinkProvider
  {
    public const string MEDIA_PATH = “~/media/”;

    public override string ExpandDynamicLinks(string text, bool resolveSites)
    {
      string baseExpands = base.ExpandDynamicLinks(text, resolveSites);
      return baseExpands.Replace(MEDIA_PATH, “http://images.pentia.dk/” + MEDIA_PATH);
    }
  }
}

Here I override the ExpandDynamicLinks in the inherited class CustomLinkProvider. I replace all media paths (identified by the prefix ~/media/) and replace it with the full path to the image server. The remaining thing to do is to replace the LinkProvider type in the web.config:

<linkManager defaultProvider=”sitecore”>
  <providers>
    <clear />
    <add name=”sitecore” type=”TestApplication.CustomLinkProvider, TestApplication” addAspxExtension=”true” alwaysIncludeServerUrl=”false” encodeNames=”true” languageEmbedding=”asNeeded” languageLocation=”filePath” shortenUrls=”true” useDisplayName=”false” />
  </providers>
</linkManager>

Here I just point the LinkProvider type to my own implementation.

Now that this is set up, all requests for media items will be handled by the image server. This does not just allow faster load times for the client, but will put less pressure on the main server. Further you can tune the media server to handling media items by increasing the media cache, setting the prefetch cache etc.

Enjoy your new Sitecore media server

In Pentia we finally got to that point, where we just decided to ignore the recommended label and upgrade and use the latest released version, as it seems rather arbitrary whether a version is recommended or not. This means that I wanted to download the latest version of Sitecore… But guess what. That is not possible. You have to download the release 090630; install it and then afterward download and install two updates.

So I couldn’t help but wonder… Why can’t I download a package containing the latest release of Sitecore?

Me and my colleague Brian Pedersen have been spending time in London (thx to Google London and Dave Gallerizzo of Fig Leaf) this week looking into the Google Search Appliance (GSA) – which is a really cool search product which I hope we will implement in a lot of future solutions. By the way, Pentia is now a Google Enterprise Partner

The GSA though, is a double edged knife – on one hand, it provides really good value out of the box (best of class in search relevance), and has a lot of nice features and configuration possibilities. On the other hand, the configuration interface on the GSA sucks! yes, it sucks! I would never expect any end-users to understand what happens in the UI, and in worst case, they will mess up the nice out-of-the-box functionality. Said in other words: the summer intern who wrote the config UI should be definately find work in a non-computer related sector.
This said, the GSA has some really cool API’s, which will allow you to provide nice functionality for your users:

Admin API
If you consider integrating a GSA in a Sitecore (or any CMS) solution, you should consider integrating some of the configuration directly in the CMS backend. Imagine users being able to tweak the biasing of content, or adding content to the “recommended” box in the top of the results directly in Sitecore. This is all available through the Admin API – which is nicely wrapped in .NET assemblies.
You can find the Admin API here.

Feeds API
The Feeds API allows you to insert content directly into the crawler queue. There are three options: web feeds, which simply adds URLs you want the GSA to crawl, url-and-metadata feeds, which allows you to add additional metadata to URLs being crawled (think adding metadata to PDF files), and content feeds which actually insert the html or binary data directly into the GSA.
You can find the feeds API here.

Policy ACL API
One of the strong sides of the GSA is the possibility to crawl and serve secure content, e.g. on your extranet or intranet. The problem though, is how to determine which URLs the individual users in your custom security solution has access to. This is where the Policy ACL (access control list) API comes handy. In short, it allows you to insert access lists in the GSA and map them to URLs – which again allows you to have fast secure queries – simple and wrapped in .NET.
Find the Policy ACL API here.

There are tons of other APIs and documentation on the Google Search Appliance on code.google.com.

When it comes to putting your pages together in Sitecore, you have two choices:

You can choose to build up your entire page composition on your templates in Sitecore, i.e. choose a layout and putting all sublayouts, renderings etc. on a template (which is naturally the __standard values of the template). This method is in my book the most correct, as it allows you, your fellow developers and the administrators to see the complete structure of a page, without leaving Sitecore. Unfortunately Sitecore does not deliver any layout inheritance etc., so this way requires a lot of hard work and mouse clicking (“try adding a rendering to all pagetypes late in the process – phew”) and is potential place for mistakes. Also, the page designer and Webforms module copies the layout from the template, locally to the item – and trust me, you do not want your layout with 20 renderings spread over your 15 pagetypes and 356 local items (“try adding a rendering to all pagetypes late in the process – double-phew”).

So, unless you are committed to keeping your page composition in one place, and choose not to use the page designer and webforms, you are left with the second option – putting page composition in sublayouts. This is where you put renderings and other sublayouts directly in the .ascx file, either through Visual Studio or the Sitecore layout designer. The big problem I have with this option, is that you separate page composition into two places – Sitecore and the ascx files. This forces you to use two different systems to setup caching etc. and makes it difficult to overview the complete page composition.

Enter Composite Layouts:

Composite Layouts is a new type of rendering I developed for a large project, which bridges the gap between the two options. It utilizes the fact that even rendering items in Sitecore have a Layout field, and it merges a layout set directly on a composite layout item into the layout set on a template. I.e. a composite layout is pretty much like a sublayout, in that it allows you to group renderings and place them on a page as a unit. The exception is that all configuration is done in Sitecore and the renderings on a composite layout can be placed in all placeholders – even placeholders outside the composite layout.

Our Form pagetype is a standard document page (with the usual header, topmenu, title, leftmenu, footer, spots etc.) which renders a selected form (which is incidentally created using Webform for Marketeers) in the content area:

The DocumentPage rendering is a composite layout which is defined with the following layout:

Note that the layout has a NullLayout selected – this is merely because the Sitecore UI forces us to select a layout before saving the layout on the item. The NullLayout is naturally never rendered.

Just to make the point; in turn, here’s how what the HeaderBlocks composite layout contains:

As you can see, composite layouts uses standard Sitecore UI with no addition, and all I’ve had to do at this point is to create a Composite Layout template and add it to the insert options of the Sublayout Folder template. The template has no fields whatsoever.

So how do you get it to merge the layouts? First you create a class – let’s call it InsertCompositeLayoutRenderings – derive it from Sitecore.Pipelines.RenderLayout.RenderLayoutProcessor and insert it into the renderLayout pipeline in the web.config. The entry needs to be right below the InsertRenderings entry, as this unfolds all the renderings in the current item and fills the Sitecore.Context.Page.Renderings list.

Second, you implement the Process() method of your InsertCompositeLayoutRenderings class, run through the Sitecore.Context.Page.Renderings and detects any composite layouts in the list, parse the layout field in the composite layout item and call Sitecore.Context.Page.AddRendering for each rendering found. If you want recursive support, you merely give the renderings on each composite the same treatment.

Granted, the design has some flaws – e.g. all renderings are added to the end of the layout (theres no InsertRendering method), so you have to be careful about the placeholders you use and order of the composite layouts – but I still consider the solution to be much better than the two options first mentioned.

We could all hope Sitecore reads this post and implements something similar in a future version, but until then if anyone is interested, I’ll consider posting the code on the Sitecore shared source network.

So what is it all about? Well we have been working with Sitecore for quite a while now, and we found that documentation was somewhat limited. Documentation revolves around SDN which is great as a reference (especially if the search functionality worked probably) and blog post by enthusiastic Sitecore developers. This leaves quite a gap, as there are no in depth article base and nowhere to go, if you want to start learning about Sitecore. Further there is only limited documentation for editors, server administrators and architects.

Therefore our vision was to create a site, which matches these target groups and goes in depth with the topics. Our mission is not to compete with SDN, as it is quite resourceful for snippets and references. Our mission is neither to compete with the blogs, as these are quite resourceful when you want biased opinions on Sitecore or new and interesting tweaks.

So in short learnsitecore.com is the place to go if you want to learn Sitecore or read in depth articles on different technologies which Sitecore uses. Right now there are a limited number of articles, but we hope to get some contributors and of cause write a lot of articles our self.

We hope you’ll find it resourceful and that you might be motivated to write an article or two.

The problem, as earlier discussed, is what to do with “presentation content”. With presentation content I mean settings or similar. For instance take a rendering where you want to present a list of news, which are all descendants of a specified root item. This rendering needs the following settings: How many news items to show, a root item, a read more link etc. Normally I would put these properties on a template as fields. However this would bind the presentation to content and the sublayout or rendering would only work on an item, which is derived from that template. As the end user can now meddle with the renderings and add or remove them at will, he will have to know the dependencies to different templates, which is practically impossible.

So what is the solution to this problem? Well as fare as I can figure out, you need to use the datasource and parameter properties on the rendering instead. However this introduces some issues when it comes to usability, as it is now the end user who needs to set these properties. Sitecore has a really rich and user friendly interface for altering content, but for some reason the UI for setting properties on a rendering/sublayout is rather hopeless. There is only one field type – a simple text field. So when you need to set an external or internal link you need to enter it as simple text. No lookups, nothing. Further there is no way, to my knowledge, to create validators for these fields, so you aren’t able to help the editor.

So for this to work Sitecore needs to implement a better UI or use the content editor to allow editors to configure renderings. I sort of figure it would be quite nifty, if there was created an item, whenever you add a rendering. The item should be based on a specific template for the rendering type, which would mean you could create different templates for different types of renderings and thereby control which parameters would be needed. This should be completely transparent for the editor, which wouldn’t notice that an actual item was created, except he would get the user friendly interface of the content editor.

This would give better usability and thereby allow a better separation of content and presentation (and the content needed by the presentation).

The end user issue doesn’t stand alone. Recently I implemented a sublayout, which should read some parameters. If I have done this in a best practice way, I must admit, that the API for reading parameters is completely hopeless. Check it out on SDN. What? Is this really the easiest way? Further the parameters data type is a concatenation of strings much like query parameters. This is quite frustrating as you have to parse the string or use the .net UrlString class to extract a specific parameter.

Adding all this together and adding different validation of the parameters made my class turn into one long unreadable mess.

The conclusion? If you want to separate content and presentation you lower the capabilities and usability for the editor and make your code one big mess. Either that or I am doing something completely wrong.

If Sitecore really wants the editors to meddle with presentation, they should really improve the UI and API for sublayout parameters and similar.

A year ago I wrote a post titled Type before function, which pointed out the very type-centric design of Sitecore. Since then, we have in Pentia tried to develop a design practice which focuses more on isolating logically grouped functionality in our design and thinking outside the type-centric nature of Sitecore. For this purpose, we have “invented” the term component in our design. The purpose of components is to separate the functionality from the type, allowing the developer to focus on one purpose and its interfaces.

The practise has been quite successful – our large-scale solutions have become increasingly easy to maintain and extend. As a side effect of the process, we now have a high degree of reuse – not just knowledge, but actual code – between even seemingly un-similar projects. Not very surprisingly, it turns out that developers are more inclined to reuse code, which is easily overviewed. The design practice is so successful, that we have passed it on to external projects, through our Professional Services.

Here are a few tips on getting you started:

Consistent placement and naming

Not all items belonging to a component can be placed together. Naming and placement makes it easier to identify component items – in a type-centric system.

Keep your files together – we never use the standard Sitecore folders, e.g. /xsl and /layouts. All files in a component are placed below a folder named /Components/[ComponentName]. This makes it easy to identify which files belong together without e.g. garbling the filename with unnecessary prefixes. And if you think about it, it’s not hard to identify a file as an XSLT – so why put it in the/xsl folder? Keeping component items together also goes for templates, renderings and layouts in Sitecore. For the purpose of Sitecore best practice, we still place templates under /sitecore/templates (although I suppose it’s not strictly necessary), and layout items under /sitecore/layouts. But we always use subfolders which are named consistently, e.g. /sitecore/templates/Components/[ComponentName].

Component projects

Each component has a separate Visual Studio project, and therefore a separate assembly. Aside from grouping files even further, this also helps to identify dependencies between components. Use build events on the project to move files from component folders to website folders if needed.

Interface templates

Think of templates in Sitecore as interfaces – never basetypes – which provide your pagetypes or data items with certain functionality. Always refer to these interfaces in the code within the components.

Example: The component Navigation (menu, breadcrumb and sitemap) defines the template Navigable with the fields Menu Title and Show In Menu. This template is assigned to the pagetypes which can be shown in the menu. The renderings Menu.xslt and Breadcrumb.xslt only references the Navigable template by using the XslHelper.IsItemOfType() method (or your own more optimized version).

Common components

There are a number of components which is always in a project, and which brings the functionality of the other components together.

The Design component contains all the graphic design for the project. Do not be tempted to place stylesheets and graphics within each component – the design for a single component is always related to other components, and therefore you will be forced to create unnecessary dependencies.

The PageTypes component brings together the interface templates and renderings and sublayouts in the other components on the actual page type template. Only page type templates are instantiated in the content tree. If you define the page type template News in the News component and not in the PageTypes component, you will be forced to create dependencies to other components e.g. Navigation.

Dependencies and Inversion of control

Keep your dependencies amongst components as few and as obvious as possible. It should not be necessary for a developer to know more than the component he is working on – too many dependencies makes the components too complex and less flexible. The common components is one way to reduce dependencies, another is the use of the inversion of control pattern and possibly an IoC container. Suppose the News component uses the Indexing component for providing data quickly. This could naturally be done by calling the indexing component directly through the News code, thereby creating a dependency. Alternately the News component could provide an appropriate interface which defines its necessary functionality. This interface could be implemented by the Indexing component and instantiated though Reflection or an IoC container like Unity or Spring, thereby inverting the dependency and making the News component more lean.

For instance take the often used structure for news, where you have a news folder. To avoid too many items in a flat structure you have folders for the current year and the current month. This could back in the old days be used by letting the editors them self create the folders they needed or you could have implemented a lot of event handlers or similar. Now you can just use a command template and let the command create the folders from the current DateTime.

To create command templates follow the guide in the data definition cookbook . Then implement the command to create the folders like this:

public class MyCustomCommand : Command
{
  public override void Execute(CommandContext context)
  {
  if (context.Items.Length == 1)
  {
  Item item = context.Items[0];
  NameValueCollection parameters = new NameValueCollection();
  parameters["id"] = item.ID.ToString();
  parameters["language"] = item.Language.ToString();
  parameters["database"] = item.Database.Name;
  Sitecore.Context.ClientPage.Start(this, "Run", parameters);
  }
}

protected void Run(Sitecore.Web.UI.Sheer.ClientPipelineArgs args)
{
  if (!args.IsPostBack)
  {
    //Means we are in the initial step, we want to ask for the name of the news
    Sitecore.Context.ClientPage.ClientResponse.Input("Enter the name of the news item:", Sitecore.Globalization.Translate.Text("New NewsItem"), Sitecore.Configuration.Settings.ItemNameValidation, "'$Input' is not a valid name.", 100);
    args.WaitForPostBack();
  }
  else
  {
    //Now we got a postback, which means we got a response
    if (!String.IsNullOrEmpty(args.Result) && args.Result != "undefined")
    {
      Database db = Sitecore.Configuration.Factory.GetDatabase(args.Parameters["database"]);
      Item parent = db.GetItem(args.Parameters["id"], Language.Parse(args.Parameters["language"]));
      //Create the folder structure if it doesn't exist
      string year = DateTime.Now.Year.ToString();
      string month = DateTime.Now.Month.ToString();
      TemplateItem folderTemplate = db.Templates[Sitecore.TemplateIDs.Folder];
      Item yearFolder = parent.Children[year];
      if (yearFolder == null)
        yearFolder = parent.Add(year, folderTemplate);
      Item monthFolder = yearFolder.Children[month];
      if (monthFolder == null)
        monthFolder = yearFolder.Add(month, folderTemplate);
      //Create the news Item
      TemplateItem template = Sitecore.Context.ContentDatabase.Templates[new ID("{B2612CF6-16D6-426D-9E74-EE3A4E3989B2}")];
      Item item = monthFolder.Add(args.Result, template);
      //Load the Item in the content editor
      Sitecore.Context.ClientPage.SendMessage(this, "item:load(id=" + item.ID.ToString() + ")");
    }
  }
 }
}

There you go – auto creation of folders. It’s that simple. I can think of really many usages of this – also more complex situations. Too bad the sheer UI documentation is so limited, as it makes it difficult to implement complex wizards etc.

A couple of weeks ago I was assigned to a task, where a client experienced that the Sitecore backend were performing really bad. Issues like these have always been harder to debug then frontend performance issues, as there are very few indicators to which process, is making the solution stall. Is it a scheduled task? Is it a custom pipeline? Is it an event hookup? Etc. etc.

Well on this particular task I found a rather new entry type in the log. Sitecore has implemented a new counter – the LongRunningOperationWatcher. This class is used to log entries like this:

Long running operation: Running Validation Rules

This is a great indicator and makes it easier to debug the backend. The class is called with a threshold, a message and some custom parameters, which are outputted in the log entry if the threshold timer is exceeded when the object is disposed. It is used in different methods throughout the kernel – for instance when validating different validation rules and in different pipelines. I can only hope that Sitecore will extend it to more operations and pipelines. Further it is great to use yourself, when creating a custom scheduled task, which might run wild.

After analyzing the log file for the client, I found that the “Long operation: Running validation rules” entry came up constantly, which told me, that either they had some custom validations, which were quite heavy on performance or that the server couldn’t bare the load from the standard validations.

·         It is quite difficult to synchronize environments. If we want to update the development environment with content from production, we either have to create a huge package with all the content or restore the database from production, freezing all development while it is updated.

·         There is no way of tracking changes or roll back.

·         It is inconvenient for our developers to work on a shared server, when developing backend functionality.

When Sitecore introduced serialization in Sitecore 6, we were hoping to be able to allow local databases that syncs via SVN and (de)serialization. The dream is a VisualSVN or TurtoiseSVN like functionality for Sitecore. Imagine using the gutter as an indicator whether you have made changes to an item and then have a commit button, which commits the changes to the repository, allowing other developers to update their database with the changes. Has anyone out there tried implementing something similar?

I have taken a look at the serialization functionality and found a few issues. Most of them can be worked around, but I was hoping, that we could have achieved our goal mostly using standard functionality.

To have version control you need the following operations:

·         Create: This works more or less as expected in (de)serialization

·         Merge: There seem to be no actual merge functionality. If you deserialize an item, which already exists (identified by item id), the item with the latest _update date, will be used. There is no merging of fields, as far as I have been able to test. This is not such a big issue, as the serialized items can be merged on file level. However it would be nice to be able to force an update through via the UI. This is by default only possible from the API.

·         Delete: This is not possible with serialization. We have thought of a couple of solutions, but they are quite extensive.

So what really needs to be handled is a way of deleting items with serialization. Oh… and a lot of UI functionality to make it work as VisualSVN

Anyone got any experiences?

Our entire setup consist of:

1: nAnt build framework
This is a set of approx. 30 nAnt scripts which is shared across all our projects. The scripts handles everything from SVN, MSBuild, FxCop, deployment, zipped releases, automatic versioning and much more. The files are versioned so that changes and new features will not influence the older projects and break the builds. In the last year we have released 5 versions of the nAnt scripts.

2: Subversion version control
In my approx. 15 years of programming I’ve only worked with Visual SourceSafe as version control (and as those of you who knows the product knows, is hasn’t changed for 15 years either , so the switch to SVN has been a daunting task for me. After a year, my only recommendation for those of you who consider it is to go for it! Subversion is easy to install and maintain (I recommend VisualSVN Server), easy to use (TortoiseSVN) and the integration into Visual Studio (VisualSVN) is perfect. Naturally the integration with nAnt is nice too as. E.g. it made it possible for us to automatically version our projects when releasing, by extracting the latest revision from SVN.

3: CruiseControl.NET
The hardest part to integrate into the company has been the CruiseControl.NET server. It’s not difficult to explain its purpose to the developers (to continuously check the projects on commits in SVN and build nightly releases), but the benefits of the other parts of the setup, for the individual developer has just been so much more evident. But still, its running, checking our builds and keeping our internal testing environment updated, by releasing each night.

4: Module library
The module library is a really neat feature of our build system. In short, it allows us to only maintain our own codebase in a project in version control and still allows developers to get quickly up and running, not making it necessary to install Sitecore version and thirdparty tools on their local machines. In the last year we’ve added 12 versions of Sitecore, 16 Sitecore modules (with 3+ versions each), 10+ third party modules like PDF, FTP and unit testing, and much more. The library allows us not only to add our old projects to the build system, but the cool thing is that when e.g. a new update to Sitecore is released, all our projects can be upgraded by changing a single line in the project build files.

5: Configuration merging
Both Sitecore and Microsoft has acknowledged the problem of mainting large configuration files. And the both have features which allows config changes to be merged from external files. The only thing they do not make easy, is to have different configurations for the different environments. For this we’ve developed a nAnt extension which allows the developers to create configuration merge files (configmerge files) which can be varied according to the environment we are building to. This has made a huge difference as opposed to juggling different configuration files for production/test/training/development environments for frontend and backend servers (6-7 web.configs!).

6: GUI tools.
We have lazy developers in Pentia Joke aside, we quickly acknowledged that in order to successfully get the system to the developers, we had to provide them with better tools than the nAnt command-line and CruiseControl xml files. So we created a nice GUI for our nAnt scripts and for editing our CruiseControl server.

As you can hear, I am still pretty excited by the accomplishments we’ve made in the last year – and we have a lot of cool features waiting. Our next release will incorporate generation of SQL scripts for mounting Sitecore databases and setting up database access and automatic IIS setup. We also want to automate our releases even more, by generating batch files for folder security and automated FTP upload to the production servers.

I’ll still be happy to hear from anyone with experience or ideas – or you can give me or Pentia a shout if you want to hear more about our setup.

·         Use of Sitecore.Context in logic

When having actual classes or general logic, I sometimes find a reference to the Sitecore.Context. Often it is a reference to Sitecore.Context.Item or Sitecore.Context.Database. This is rarely a good idea. The logic should be independent of the context it runs in. Instead you should pass in the objects you need as parameters. If you don’t do this, you’ll bind your logic to a certain context, making it unusable, if you want to use it without a context. Further logic that uses the context isn’t very testable.

·         Iterating over to many items

I don’t find this sort of issue very often, but it is pretty severe. The scenario is often that you have a list of all latest documents or a similar relational operation. You implement a simple XSL using “//item”. This works fine in development, but when the client starts importing or creating several thousand documents, the list doesn’t perform and brings the whole site down.

·         Too much logic in an XSL

Often you start out with a page type, which looks like a simple rendering. Therefore you start out creating an XSL. As you dig into the specs, you find out, that you need a lot of logic. You end up with a large amount of XSL extensions and a complex rendering. The result is a way to complex XSL, which is practically unreadable and impossible to maintain. When you have a lot of logic use a sublayout.

·         Reference to specific databases

Sometimes I find a reference to a specific database. For instance something like Sitecore.Configuration.Factory.GetDatabase(‘web’). Allthough it may be needed in some situations, it often gives some unintended sideeffects. Most of the time you want to operate on the context database, so you use the correct database specified in the site section in the web.config. A direct reference to the web database might cause preview functionality not to work as intended, and a direct reference to the master database might not work if you are using a staged environment.

·         Null reference

As Sitecore is so type weak and everything is an item, you don’t know what fields/properties the item has. No matter how experienced the developer is, I often find the use of a field of some sort, where it hasn’t been validated whether the field is null or not, resulting in a null reference exception if the input is incorrect.

·         Overriding standard Sitecore functionality

Sometimes a developer isn’t satisfied with the way Sitecore implements something – for instance the indexing, the site resolver, the domain etc. As Sitecore allows you to override almost everything, the developer thinks… Hey, I’ll just override the domain doing my own implementation. Although this might be necessary, it should be considered carefully. I have too many times stumbled into a problem with a custom implementation of standard functionality, either because it may be more complex than first assumed, the next developer on the project isn’t aware of it or last but not least an upgrade of Sitecore changes the requirements to the functionality.

I am hoping you want to share some of your experiences as well – telling what Sitecore pitfalls you often stumble upon or find very irritating.

Therefore I decided to implement an index viewer and I am proud to announce, that it is now released. It has been added to the Sitecore Shared Source modules. Go to http://trac.sitecore.net/IndexViewer to download the package or the source. To see some screenshots go to http://trac.sitecore.net/IndexViewer/wiki/Documentation.

In the IndexViewer it is possible to: See information about an index (Last modified, number of ducuments etc.), browse the documents in an index and search through the index using different Lucene Query types.

Let me know if you have any comments, feature request or similar. Enjoy!

But…  Does it make any sense?

·         Most of the clients we have been working with prefer to use the content editor and not webedit. To ensure that content editing is user friendly and intuitive, most of the time we construct solutions, where the content structure and hierarchy is the same as how it is presented on the frontend. This enables the editor to find and edit content in the same manner they find the information on the frontend.

In this matter it makes more sense to bind content and presentation structure together.

·         You seldom want to use the same content structure on different devices. When constructing sites for mobile devices, you probably want to have a simple flat hierarchy, which is different from your normal site.

Therefore it makes more sense to me, to have two different structures optimized for the presentation on the different devices.

·         Often the editors want to be able to edit the presentation. If they create a list in a rich text, they probably want to be able to decide how this list is presented – hence you bind content to presentation. This is allowed in the rich text field. By nature WYSIWYG editors is bound to presentation. What you create is what is presented. Should you avoid rich text fields completely?

·         If content from rich text fields should be independent from what devices it is presented on, it requires editors to consider this, when they create their content. For instance a table with a lot of data expanding over 320 pixels wouldn’t look good on an iPhone, so the editor has to be more aware of the technical limitations of the devices or limited to use memo fields.

All in all I find that you on some level always want to bind the content to the presentation, allowing more flexible content and giving editors a more intuitive way of creating content.

I agree that you can construct a Sitecore solution that separates content from presentation completely, by developing a solution consisting of a big repository of memo fields, which can be pulled on to a presentation item… But this wouldn’t be very user friendly.

So why is it so important to separate content from presentation and does it make any sense?

The following table shows the number of files, just in the /sitecore/shell/themes/standard folder for some randomly picked versions of Sitecore CMS:

Version 5.0:    11.100 files
Version 5.2.0:    13.357 files
Version 5.3.0:    13.745 files
Version 5.3.2:    18.133 files
Version 6.0:    18.244 files
Version 7.0:    ??

I have about 5-10 different Sitecore projects on my hard disk which I am actively working on, I constantly create and delete Sitecore projects for testing purposes and our build system continuously and nightly surveys, builds and copies 20+ active Sitecore projects in our company. All of these tasks are heavily burdened by the icon library.
A clean Sitecore 6 version contains approx. 24.000 files of which approx. 18.000 are icons (and approx. 5.000 are related to the HTML editor). This means that 75% of the files in Sitecore are icons. In terms of megabytes, this number is only 40%. But still, you get my point?

Sitecore, please, please, please consider alternate ways of including the icon library. How about a compiled resource with all the icons? Or maybe included in the media library in the core database? Whichever way you choose, the life of me – and a lot of my fellow Sitecore developers – will be so much easier. Thank you!

Please give me a shout if you have any comments or if you want to contribute with ideas or coding.

The really interesting question is, are anyone working on a LINQ to Sitecore project? or how about an template entity mapper (like to one in LINQ to Sharepoint)? Give me a shout if you are interested – maybe we can get a open source project going on the topic.

Both the mentioned technologies from Microsoft uses another feature in .NET 3.5 SP1, which is URL Routing (available through the System.Web.Routing assembly). Basically, you are able in your global.asax to specify dynamic URL’s which will routed to static ASP.NET pages. Sound familiar? Yes, it is a dynamic resolver similar to the way Sitecore resolves its rendering engine, and this is where the challenge lies. Microsoft uses exactly the same technology as Sitecore, httpModules, to hook into the request and resolve the physical file. Therefore the following must be added to you web.config to get Microsoft URL Routing to work:

<httpModules>
  <add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
  <add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
  <add type="Sitecore.Nexus.Web.HttpModule, Sitecore.Nexus" name="SitecoreHttpModule"/>
  <add type="Sitecore.Resources.Media.UploadWatcher, Sitecore.Kernel" name="SitecoreUploadWatcher"/>
  <add type="Sitecore.IO.XslWatcher, Sitecore.Kernel" name="SitecoreXslWatcher"/>
  <add type="Sitecore.IO.LayoutWatcher, Sitecore.Kernel" name="SitecoreLayoutWatcher"/>
  <add type="Sitecore.Configuration.ConfigWatcher, Sitecore.Kernel" name="SitecoreConfigWatcher"/>
</httpModules>

Notice that I’ve added the UrlRouting to the top of the list, making this my primary URL routing preference. There is a few more entries in the web.config you need to add, but this is really the one that does the trick – well almost…
The problem is that Sitecore is a real bastard for taking over the request – even if Microsoft URL routing is interested in the request, Sitecore says “we’ll I don’t know about this URL, so lets redirect to the ItemNotFoundUrl” (this is also why 404 errors and SEO in Sitecore is handled poorly).
To overcome this, we either have to, manually, enter our URL Routing URLs in the IgnoreURLPrefixes entry in the web.config or create a Sitecore HttpRequestProcessor for handling the URL Routing URLs. To do this, you need to implement a class deriving from HttpRequestProcessor which determines if a URL is handled by Microsoft URL Routing and then skips out the Sitecore stuff.:

using System.Web;
using System.Web.Routing;
using Sitecore.Pipelines.HttpRequest;

namespace WebApplication1
{
  public class IgnoreUrlRouting : HttpRequestProcessor
  {
    public override void Process(HttpRequestArgs args)
    {
      RouteData route = RouteTable.Routes.GetRouteData(new HttpContextWrapper(args.Context));
      if (route != null)
        args.AbortPipeline();
    }
  }
}

This class then needs to be hooked into the Sitecore request pipeline in your web.config. I’ve chose to do it just after the IgnoreList. This is before Sitecore sets up its context, so you can choose to move it even further down the list if you want more Sitecore functionality in your ASP.NET code:

<httpRequestBegin>
  <processor type="Sitecore.Pipelines.HttpRequest.StartMeasurements, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.HttpRequest.IgnoreList, Sitecore.Kernel"/>
  <processor type="WebApplication1.IgnoreUrlRouting, WebApplication1"/>
  <processor type="Sitecore.Pipelines.HttpRequest.SiteResolver, Sitecore.Kernel"/>
  ...

Bam! You are up and running ASP.NET Routing and can now start using MVC, Dynamic Data and all the other fun new stuff coming from Microsoft.

The way Sitecore uses Lucene to index, hasn’t been all that well documented, but earlier this year Sitecore released some documentation describing how items are indexed. The guide is ok and it describes how indexes are configured and how the indexing is performed in an understandable way.

However I often find that I need some documentation on how to extract data from the indexes. Even Lucene’s own online documentation on this, is somewhat limited. A couple of weeks ago I found and skimmed the book “Lucene in action”. It is a recommendable book and describes the different queries and analyzers really well.

Still there is a lack of Sitecore documentation on how to extract data through the Sitecore wrapper API to Lucene. In particular I could use some documentation on the Sitecore.Data.Indexing namespace, which seems to hold a lot of functionality – also when one wants to extract data. The documentation is limited to a few snippets and blog entries.

However the lack of documentation hasn’t been an issue until Sitecore 6, as it was possible to use the tool Luke. With Luke it was possible to browse indexes, try out query strings etc. When developing something that uses Lucene, this tool has been essential.

In Sitecore 6 the indexing uses compression, resulting in Luke failing whenever you browse or search through an index – as .net compression isn’t compatible with Java compression. Whether or not to use compression for the indexes, hasn’t been implemented as a setting in the web.config, but is hardcoded into the IndexData class, so it is not possible to disable. L

I have asked Sitecore Support to register a change request for implementing a setting – but until then developing functionality, which uses the indexes, are based on guessing and use of the reflector… So Sitecore please hurry!

The other day exploring the Sitecore API through the reflector, I found Sitecores way of marking TODOs. I was looking at the SiteResolver and then found the following line of code in the Process method:

Todo.OT("Optimize - takes almost 2 ms.", false);

While laughing I thought…. Hmmmm should I contact www.thedailywtf.com ?

It seems that Sitecore has a class called Sitecore.Todo with a method for each developer and it is not removed when releasing new versions of Sitecore. The above line probably reminds Ole Thrane that he should take a closer look at the SiteResolver.

Much better then resharper…  Or? J

Although Julius works with netzkern, a German Sitecore partner and training center, the series is fairly objective and I would consider a must-read for all you people in the Sitecore/Sharepoint community interested in where Sitecore/Sharepoint can help you.

You can find the series here.

Good work Julius – looking forward to the next post.

Are others of you in the Sitecore community also attending the conference? Maybe we should get together for a talk about how the topics could be applied in our daily work with Sitecore. Write me a comment if you are interested.

All developers (in their right minds) knows that asp.net codebehind files should contain UI layer functionality, not business logic, and that one c# codebehind file is bound to one asp.net file. What we want to achieve, is to have the same link between codebehind files in ASP.NET and XSLTs, therefore in our internal projects at Pentia, we have introduced the concept of XSLT codehind files.

So how does that work, you might ask?

Basically, we’ve developed a module which is included in all our projects (through our build environment), which automatically links XSLT extension classes to XSLT files through a common namespace. The module consists of an overridden Sitecore.Web.UI.WebControls.XslFile class, which overrides the AddExtensionObjects function:

  public class XslCodebehindFile : Sitecore.Web.UI.WebControls.XslFile
  {
    protected override void AddExtensionObjects(XsltArgumentList list, Item item)
    {
      //...
    }
  }


The AddExtensionObjects function dynamically determines which .NET class is the codebehind file for the current XSLT and adds it to the XsltArgumentList with a specific namespace (in our case http://www.pentia.net/codebehind). The class to add is determined via a custom .NET Attribute class which decorates the codebehind class (see the example below).

Furthermore the module implements an overridden Sitecore.Web.UI.XslControlRenderingType class:

  public class XslCodebehindControlRenderingType : XslControlRenderingType
  {
    public override Control GetControl(NameValueCollection parameters, bool assert)
    {
      // Returns the XslCodebehindFile class instead of the XslFile class
      // ...
    }
  }

This class is used by the Sitecore renderings engine to return the .NET class which implements a Sitecore rendering type. The class is hooked into Sitecore through the web.config (done automatically though our build environment):

<configuration>
  <!-- ... -->
  <sitecore>
    <!-- ... -->
    <renderingControls>
      <!-- ... -->
      <control template="xsl rendering"
        type="PT.XslCodebehind.XslCodebehindControlRenderingType, PT.XslCodebehind"
        propertyMap="Path=path" />
        <!-- ... -->


So how does the developer actually use it?

The developer starts by writing his XSLT file, e.g. /xsl/newslist.xslt. Most often it turns out that XSLT files does not even require codebehind or that the required functionality is implemented in the Sitecore XSLT extensions, but in the rare cases where advanced functionality is required (e.g. paging in the list of news) the developer creates a c# class file named newslist.xslt.cs (to keep the naming conventions defined by Microsoft). The class in the file is decorated with the XslCodebehind attribute which points to the fully qualified XSLT file:

  [XslCodebehind("/xsl/NewsArchive.xslt")]
  public class NewsArchive
  {
    //All functions in this class can be called in NewsArchive.xslt
    public Int32 GetCurrentPageIndex(XPathNodeIterator archive)
    {
      //...
    }
    public Int32 GetPreviousPageIndex(XPathNodeIterator archive)
    {
      //...
    }
    public Int32 GetNextPageIndex(XPathNodeIterator archive)
    {
      //...
    }
    }

This class is then automatically linked into the XSLT file at runtime and can be called though the http://www.pentia.net/codebehind namespace:

  <?xml version="1.0" encoding="UTF-8"?>
  <xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:sc="http://www.sitecore.net/sc"
    xmlns:codebehind="http://www.pentia.net/codebehind"
    exclude-result-prefixes="sc codebehind">
    <!-- ... -->
    <xsl:template match="*" mode="main">
      <!-- ... -->
      <a href="?p={codebehind:GetNextPageIndex(.)}">
        <!-- ... -->
      </a>
      <!-- ... -->
    </xsl:template>
  </xsl:stylesheet>

Easy-peasy – no meddling about in web.config and a much tighter coupling between XSLT files and their .NET functions.

The XSLT codebehind functionality took me about half a day to code and include into all our projects. It has made it practically easier for developers to link functionality to XSLT files and conceptually easier to understand the placement of the XSLT functionality in the UI layer.

The possibility of hooking in your own .NET functions into your XSLT code is a vital part of Sitecore, but the concept of XslExtensions brings a few problems to the party:

• XslExtensions are actually a return to the world of functional programming and removes the concept of which context your code is running.
• XslExtensions are loosly bound to where it is used. In practise it is difficult to know from where your code is being called – if it is called at all.
• Hooking in XslExtensions requires changes to your web.config file. This is actually not a big problem, but it would be nice to be without.
• XslExtension methods require specific types as input and output. Therefore if you introduce nice functionality in a XslExtension method, it is bound to the XSLT compliant types.
• XslExtensions lies on the border between the UI and the business logic tier of your application. Therefore XslExtensions can often be cluttered with methods which replicate and port functionality in your business logic to XSLT compliancy, or actually introduces new business logic functionality.

A good example of this last two points are Sitecore.Xml.Xsl.XslHelper.HasBaseTemplate() method, which is actually the only place in the Sitecore API where you can query whether an Item derives from a given template. This means that if you need this code in ASP.NET, you need to replicate the functionality in your own classes or – even worse – call Sitecore.Xml.Xsl.XslHelper.HasBaseTemplate() from your ASP.NET codebehind.

So, what can we do to try to enforce good development practise while still maintaining the essential functionality of exposing .NET methods to XSLT’s? I’ll get back to that in part two of my post.

The next release will be Q1 2009 and is codenamed “Twin Peaks”. According to Sitecore, this will be a minor release primarily focused on scalability, i.e. clustering of the master/editing servers and transactional publish. This will allow Sitecore to run live mode (no publishing) on a scaled environment as well as allowing partial clearing of the caches. These features are super important for the Sitecore product and something I’m personally looking very much forward to.

After “Twin Peaks” comes “Everest” – Q2 2009. As I see it, a version which is primarily defined by the marketing division of Sitecore. It is planned to include personalization, analytics and reporting features – nice features, but not something I as developer and architect is going to lie sleepless in anticipation over. That said, I’m sure we’ll all experience more user driven and personalized websites in the future which means that Sitecore is delivering.

Not included in the roadmap was “Massif”, which rumor says is going to contain database and content scaling – the ability to have thousands of items on one leaf in the hierarchy. For me this is the big one – imagine not having to force one hierarchical view on to parts of your data. For example, in current versions of Sitecore we are forced to group the news data of a solution after date, category or something other. But then if the date on the news item changes, we have to move the item to another folder or what if news can have multiple categories… Hopefully “Massif” will help us out on this, allowing items to be created in one big pile and extracted using indexing.

Conclusion: Good job, Sitecore – please bring more roadmaps in the future!

<xsl:variable name=”home” select=”$sc_item/ancestor-or-self::item[@template='site root']” />

It is fine that they finally removed the hardcoded path to /sitecore/content/home, but in my opinion the reference to the specific template ‘site root’ is still bad practice.

When developing a site one should take into account, that the site can be expanded, altered or duplicated later on. In the process of doing so, it is likely that a new template is created, which then inherits from the original template (in this case the ‘site root’). If this is the case all your renderings will stop working, just because you wanted to add a field, change a rendering or in any other way alter the original template.
Instead you should test whether an item is of a given ‘type’ – testing if the template the item is based on is equal to or derives from a specific template. This functionality has even been included in the XSLHelper class in Sitecore 6. Now it is possible to do the test like this:

<xsl:variable name=”home” select=”$sc_item/ancestor-or-self::item[sc:IsItemOfType('site root',.)]“/>

The concept has been substituted by the possibility to assign templates directly templates (i.e. “Which templates can be created under this page type” instead of “Which prefilled items can be created under this page type”). The prefilled data on the master (which was copied to the items) can still be applied using Standard Values (which was there in Sitecore 5 as well). Standard Values are made even more powerful than in Sitecore 5 since it now derived through all inheritance levels, i.e. if DerivedItem is created from DerivedTemplate which derives from BaseTemplate, standard values set on BaseTemplate also applies to DerivedItem. This means that you can e.g. set a layout on BaseTemplate and thus all the derived templates will now have a standard layout which you apply changes to.

With this and other features, Sitecore 6 has made some nice changes to force developers to design better Sitecore solutions by applying content reuse and thus makes the solution easier maintainability. But there are some issues: Sitecore 6 no longer indicates whether a value is a standard value or actually applied to the item (see below). In my opinion this is a major flaw. It is vital for developers and administrators to be able to instantly determine whether a value should be changed directly on the item or on the template, thereby allowing them to think about whether the change should be universal or local change. An ugly dent in the before mentioned “changes to force developers to design better Sitecore solutions”. Thankfully the designer of the DBBrowser (hail!) has not been so rash – but this is still not a tool I would like my users (even the super-ones) to see. Hopefully this will return in an upcoming hotfix.

I’ve been working with Sitecore for quite a while now and my first though on this reply was “Of course you cannot remove the Sitecore folder, because…” – well because what? So my second though was “Dammit i’ll try it out” – and…

System.Xml.XmlException: “The root element is missing”

To be frank, I’ve not once though to remove the Sitecore folder even from some of the major solutions I’ve been on – and it makes perfect sense. There really should be no runtime specific data in the /sitecore folder – well at least not in the /sitecore/admin, /sitecore/debug, /sitecore/login, /sitecore/shell, /sitecore/testing (actually /sitecore/testing sound like it should not have been released at all), and the folders not mentioned here sound like they at least could be removed on some projects. So why does it fail?

It seems one runtime file has snuck its way into the /sitecore folder – to be more precise: sitecore/shell/Security templates.xml. Because security is such a low level part of Sitecore and affects all reading of data via the API, and since all data in Sitecore are based on templates – even security data – initializing the templates for Users, Roles must be done before all data access through the normal API can begin (a genuine catch 22). The templates for security are therefore specified in a file – Security templates.xml.

Luckily this file – along with its path – is specified in the web.config and can therefore be moved (two changes are necessary – to find them search for the path), and – hey presto – the /sitecore folder can be removed with out exceptions being thrown.

Please note that there are other links in the web.config file which must be changed, e.g. /sitecore/nolayout.aspx which is used to show a pretty error page when a layout is not present on an item. But these should be fairly simple.

Also note that this is Sitecore 5.3 only – Sitecore 6 has an entirely different security architecture and therefore none of the above is probably valid.

Happy /sitecore deleting

Consider the main sections in Sitecore: Content, Templates, Layouts, and even the folder structure /xsl, /layouts. Sitecore seems inherently to point the architect towards categorizing his solution after which types of elements it consists of, i.e. which templates do my website consist of, how many layouts do I have, which XSL’s do I have to write etc. instead of looking at the conceptual structure of the website, i.e. which functionality do I have, e.g. newsletter, document, navigation etc. Trying to piece together all the parts which make one function on the website involves browsing through a lot of folders in Sitecore and looking into a lot of code, whereof many of the references are very loose e.g. template names in XSLT files, or assembly references in the web.config (or even worse: assembly references in Sitecore). All in all it is not an architecture which is very helpful for reuse and overview.

I vision Sitecore in a future version working in a more functionality-centric way, for example imagine the Sitecore content tree:

• /sitecore
  • Content (This is where the editors edit the site – not much different here)
  • Components (This is where we – the developers – roam)
    • Component (each functionality has its own section)
      • Templates (this defines the templates for this component)
      • Presentation (This defines all the presentation elements for this component, layouts, renderings etc.)
      • Settings (General settings, dictionary texts etc. needed by the component)

…and that’s it. No more browsing the entire tree looking for the settings for the Mailing list module. No more: “I wonder if this layout is used by any of my 367 templates”. No more: “Was that document.xsl or document.ascx”. Just imagine the ease in making of package for porting functionality to a new website.

Just my two cents…

A layout is basically a simple field (__layout) on an item which describes how the item is rendered by the rendering engine, and as such can be assigned on the item and on the Standard values (http://sdn5.sitecore.net/End%20User/Template%20Manager/Standard%20Values.aspx).

On pre-5.3 version of Sitecore standard values was not available, so in order to have layout reuse, layouts was assigned to templates. This functionality has been preserved in Sitecore 5.3 for backward compatibility. I’ve actually just recently been made aware of Sitecore’s recommendation on putting layout settings on standard values instead of on the template. Architecturally this is absolutely the right way to go – the template way was a hardcoded layout engine functionality to enable reuse.

Well to get back to the point: Do not – ever – assign layouts directly to items.

Assigning layouts to template standard values gives you the reuse you want and need, in order to maintain an architecturally sound Sitecore installation. Consider a situation where you have a layout (header, footer, menu, spots, content) defined on your document template, and you want to introduce a breadcrumb on your site. If the architecture is correct, this can be accomplished merely by changing the document template and all documents on your website will be updated.

Then again consider a situation where 10 specific documents need a slightly different layout. Well, the simplest way would be to just set the layout directly on these documents. WRONG! Settings layouts on directly on items primarily set aside all reuse, but more importantly makes you completely loose the overview of your solution. If you in this case wish to introduce a breadcrumb you will have to manually find (on your 10.000 page website) the items which has a specific layout and correct these – which often leads you to the painstaking realization that you have to write a script.

Therefore what you should consider is introducing data templates and layout templates and use template inheritance. In projects in Pentia, we define fields and functionality in one template then derive to another template and set the layout on this. Consider a template DocumentData which holds the fields Title and Text, and another, Document, which derives from DocumentData and define the layout (and other standard values). If I need specific layouts on certain items, I derive another layout template from DocumentData, e.g. WideDocument, which then defines the specific layout. This means that all layout settings are always in the Templates section of Sitecore – easy to find and reusable.

Well I signed up and hope to be selected for the program. Exciting to see what the developers have come up with. Especially Im looking forward to have a look at the new security engine. Further it’s very nice that the next version of Sitecore has an actual beta fase. Hopefully this will ensure, that most bugs are handled before an actual release.

One thing though… You have to sign up via fax! What?!? Cutting edge technology CMS vendor Sitecore couldn’t make an online sign up form? Well it made me laugh.

Module Library:
We have collected an entire module library, including all newer version of Sitecore, all Sitecore modules as well as all our internal modules. This means that when starting a new project, or when implementing a new modules in a project, the customer merely points the build configuration to which modules the project uses, and – hey presto – the module is included in the project. This includes code files, Sitecore packages, configuration file changes (see later) and all other related files. The point is – the project points to a module, and the module is responsible for integrating itself in the project.

Configuration files management:
We have previously had a lot of hassle trying to maintaining changes in the Sitecore web.config as well as all the other configuration files. Trying to keep all config files in all project targets (dev, test, prod, etc.) synchronized is a pain. Therefore we have developed a nAnt task which when running the build, merges project/module specific changes into Sitecores standard configuration file. I.e. when a full build is run:

1. The standard Sitecore configuration files are copied from the Module Library (from the correct version of Sitecore)
2. The relevant Sitecore modules standard configuration changes are merged into the configuration files
3. Dependant on which target the build is for, the project specific configuration changes (connection strings etc.) are merged into the configuration files.

A side from keeping the configuration files synchronized, this also means that when upgrading Sitecore (a task which basically to point the project to the new version in the module library) all Sitecore’s new or changed configuration settings are automatically included.

Our CI environment also implements Subversion, MSBuild, FxCop, automatic test server deployment and installation versioning/packaging.
One of the problems we are facing with Sitecore and CI is the amount of functionality and configuration hosted in the Sitecore database. We’ve through hard about e.g. integrating the Sitecore packager with the build environment, but dropped the idea. Please let me know if you’ve done something similar.
As you can hear i’m pretty excited about this, and would really like to make it as cool as possible – so throw me a comment if you have experiences with CI/build environments and Sitecore.

• All database access in the MailingList module goes through the internal class Sitecore.Modules.MailingList.Core.SqlHelper
• This class is only accessible through the internal property SqlHelper SqlHelper in Sitecore.Modules.MailingList.Core.MailingList
• SqlHelper opens a database connection in the protected (but not virtual) IDbConnection CreateConnection()
• This function returns an SqlConnection if the Sitecore field “Database” contains the text “MSSQLSERVER” (*Sigh*), otherwise an OleDbConnection is opened
• The sql server ConnectionString is read from public static string Sitecore.Modules.MailingList.Core.MailingListSettings.ConnectionString
• This property reads the value from the field ConnectionString in the Sitecore database

As you can see there is no way of plugging in anywhere…