New releases, Sitecore

Sitecore Rocks – preview the future of Sitecore development

Something really cool happened today!

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:

Standard
New releases, Sitecore, Uncategorized

What TODO – in Sitecore 6.3

Sitecore 6.3 was recently released. A lot of great improvements was included in this version – for instance support for multiple backend web servers and Windows Azure support. Read more about it in Marco Tana’s blog post and read more about the event queue on Adam Conn’s blog.

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?

Standard
.NET, Architecture, Sitecore, Uncategorized

5 worst code smells in Sitecore

Last year I wrote a blog post on doing code reviews on Sitecore. While dealing with conceptual issues it doesn’t really say what to look for in code, when evaluating the quality or to evaluate if any wrong decisions have been made when developing the solution.  Therefore I wanted to wright a post about the top 5 code smells I look for, when I am trying to evaluate or trouble shoot a Sitecore solution. These code smells often indicate that the developers have gone down the wrong road and there is something fundamentally wrong in the architecture.

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?

Standard
publishing, Sitecore

Publishing strategies

Publishing can be quite an issue for content authors and make an impact on performance. However if you use the right strategy, there really isn’t any issues.

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:

Traffic light with timer

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: 

scheduled publish timer

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.

Standard
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
.NET, New releases, Sitecore

Will dynamics in .NET 4 change the way we do Sitecore?

I am spending my time these days walking the halls of Berlin Messe at the Microsoft TechEd 2009. One of the interesting upcoming features of .NET 4 is the introduction of dynamic language support in the .NET Language Runtime. This does not only mean that you can write your .NET code in dynamic languages such as Python (IronPython) and Ruby (IronRuby), but also that you can use some of the dynamic features from C#. With the introduction of the dynamic type keyword, method calls and member access can be evaluated at runtime instead of at compile time (previously known as late-binding). This does not mean that C# is no longer a type safe language, it merely means that the language now provides a more “syntax correct” way of accessing those dynamic types of data, we previously used to access via strings, invokation, reflection etc. Examples of dynamic data models includes COM, the HTML DOM and XML.

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:

TryConvert

A cast is attempted, trying to convert the dynamic type to a static.

TryGetIndex

An indexer is called, trying to get a value with a given id or index.

TryGetMember

There is an attempt to get the value of a named member (e.g. a field or property)

TryInvokeMember

A method with a given name and parameters is invoked.

TrySetIndex

There is an attempt to set the value in an indexer with the given id or index.

TrySetMember

There is an attempt to get the value of a named member (e.g. a field or property)

 

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.

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