In the first part of this series I spoke about the requirements for the project. The primary issue that we were dealing with was how we were going to approach the development pieces (site definitions, list definitions, master pages, custom site columns etc…). We first thought that we would bake all of this into our site definitions which would be easily accomplished through modifications of the ONET.XML file of our custom site definition. But this would leave our client up the creek without a paddle if they decided in the future to make changes to our custom work. They would actually have to open up the custom site definition and make changes to an ONET.XML file that is being used by other sites that have already been created. Can you say very very dangerous and not a good idea.. J!So what if you can update a modular component that the ONET.XML file references without actually touching the blue print file where all the custom publishing sites get their base configurations from (ONET.XML). Welcome to the new world or semi-new world of MOSS 2007 feature development boy did this make life a WHOLE lot easier. In the next couple of pages I am going to talk about the different pieces my team looked at during the implementation. Also why we chose to either directly build these pieces into the site definition or wrap them up into features. List Definitions and Custom Site Columns My first task was to build my custom site column(s) and build them into my custom list definition. Once these were built and wrapped up into features I can then directly reference them via their unique ID’s within the ONET.xml of my custom publishing site definition. I would then repeat the same process for my custom document libraries. Behind the scenes SharePoint actually treats document libraries like any other list. For example the code snippet below is from the ONET.xml <Configurations> node which is where you can declare which lists you would like to be created when the site is provisioned.
<Lists><List FeatureId="00BFEA71-2062-426C-90BF-714C59600103" Type="103" Title="$Resources:core,linksList;" Url="$Resources:core,lists_Folder;/$Resources:core,links_Folder;" /><List FeatureId="00BFEA71-E717-4E80-AA17-D0C71B360101" Type="101" Title="$Resources:core,shareddocuments_Title;" Url="$Resources:core,shareddocuments_Folder;" QuickLaunchUrl="$Resources:core,shareddocuments_Folder;/Forms/AllItems.aspx" />
</Lists>
The highlighted list feature above is just your OOTB links lists. The list feature below is your OOTB shared documents document library. As you can see they are referenced exactly the same whether they are a list or a document library within the ONET.xml each sporting their own unique “List FeatureId”. The actual development of the custom list definition such as the creation of custom views, settings, and fields are all controlled by schema.xml file and are also addressed in the “YourCustomListDefinition.xml” file that you must include when wrapping up your list definition as a feature. For a good beginning article on creating custom list definitions these articles below should provide some good insight and will go a little bit more in depth as to how to go about creating a custom list definition:http://msdn2.microsoft.com/en-us/library/ms466023.aspxhttp://msdn2.microsoft.com/en-us/library/ms983903.aspx. Custom site columns are best deployed via the creation of a feature. The major reason being is the ability to easily deploy updates to this site column if needed in the future. Whereas in the days of SPS 2003 we had to build our columns into the list definition which were then referenced inside of the site definition. If an update on that column needed to be made it would not affect the lists that were already created and using this column. Now with features my team was able to provide the client with a solution for the short and long term with very little footprint if any updates were needed. The site column can also be changed directly through the web UI once it has been deployed through the feature so this also gives admin another option if small changes were needed to the site column after it was deployed. Within your feature for a site column you will have a “CustomColumn.xml” where you can define the attributes for your custom column. This file will contain the unique field ID which is highlighted below. For example when defining a custom site column within your “CustomColumn.xml” it will look something similar to this:
<Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <Field ID="{464e12ed-ff2e-4247-3468-e69342f9ef96}" Name="MyCustomColumn"
SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Custom Site Column Name" Group="Custom Site Column Group" Sealed="TRUE" Type="Note" DisplayName="Custom Column Display Name that will be shown" Sortable="FALSE" Description="Useful description for users adding new items to your custom list" UnlimitedLengthInDocumentLibrary="TRUE" AllowDeletion="TRUE" ShowInFileDlg="FALSE">
</Field>
The highlighted field ID you will have to keep track of when implementing it within your custom list definition. This is because you will have to reference your custom column within your list definitions schema.xml. The good news is that your schema.xml will be stored within your FEATURES directory so you don’t have to go hunting for it when and if changes/updates need to be made. Those of you from the SPS 2003 days should remember that absolute horror of trying to update a custom list definition with small changes in an environment with multiple custom site definitions that this list was being used by. Especially if you made a change to one then forget which one you changed….hunting through multiple 2000 line schema.xml files…..hmmmm I wonder who has done that before!The purpose of this blog entry was to not get into the technical details of creating a custom list definition, site definitions, and custom features but to explain my thoughts on when is better to build features or build directly into site/list definition. So I am not going to give you a step by step on creating custom list/site column/content types. If you are looking for a step by step on this refer to Ari Bakkers’ blog article here: http://blogs.provoke.co.nz/Ari/archive/2007/04/18/creating-a-custom-sharepoint-2007-list-definition.aspx . Now that I have my list definition complete with my custom columns I now have to wrap this list definition up into a feature. I would like this list to not only be used by my custom site definition but also would like this list to be available to be created by other sites within the site collection. This link will give you a good head start on exactly how to accomplish this task via a feature: http://msdn2.microsoft.com/en-us/library/ms466023.aspx . T
The decision was made to wrap our list definition and custom site column inside a feature because:
· It made our custom list available at whatever level we wanted (web, site collection, farm)
· Our custom list could be reused throughout the entire implementation
· The custom list could be updated/changed without touching the actual site definition files
· The custom site column can be referenced and reused in other custom site definitions If you look at the C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES directory you will find that almost every single list/document library has been deployed OOTB through features. This modular approach gives a lot more flexibility when your customer would like to reuse components within your implementation. What I like best about this approach is that everything is defined in one group of files that are easily identifiable if changes need to be made. This is a much cleaner approach compared to having to open up the ONET.XML file that current sites may be built off of or creating a whole new site definition when changes must be made to the list definition that is defined inside of the ONET.XML. I hope that I did not jump around too much while trying to get my point across. Being a SharePoint developer means having a pretty deep set of skills and knowing the ins and outs of the product. One thing is for sure and that is feature deployment once understood is making our lives a bit easier in some aspects J.
In the next and final part of this article I am going to talk about page layouts and its counterpart master pages and how and why went about developing/deploying these pieces. The article will mainly focus on creating custom page layouts, publishing site definitions and the decisions we made around deploying them via features. Your questions and comments are always welcome as I realize there may be better ways to go about doing this than the approach my team took.
Cheers!
Posted
08-13-2007 5:09 PM
by
Jason Medero