Back to basics : 5 All about onet xml

The global Onet.xml file defines list templates for hidden lists, list base types, a default definition configuration, and modules that apply globally to the deployment. Each Onet.xml file in a subdirectory of the %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\SiteTemplates directory can define navigational areas, list templates, document templates, configurations, modules, components, and server email footers that are used in the site definition to which it corresponds.

When Microsoft SharePoint Foundation is installed, several Onet.xml files are installed—one in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\GLOBAL\XML that applies globally to the deployment, and several in different folders within %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\SiteTemplates. Each file in the latter group corresponds to a site definition that is included with SharePoint Foundation.

Depending on where an Onet.xml file is located and whether it is part of a site definition or a web template, the markup in the file does some or all of the following:

• Specifies the web-scoped and site collection-scoped Features that are built-in to websites that are created from the site definition or web template.
• Specifies the list types, pages, files, and Web Parts that are built-in to websites that are created from the site definition or web template.
• Defines the top and side navigation areas that appear on the home page and in list views for a site definition.
• Specifies the list definitions that are used in each site definition and whether they are available for creating lists in the user interface (UI).
• Specifies document templates that are available in the site definition for creating document library lists in the UI, and specifies the files that are used in the document templates.
• Defines the base list types from which default SharePoint Foundation lists are derived. (Only the global Onet.xml file serves this function. You cannot define new base list types.)
• Specifies SharePoint Foundation components.
• Defines the footer section used in server email.

You can perform the following kinds of tasks in a custom Onet.xml file that is used for either a custom site definition or a custom web template:

• Specify an alternative cascading style sheet (CSS) file, JavaScript file, or ASPX header file for a site definition.
• Modify navigation areas for the home page and list pages.
• Add a new list definition as an option in the UI.
• Define one configuration for the site definition or web template, specifying the lists, modules, files, and Web Parts that are included when the configuration is instantiated.
• Specify Features to be included automatically with websites that are created from the site definition or web template

You can perform the following kinds of tasks in a custom Onet.xml file that is used for a custom site definition, but not in one that is used for a custom web template:

• Add a document template for creating document libraries
• Define more than one configuration for a site definition, specifying the lists, modules, files, and Web Parts that are included when the configuration is instantiated.
• Define a custom footer for email messages that are sent from websites that are based on the site definition.
• Define custom components, such as a file dialog box post processor, for websites that are based on the site definition.

Back to basics :4 Sharepoint config files

I always excited about the SharePoint product team's vision on the way they aligned multiple moving parts to achieve the business objectives of the product. One of the main things in that context is the configuration entity. SharePoint configuration settings exist at several levels. As in all ASP.NET applications that use the integrated pipeline, 

• some fundamental settings are in the machine.config file, 
• the global web.config file, and 
• the applicationhost.config file, which is the IIS configuration store. 

SharePoint makes no changes in the default versions of the first two files. It does make some changes in the IIS configuration store. Each IIS website and, therefore, each SharePoint web application, can have a web.config file in its root folder. This file is substantially customized by SharePoint whenever a SharePoint web application is created. 

SharePoint also takes advantage of the fact that web.config files can be applied to specific virtual or physical folders within a web application. For example, SharePoint puts a web.config file in the virtual directory _layouts\mobile (which is mapped to the physical directory %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS\MOBILE\). Among other things, the web.config file registers a series of filters that control how a page is rendered, based on the capabilities of the mobile device that has requested the page.

Farm-wide configuration settings are stored in the SharePoint configuration database on the computer that is running SQL Server in the farm. Configuration for specific types of websites is contained in various kinds of XML files, such as the Onet.xml file, and configuration for specific instances of websites is contained in the content database. In addition, several classes in the SharePoint object model have property bags that can be used to store custom configuration information for specific objects, such as objects that represent websites, Features, alerts, and files.

Right SharePoint 2013 APIs for your needs – A ready reckoner

SharePoint products team amazes me every time they introduce a product version release. There are several options available when it comes to access SharePoint 2013 using APIs. Per my understanding the following will be the factors that decide which option to use

• Type of customization like web parts, Silverlight App, SharePoint App Page, timer job and more. All these customization are different in most aspects and choosing right API option would eventually decide its eventual success
• Enterprise governance rules will be the key differentiator in deciding the API option.
• Development skill level is the other factor. Expertize in a the technologies like .NET Framework, Silverlight, PowerShell, JavaScript, ASP.NET, REST/OData will ensure the best development practices are applied in design / development of custom components
• Devices we are targeting like farm server, client computer, mobile devices etc. The customization targeting different device should use appropriate API option.

Let me share a high level mapping based on the current info ...

API Option	Custom Component
Server Object Model	PowerShell script for farm / web app maintenance, tracking etc
	Timer job to perform scheduled actions on web app
	Web Parts to be displayed in sites
Silverlight client object model	Web Parts to be displayed in sites
	SharePoint  App
	Silverlight Application that integrate with SharePoint site data
	ASP.Net web application that integrate SharePoint site data
REST/Odata Endpoints	ASP.Net web application that integrate SharePoint site data
	SharePoint  App
	HTML/Javascript application that consume SharePoint site data
	App for office
	LAMP web application that integrate SharePoint site data
	iOS/Android app for mobile devices that access SharePoint site data
Javascript APIs	Web Parts to be displayed in sites
	ASP.Net web application that integrate SharePoint site data
	SharePoint  App
	App for office
	HTML/Javascript application that consume SharePoint site data
.Net Client Object Model	.Net application that consume SharePoint site data
Mobile Silverlight API	Silverlight app for windows phone
	XNA app for Windows Phone

more to follow...