A few weeks ago I presented you a solution for creating dynamic layouts with nothing more than some CSS definitions and a dynamic body id. Using exactly the same HTML markup you can create a different layout of your page elements what makes it an extremely efficient and easy to maintain solution. While the concept is pretty straight-forward, applying it in practice to a real-life SharePoint Server Web Content Management solution has one drawback that you should keep in mind.
SharePoint 2010 ships with support for Linq. The great thing about it is, that Linq simplifies the process of querying lists and working with the retrieved items. Instead of objects, which you get if you’re using CAML, Linq retrieves for you strongly typed objects what makes it extremely easy to work with. And although it seems really perfect there are a few things that you need to keep in mind before you refactor your code to use SharePoint Linq instead of CAML.
About a year ago I wrote about the inconvenience of the SPSecurityTrimmedControl: a great idea within the SharePoint framework that unfortunately doesn’t work the way it should. Now, as we’re about to get a new release of SharePoint, I decided to check if things have changed.
Body id is a cool webdesign trick that allows designers to easily alter the layout of a page using nothing more than a single property and some CSS styling. Using the body id you can define one HTML page structure for the whole site and then, by changing the single value of the body id attribute, you can create new experiences by styling the different pieces of the page in a totally different way. While it sounds very easy and it is very easy with HTML, this trick can get very challenging when used with SharePoint.
Content Query Web Part has been around for a while now and has proven to be a great performing and a very flexible content aggregation solution. In spite of its power it has some shortcomings like for example lack of support for Lookup fields with multiple values.