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