.NET, Documentation, New releases, Sitecore

Sitecore learning portal launched

My cooworker Jimmi Lyhne Andersen and I are glad to announce that we have finally finished a project we have been working on for quite a while now; a complete learning site for Sitecore. Check it out at http://learnsitecore.cmsuniverse.net/

 

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.

Standard
Uncategorized

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.

Standard
Architecture, Sitecore

Command templates – the forgotten feature of Sitecore 6?

I don’t know about you, but I actually haven’t been giving command templates any attention since they were introduced in Sitecore 6. This is really a shame, as it is pretty powerful and can help editors a lot.

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.

Standard
debugging, Sitecore

Performance debugging Sitecore backend

In Pentia we have created a new service – Pentia Professional Services, where we offer our deep knowledge of and experiences with Sitecore. The purpose of this service is a bit like Sitecore Professional Services. We offer to help clients and partners with architecture, codereviews, performance testing and debugging Sitecore solutions. To differentiate us from Sitecore Professional Services we focus on the custom solution, where Sitecore focuses on the product.

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.

Standard
Sitecore

Sitecore serialization for version control

As described in the latest post about Continuous Integration we have been working on making it easier and less manual to have multiple developers work on the same project in different environments. However one thing that has always been a challenge is Sitecore items in form of templates, layouts etc. Until now we have run on a shared database server, making updates to Sitecore from a shared server to avoid data cache issues. This has a couple of disadvantages:

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

Standard
Uncategorized

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.

Standard
Uncategorized

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!

Standard
Architecture, Sitecore

Content and presentation separated – Does it make sense?

Often I hear that Sitecore separates content and presentation completely – In fact it seems that it is a key selling point. Lately I have also seen other CMS vendors promote the same idea. But I must admit that I don’t understand why it seems to be so important. Is it because of reuse of content? Is it because you want to be able to present the same content on different devices such as iPhones, PDAs etc.?

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?

Standard
Sitecore

Sitecores Lucene integration

I have always been fond of Sitecores use of Lucene to index. I often use Lucene to relational operations avoiding iterating over the complete content tree etc.

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!

Standard
Sitecore

What TODO?

When developing solutions and you stumble upon an issue, you want to return to, it is a good idea to mark this with some kind of TODO tag. We normally do this in a comment and then browse it with the TODO-explorer in Resharper.

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

Standard