Localizing Content Query Web Part XSL templates

It’s great to know that the Content Query Web Part (CQWP) is there whenever you need to provide a roll up of some content. Delivering a solution of similar experience, possibilities and flexibility would be really time consuming. Unfortunately there are still some things inside the CQWP which could be improved. Let’s take for example localizing the XSL used for data presentation: do we really have to create a different template for every language or is there a better way?

Alternative display order in Content Query Web Part

Content Query Web Part (CQWP) is a great solution for content aggregation: not only thanks to its high performance but to the XSLT-based output rendering as well. And while XSLT is very powerful, many beginning SharePoint developers experience it as an obstacle and are more likely to provide custom aggregation solutions instead of using the standard components provided with SharePoint. In this article you will find out how you can alter the standard display order of the aggregated content using nothing more than the standard Content Query Web Part and a little bit of XSLT.

Generating list instances XML using Imtech ListInstance Generator

This week I learned the hard way that the FeatureId attribute of the ListInstance element must contain the ID (GUID) of the Feature which has provisioned the particular List Definition. Although I’ve provisioned lists using Features dozens of times, this one sneaked up on me and took me more than an hour to figure out. To prevent it from happening ever again I’ve decided to create a tool which would make working with ListInstance element even easier.

Setting the right value of the FeatureId attribute for ListInstance

Setting the correct value for the FeatureId attribute of the ListInstance element is just one of things you can easily overlook on a sunny Friday afternoon when your mind is already enjoying the weekend. It’s like forgetting to read the small letters underneath a contract you’re about to sign: it seems like it all is going to be okay but at the end of the day you’ll be in troubles.

Improving performance of SharePoint solutions by using Cache and CacheDependency

Recently I noticed that the customers ask for more control about the custom SharePoint solutions we deliver. They not only want to be able to customize general SharePoint settings which determine the working of the solution but they want to be able to configure various custom controls as well. Storing custom settings in a list provides the power users a nice interface, yet retrieving these values for each single request is very likely to decrease the overall performance. Is it then a battle between customizable and well performing or is there more to it?