Customization of Everything SharePoint…
This post is based on another interesting question which I answered over in the MSDN SharePoint – Design and Customization forum. Here’s the question from SLF05:
…basically, the concept of customized vs. un-customized [object within SharePoint] isn’t 100% clear. When it comes to chrome/layout/CSS type files, it’s best to keep [things] un-customized for various reasons which I’ve read a ton of times, but I am wondering, when creating custom columns, custom web parts etc, are those “customized” in the same sense? Is it best to create custom columns and such on development then move them to production via feature rather than create them on the production separately? Or does it not make a difference.
My gut tells me it doesn’t make a difference, but I haven’t read anything that says so or understood the logic enough to make a strong conclusion.
and my answers:
Sort of. Most of the old concern about customizing pages away from the Site Collection came from the unghosting behavior of SharePoint 2003. IN SOME CASES, this *could* cause *some* performance issues. (Note how I am being forceful about this.) I think it became a sort of “urban myth”, as I’ve heard everyone talking about it for so long with no specific evidence. In SharePoint 2007, this isn’t really a concern. All pages live in the DB anyway, and I’ve never seen anyone demonstrate that there are any issues with customization.
What you shouldn’t do is change the “out of the box” files without knowing what you are doing. For instance, editing files in _layouts is usually unsafe, as a hotfix might clobber your changes. (My partner Pete Sterpe just published a blog post about one way to manage this, if you need to do it.) Generally speaking, anything in the file system should stay sacrosanct unless you understand the implications.
As for using features vs. the UI to add custom lists, etc., it’s mainly an issue of deployment. You want to use features if:
- You have written managed code which you want to be able to version, etc.
- You have a rigorous deployment process you must adhere to
- You want to deploy to many places, which would make doing it manually unsafe or tedious
- etc.
What do you think? Am I missing the boat on any of this?
Hi there Marc, head at the point – i also think as you, it seems to be some urban myth or something, likes you destroys something when you customize something here. Lets see this as that the SharePoint functional files should be somewhere (12 hive) untuchable – and everything else, new files or ‘new copies’ of files that lives in the 12, they belong in the SQL. And about performance, i have not seen any affects or difference here about loading time in the real life if could say so. SharePoint asks the database every time a page are requested, if it´s in the filesystem or not so it has to go that way anyway. To keep all this in a good performance we also have the inbuilt cache and ways to to make the right hits at the right databases in the right scenarios. Think you are as always, already in the boat! Keep up your good blogs Marc. // Christian