Kit Kai's Tech Blog

Restriction when customizing Sharepoint

Different ways of customising sharepoint

SharePoint products and technologies facilitate collaboration within an organisation and with partners and customers. Users can easily create, manage, and build their own collaborative web sites and make them available throughout the organisation. However, the default design of SharePoint does not meet the collaborative needs of most organisations. Microsoft has provided us with three ways of customising SharePoint.

Using Frontpage 2003

Customising SharePoint using FrontPage is very simple. It’s like using FrontPage or DreamWeaver to develop your personal webpage. However, when a page is customised using FrontPage, the page becomes 'unghosted', and is no longer connected to the physical file, but lives in the database server. What these means is that SharePoint has created a copy of that page, allowed you to make changes to it, and to save it into the database. The implications are:

• The pages runs under a different security context (safe mode) in which all controls are required to be registered as safe and no server-side scripting is supported.
• Any changes made to the template file are no longer reflected on the unghosted page.
• There is a caching and performance issue as the file has to be retrieved from the database.

Using WebParts

Webparts are controls that you can place on pages that inherits from WebPartPages. They are similar an asp.net control, except that there are certain methods that you need to implement in order to make full use of SharePoint’s functionality. I shall not touch on how to develop one as there are articles in the internet that teach you just that. There is a control which you might want to check out. It’s called the "SmartPart", and it works by taking a normal asp.net usercontrol, and allowing SharePoint to use that as a WebPart.

Using CAML

CAML (Collaborative Application Mark-up Language) is actually a xml document that defines a few things in SharePoint. The most commonly CAML documents that you would amend is onet.xml and schema.xml, which defines the sites and lists respectively.

CAML overcomes the implications caused when using FrontPage, but there are still a few things that you should take note of.

• When you deploy in a server farm environment, you need to make sure that each server is updated manually.
• When you want to customise a meeting workspace, you cannot create additional meeting workspace site definition. You can only do so by modifying the existing one, which means that all your meeting workspaces will have to look the same, minus additional customisation done via FrontPage or WebParts. The cause of this limitation is that SharePoint only recognises a site definition as a meeting workspace when the ID assigned to it is 2[1]. Any other ID is causes SharePoint to recognises the site definition as a team site.
• When you want to customise a picture library, the same limitation that applies to a meeting workspace site definition applies to picture library as well. For SharePoint to recognise a list definition as a picture library, the ID needs to be 109[2]. Any other value will cause SharePoint to recognise it as a document library.

Site Template and List Template

After you customise SharePoint using one of the three methods above, you can save the whole site as a site template, or a list as a list template, and use it to create other similar sites and list. (Document libraries can be seen as a special kind of list). Well, the template is saved in binary format, which means that you can’t customise that template without first creating a site / list based on the template.

I hope this would be useful to you. Any feedback / critics is greatly appreciated.