[Translation] no.9352 SharePoint pages (1): SharePoint page Architecture

[Opening] recently, I have been studying SharePoint technology, built a portal prototype on the Intranet, and made some attempts. Some feature pages need to be created due to some requirements. I started to use Sharepoint to create pages. It took only half a day to understand that the original content pages do not support inlineCodeIn Visual Studio, it was difficult to learn things. SharePoint 2010 Development for Visual Studio 2010 is a very good book. However, I am too bad at English, so I try to read it and view it word by word. I am also tired of thinking about it, especially probably, it is better to directly convert it to other users. It is also a communication. If there is any ambiguity, please correct me. Thank you. The level is limited. I think it is a little better than the translation software. You will give more advice.

Because we only focus on the SharePoint pages section, we have translated this chapter. Because there are many development tasks, and other chapters will be released later, the original chapter contains about 42 pages, therefore, it will be divided into several parts for release. Most of them are original text sentence-by-Sentence Translation. Sorry.

SharePoint Pages INTRODUCTION

Sharepoint is built on ASP. NET, so the SharePoint user interface is completely ASP. NET page. If ASP. NET developers can easily customize and develop SharePoint interfaces. Although SharePoint also provides a powerful user interface framework, it will not go beyond ASP.. net. For example, if you do not like the default webpart page of the navigation structure, you can customize different templates, or you want to integrate existing ASP. NET applications into a Sharepoint website. These application scenarios need to be developed in ASP. NET. This chapter will discuss how to customize and develop SharePoint pages in ASP. NET.

SharePoint Architecture

Before learning how to customize and create a Sharepoint page, let's take a look at the SharePoint architecture. So far, we have learned about Web applications in SharePointProgramBut what is the Web application? In Sharepoint, each web application has its own independent IIS application pool. The application pool is a workflow started by IIS. When running, it returns to the SharePoint page to process received IIS requests.

During the installation process, Sharepoint creates two IIS Web applications. One is the default website set, and the other is the SharePoint Administration Center website. Because two web applications cannot access the site by sharing the same port, the SharePoint Management Center website is usually accessed through the website http: // yourserverurl: portnumber, the default site of another Web application is accessed through the default port at http: // yourserverurl. The web site port of SharePoint central administration depends on the available port of the machine. If you want to create another website set, you need to tell the SharePoint host web application, or you need to create a new Web application to host the new website set.

Now you may want to know why you need to create multiple web applications, instead of creating a collection of all sites in one web application, the key reason for creating a new Web application is that the site content is independent. Each time you create a new Web application Sharepoint, a new content database is created, and all data on the relevant websites and web applications is stored in this content database. If the content of the website set grows too fast or the storage of the content database is restricted, the administrator can store the website set in another new content database, and continue to use the same web application. This is the so-called split content database.

The second important reason for creating a new Web application is security. All web-related website set executions occur in the application pool. If you want to ensure that some code cannot run from other website sets in the same process, you can use different web applications to create the second website set. This ensures that different application pools are executed and two website sets are executed.

A website set, as its name implies, is a collection of SharePoint websites and webpages. For each website set, you can allow different people to manage, permissions can be set for individual users or groups, so that they can separately manage backup website sets, management workflows, website templates, list template, content type, or website list. Think about a company that needs to build a Project Department website and a marketing department website on SharePoint. Not only does each department have different content, but users of engineering websites and marketing websites also use different content. In this case, you will create a project website and a marketing website respectively. Different permission settings can be used to restrict or prohibit marketing personnel from accessing the Engineering website of the engineering department.

The spsite object in the website set represents the server-side object model or the client-side object model on the website. As mentioned above, a website set contains multiple websites and webpages.

So what is the difference between a website set and a website? The website set and the website seem similar from the end user's perspective, because the website set always has a default site associated with it. Create a sub-website to inherit permissions and navigation structure from the parent website. Sometimes, you may not know when to create a new sub-website or a new website set. If you want to learn more about this topic, you can readArticle:
Http://technet.microsoft.com/en-us/library/cc742548.aspx

Spweb objects represent an object model of a Sharepoint website on the server side and a web object of the client object model. As shown in Figure 10-1, a Web application has two website set objects. Both sets create a default website. Of course, when you create multiple sub-sites, there is only one default website.

The last object in the SharePoint system is the page of the website or website set. There are three types of pages in the SharePoint Development Environment: master page, website page, and application page.

The master page provides visual and sensory definitions for Sharepoint pages, such as the ribbon toolbar defined by the master page, Ajax script object manager, and site navigation. Each page uses the same page layout. A page that uses a master page is a so-called content page. The appearance of each content page is provided by the master page. Developers can add different content by extending the replaceable placeholders on the master page. Figure 10-2 shows the relationship between the master page and the Content Page. On the master page on the left, v4.master provides common features for home. aspx and mywebpartpage. aspx.

Sharepoint is built on ASP. NET, so the master page also inherits from the ASP. NET master page, and the master page extension used by Sharepoint is also. master.

The second page type is website page. The webpage is customized through the SharePoint operation interface or design tools, such as SharePoint designer. Most importantly, you need to know that all custom website pages are stored in the content database of SharePoint. All website pages are created and customized by Sharepoint designer. Why is it so important? Think about it. If there are thousands of pages in a Sharepoint scenario, if each page is customized, then all webpages are retrieved from the content database and loaded into the memory. This will have a certain impact on performance and load. However, website page customization provides great help to users and administrators. A good example is home. aspx, the top-level page of the website.

Finally, it is the application page. Like a website page, you can use the SharePoint user interface, functions, and content on the application page. The biggest difference between an application page and a website page is that an application page can be customized and deployed to a file system (rather than a content database) on the web server ). All application pages are stored in the SharePoint configuration storage location {SharePoint} \ template \ layouts. The application pages of any site in the Website access field are included. Settings. aspx, as shown in Figure 10-3. This is the page on which each site authorized user or website set administrator can modify SharePoint configuration from the SharePoint website.

With an understanding of these SharePoint architectures, we will start creating and customizing the SharePoint page in the next section.