Right after I posted my last article on using Page Layouts for dynamic body ids and issues that you stumble on, I got one more idea on how you might leverage Page Layouts for setting dynamic body ids and still deliver a great performing solution.
If you’re working with SharePoint 2010 solutions that deploy assemblies to BIN the right way (with CAS policies that is), you might have noticed that an error occurs during the deployment of the WSP to SharePoint with the new Visual Studio 2010 SharePoint Developer Tools.
While creating custom branding for SharePoint it is not only important that it looks all right, but also that it’s fully functional and that users don’t loose any of the standard functionality provided with the platform. While most elements can be easily positioned within Master Page and Page Layout some are positioned more “indirectly”. Knowing how SharePoint does the positioning can help you deliver a great User Experience.
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.