Developing Web Content Management (WCM) solutions on the Microsoft Office SharePoint Server (MOSS) 2007 platform was really challenging. And I’m not talking here about taking care of delivering web standards compliant XHTML, implementing accessibility or making the website lightning fast. I’m talking about the development process itself: from creating the very first custom Site Column to deploying the Solution. There were several tools, none of which fully integrated with Visual Studio or provided a consistent approach. At the end of the day we – SharePoint 2007 developers, became wizards doing the magic of manual tips & tricks and combination of various tools every day just to get the job done. Just recently, when SharePoint 2010 shipped, Microsoft provided us with the new Visual Studio 2010 SharePoint Developer Tools. And although they are called tools, they are more than that. In fact Microsoft provided us with a framework for building developer tools. A new era has come.
SharePoint 2010 ships with a new User Interface framework that allows you to easily create rich user experiences. While developing custom solutions one of the challenges is to communicate long-running operations with the user: after all there is nothing more annoying than a non-responsive UI. Find out how the new UI framework of SharePoint 2010 supports communicating the progress notifications to users.
SharePoint 2010 ships with a brand new Rich Text Editor which has a dozen of new capabilities. One of those capabilities allows you to insert Web Parts in content which can help you add some rich functionality to your content. And while it sounds pretty cool there are scenarios when you might want to turn inserting Web Parts in content off. In this article you can read about how you can disable inserting Web Parts in the SharePoint 2010 Rich Text Editor.
Recently I’ve been working on a SharePoint solution that was persisting some state information. Originally this solution was relying on Session State but because of some extra configuration complexity that using Session State with SharePoint requires we decided to replace the Session State with cookies. Although both approaches are not exactly the same they were both sufficient in the scope of the solution. And although you might expect no rocket science when working with ASP.NET cookies there are a few things that keeping in mind might save you some painful hours.