Site Definition vs. Site Template
1. Requires admin access to server
2. Supports features stapling
3. Files on disk
4. Can provision multiple webs
5. Relatively complex
Site Template:
1. Installable from web UI by site owners
2. Additional features must be activated in gallery
3. Files in DB
4. Single web only
5. Relatively simple
There are two confusing terms in MOSS 2007, site templates and site definitions.
A site template is a .stp file which contains only the difference of changes from the
Original site definition. A user wants to install a custom .stp file must have a site
Definition installed from which the .stp file was saved.
(Note: In MOSS B2, you can only save top level sites. i.e. site collection as a site
Template. This is a bug and will be corrected in B2TR.)
A site definition on the other hand is a complete definition with a directory structure
Containing .aspx files and important Onet.xml file.
We will create here a simple site definition which when applied shows a custom webpart
On page.
The site definitions are stored in this directory
\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates
Each site definition needs an entry in webtemp*.xml file which are located here
\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1033\XML
Site definitions vs. Site templates
- Site definitions have to be updated by a developer or administrator with some XSLT or CAML knowledge
- Site templates can be created easily
- If you update a site template (e.g. change the column type) none of the lists based on it will update – whereas for site definitions they will. Only certain aspects based on site definition – will update – e.g. add/changing/removing views will not
| Site Definitions Vs. Site Templates |
This is really a common source of confusion among SharePoint developers. The fact that site definitions are located in a folder named SiteTemplates multiplies the confusion.
Before going into direct comparison, let me define both:
Site Templates : Are snapshots of sites at a point in time. When a user customizes a site from the UI or SPD, the custom template consists of the difference between the original state of the site (determined by its definition) and the state of the site or list when the custom template is generated.
Custom templates remain tied to a particular site definition (for example, the site definition for SharePoint Web sites or Meeting Workspace Web sites), so that if the site definition is not present or is changed, the custom template cannot work.
Site Definitions : As the name implies, A Site definition is "core definition of a site”. Each site definition emerges through a combination of files that are placed in the 12 hive of WFE during installation of SharePoint. Site definition files include .xml, .aspx, .ascx, and .master page files, as well as document template files (.dot, .htm, and so on), and content files (.gif, .doc, and so on).
Now to the fun part, the comparison :
Site Definitions | Site Templates |
Files are on disk, better performance. | Files are in database, less efficient. |
Highly customizable and extensible (XML and .NET code is much more flexible than UI) | Not easily extensible (You are limited by what UI offers) |
Can provision multiple webs * | Can only provision one web |
Complex to create | Easier to create |
Requires admin access to server for deploying. | Installable from a Web UI by site owners. |
Modifying the site definition after provisioning at least one site from it is not supported and might break existing sites. | Custom templates can be modified without affecting existing sites that have been created from the templates(**). |
* This could be achieved using Provisioning handler (For more info, refer tohttp://spcodesnippets.codeplex.com )
** Please note that If the site definition on which the custom template is based does not exist on the WFE, the custom template does not work.
On the surface, it appears that a site template has numerous advantages over site definitions; it is certainly easier to create and deploy, and you can change it without breaking sites that use earlier versions of the template because it is not centralized in the 12 hive.
However, the fact that a site template contains everything about a site in a single file makes granular modifications of individual elements very difficult. For many projects, that is a good enough reason to suffer the additional complexity of site definitions.
However, site definitions present a different challenge. If you change an existing site definition in the 12 hive, you run the risk of breaking any sites that were created previously and use the existing definition. (Besides, this is not supported by Microsoft ) , The key is to adopt the same strategy as for the core WSS site definitions:
Keep the definition as simple as possible and use feature stapling for everything else. Feature stapling allows you to add a feature to an already existing site definition. You may think this would be a complete waste of time, because you can simply add the feature into the site definition using far less code than having a feature staple, but when I tell you that
Microsoft does not support modifying a site definition in any way after a single site has been provisioned from that site template, you may reconsider.
Features are not an alternative to site definitions. Features are a complement to site definitions. If you keep the site definition as simple as possible and use features for the majority of a site elements, you gain the benefits of granular control in the development environment while reducing the risks involved in making changes to production systems over the life of the sites.
For more information, I would recommend Building SharePoint User Experience by Bjorn Furuknap.
No comments:
Post a Comment