|
|
|
|
|
|
|
|
Managing the Code When Customizing SharePoint
Robert Bogue 6/9/2008
Go to page: 1 2 3
Printer Friendly Version Determining the Difference Between Code and Content You may have noticed that the list of code items and the list of content items don't represent everything that is in SharePoint. There are some major gaps between the two. It's already been mentioned that some items may start out as content and then be converted into code to allow them to be more easily deployed in a consistent manor. Let's take a look at that list: Generally speaking it's a good idea to deploy master pages via Solutions and Features. Content Types -- particularly those used for Web Content Management should also be deployed via Solutions and Features. Page Layouts which are designed for cross site use fall into the category for deployment -- and thus should be treated as code -- as well. Similarly Themes are good candidates for Solution deployment since the point of a theme is a consistent experience between sites. It does get a bit sticker when we start to talk about Web Part Pages because sometimes you just need another page in the database. In other cases you want the page to appear on a whole set of sites. If it's a one off, the page can certainly stay in the content database as content, however, if it's a part of a solution that already includes code, it might be best to wrap the web part page up into the Solution and Feature and to use that for deployment. Navigation is the final difficult to classify component of the SharePoint configuration landscape. In many ways, Navigation is built up from the data that's in SharePoint so it's a function of the content. However, it is possible to deploy some navigation via code. Again this would typically happen when you're already deploying code solutions and the objective is to add that code solution to the navigation tree. However, because it's bundled with a new application it's unlikely that anyone would misconstrue one type of navigation for another. Smashing Code and Content Together By viewing the problem from the perspective that content rolls backwards from production and code rolls forward from development you have the ability to smash code and content together in a QA environment so you can perform real-world testing before you get into the critical production environment. Being able to find issues in QA will lead to a more stable production environment and fewer emergency deployments of new code.
Go to page: 1 2 3
Printer Friendly Version
|
Intranet Journal's Tutorials |
|
Managing Editor |