New releases, Sitecore

Looking forward to Sitecore in 2010

2009 has brought some really nice features and enhancement to Sitecore and has in my point of view really moved Sitecore succesfully to the Enterprise segment. 2009 has also been a year with great focus on feature richness and business value in the product, e.g. by targeting marketing divisions even more. From a developer point of view, 2009 has been a more meager year, although OMS and the rules engine are interesting additions. Below, I have compiled a list of topics, where I would love Sitecore to make headway in 2010. The list is nowhere near complete and is as always my personal opinion. Sadly I have no crystal ball to tell me what Sitecore really focused on.

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.

Standard
Architecture, Sitecore

Dedicated image server and Sitecore

A lot of sites which have a large amount of visitors use a dedicated image server.  There are several reasons for this, but mostly it is because that most browsers only allow a few simultaneous connections to the same domain, which stalls the download of a page that has more than two resources. For instance imagine you have a page consisting of multiple images, stylesheets and javascript files. As the clients only allows a few simultaneous downloads, the browser won’t download all the resources at the same time, but wait for each download to complete and first then start the next download.

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 🙂

Standard
Sitecore, XSL

Reference to templates

The last couple of weeks I have stumbled on several people referring to a specific template when developing XSLT’s or in some other code. Even Sitecores standard XSL does it:

<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’,.)]”/>

Standard