Hi Friends, below is quick start FAQ for people who are new to share point. We will warm up some theory in the first two articles and then do some practical on the same lines. I have made a 10 part series for share point and I hope you will enjoy it. This is the first part from the series. Get warmed with the theory first and then rest of SharePoint is a breeeeeze. This section covers sharepoint basics and the walks through how share point works with ASP.NET.
Share point helps team members to connect and exchange information in a collaborative manner. It helps to centralize enterprise information for efficient functioning. For instance below is how a normal organization works. Files and documents scattered in individual PC and data is transported according to custom protocols. The communication protocol for sending these data is also person dependent. Some body would use a email , some body would share a drive etc etc.
Share point unites all the documents in to one centralize place and unifies the data transport mechanism. In one words a central enterprise information portal.
Microsoft has divided share point products in two parts. One is called as WSS (Windows SharePoint services) and the other is MOSS (Microsoft Office SharePoint server). WSS is the platform on which MOSS is built. The WSS part is licensed through Windows 2003 server and it does not cost. MOSS is separate product by itself and it needs licensing and it has a good amount of cost J . WSS is good for small team and small projects. MOSS has extra functionalities in other words value added services. So the choice between WSS and MOSS will depend on budget of the project and the VAS provided by MOSS.
WSS does not work in an isolated fashion. It needs help of two more products IIS (Internet Information Server) and SQL Server.
In order to understand how WSS works with IIS we need first understand the concept of "HttpHandlers and HttpModules".
Using the HttpHandlers and HttpModules request is first passed through the Share Point runtime and then passed to the ASP.NET runtime (aspnet_isapi.dll).
If you open the web.config file of a WSS enabled IIS web application you can see the application run time handlers and modules.
<add verb="GET,HEAD,POST" path="*" type="Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler, Microsoft.SharePoint, Version=188.8.131.52, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
We have highlighted the application runtime module.
<add name="SPRequest" type="Microsoft.SharePoint.ApplicationRuntime.SPRequestModule, Microsoft.SharePoint, Version=184.108.40.206, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
Share point is all about enterprise data. When we talk about enterprise data it looks some as shown in the figure below. In other words grouping and sub groupings of data.
SharePoint extends the IIS web application structure to accommodate the above defined data structure using site and site collections. We will see in the later section how to create site collections.
What is the main advantage of using site collections?
As said previously SharePoint is all about data and data should properly authenticated / authorized to proper users. By defining the structure in site and site collection we can now define roles and responsibilities according to data. For instance in the above figure we will assign all HR user to payroll, recruitment and assessment site. These users will not be assigned to account site collection. Same holds true for accounts user.
So when you design your hierarchy of site and site collection you need to keep in mind the enterprise hierarchy structure and design the same accordingly.
SQL Server is used to store content and configuration information. We have two types of databases one is the content database and the other is the configuration database. We had said previously that content is according to every site. So every site has his own content database. For instance if we have a payroll site and recruitment site they have their own content database. Configuration database is for the entire site as they are used in web farms, site configuration and lot of other things which are generic and common across all the sites.
What is the concept of virtual path provider?
Any project has two parts one is the standard and common part and the other is the customized version. In ASP.NET we have two types of pages for any project one is common ASPX pages and the other is customized ASPX pages. Common pages are stored on file directories while customized versions of pages are stored in content database.
So in other words we need an abstract mechanism by which we can render pages from SQL Server content database and also from the virtual directories. This is achieved by using the virtual provider provided by SharePoint. So for all customized pages virtual provider reads from the content database and passes the same to the ASP.NET runtimes. For all common pages it goes to the directory, parses it and the passes the same across to the ASP.NET runtime.
Virtual provider is an abstraction which loads the page from the content or the file system depending on whether it's customized or common pages and passes the same to the ASP.NET runtime.
What is the concept of ghosting and unghosting in SharePoint?
In SharePoint most of the site pages derive from templates. The custom pages only store the difference between them. The template is loaded in memory and applied to the custom pages on fly. In other words the template is stored in a cache. This definitely brings in performance and flexibility. Flexibility is in terms that when we change the template page it's applied to all custom pages. These pages are loaded from the file system. So pages which are loaded from the file system are termed as ghosted pages.
If the page data is loaded from the content database it's termed as unghosted pages.
As a note let me clarify the concept of document and content table as we are already trying to understand the concept of ghosting and unghosting. As we know that SharePoint stores all pages in the database. Looking from a 50,000 feet it has two tables one is the document table which has the entry of page and the other is the content which has the source code of the ASPX page.
So when a page is requested it first checks in the document table and then goes to the content table to load the page. If it does not find data of the page it goes to the file directory to load the page. This loading is done by ASP.NET runtime himself. But if there is data present in the content table then it's loaded by the 'safe mode' parser.
What is the concept of safemodeparser in ASP.NET?
As said the previous section there are two tables one is the document and the other content. If the page is stored in the content database it's loaded by the SafeModeParser which is page parser provided by SharePoint. If there is no data found in the content it's loaded from the file directory by simple ASP.NET runtime.
What is the concept of Site pages and Application pages?
Site pages are customized pages and are saved in to content database. So when you use the SharePoint designer to make custom changes it saves the changes in to content database. If you want to make generic pages in a site collection which will be used by every one, like for instance the 'Settings.aspx' page then you need to use application pages.
In other words Site pages are nothing but customized pages stored in content, while application pages are generic pages which will be used by all the sites in a site collection.
In part two we will try to get hands on share point, create site collections, create application pages and understand the concept of features.