Sitecore MVP event at Dreamcore Europe 2010

Dreamcore Europe 2010 - Sitecore MVP event

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.
Sign up now for the Sitecore Dreamcore MVP event
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.


Content and presentation separated – part 2

Following up on my previous post about content and presentation separation , I realized that separating presentation and content is extremely important, if you want to utilize some of the new features in Sitecore such as the page editor and the new rule engine . These features let the end user meddle with the presentation which gives quite a few nice features. For instance an editor can add a rendering to a given page in a rich and intuitive GUI and set up rules for a visualization of a certain rendering.

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.


Sitecore Continuous Integration Continued

Here’s an update on the post I wrote a year ago on our Continuous Integration project here at Pentia.
To put it short: it’s turned out to be one of the most successful internal projects in our company. In the last year we’ve added 20+ new projects into the system, and we are in the process of moving our old projects from SourceSafe to SVN, and creating build files for them.
Our setup is not a conventional build setup with specifically designed build scripts for a major project, it’s more of a build framework for the many Sitecore project passing through Pentia. We’ve designed our setup around our naming and location best practises, so in order to add a project to the build system, we only need to create a single file with about 10 lines of XML specifically for the project.

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.


Code reviews on Sitecore

Thomas Eldblom and I are reviewing most of the projects, we do in Pentia. The most of the things we comment on concerns C#, architecture, HTML, XSL or other general technologies, but some issues are related to the use of Sitecore. In this post I want to share the most common, most severe or most irritating issues/pitfalls I often stumble upon or look for, when doing a code review. I am glad to say, that I almost never stumble upon the most basic things, such as layouts specified directly on items, masters set on masters (SC5) etc.

·         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.


Introducing the Lucene Index Viewer

I have earlier complained about Sitecore 6 Lucene implementation hard-coding compression, making it impossible to view the index in Luke. Further I have often wanted to view an index in production, where a Luke installation wasn’t allowed.

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!


Microsoft TechEd EMEA 2008

Jens and I from the Pentia Core team are going to attend the Microsoft TechEd 2008 conference in Barcelona, 10-14 November. Over 200 sessions of tech talk over 5 days – who could wish for more:-)
(Plus we’ve also managed to get tickets for FC Barcelona vs. Valladolid at Camp Nou – I’m soo excited!)

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.

Sitecore, Uncategorized, XSL

XslExtensions be gone – part 2

As described in part one of my post, we at Pentia have for some time had a bad feeling about the XSLT extensions concept introduced by Microsoft in the XsltTransform class and implemented further in Sitecore. We feel that XSLT’s belong in the UI tier (in a traditional n-tier architecture) and XSLT extensions has a tendency to introduce a mix of UI and business layer functionality and limited by the type restrictions in XSLT.

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):

  <!-- ... -->
    <!-- ... -->
      <!-- ... -->
      <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:

  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"
    exclude-result-prefixes="sc codebehind">
    <!-- ... -->
    <xsl:template match="*" mode="main">
      <!-- ... -->
      <a href="?p={codebehind:GetNextPageIndex(.)}">
        <!-- ... -->
      <!-- ... -->

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.