Pro Office 365 Development, Second Edition (2014)
APPENDIX A. SharePoint Primer
This appendix is intended for anyone who is fairly new to the SharePoint technology. I’ll give you a brief description of the various types of objects that are used to implement a SharePoint solution. In a very loose sense, SharePoint can be thought of as a database where the “tables” are the lists and the “rows” are the items you put in the lists. Because SharePoint also provides the visualization of this data, presentation aspects are considered at every level in the “database” design.
Note Most of the figures included here were taken from the SharePoint Designer, a client application that is used to customize a SharePoint site. You can also modify these same objects using web pages within SharePoint itself. The user interface is a little different but the concepts are the same.
The basic building block is the column, which holds a single piece of information.
Note Columns are also referred to as fields. In the SharePoint object model, columns are accessed through the SPField class. SharePoint Designer calls them columns. So you will see the terms column and field used interchangeably.
Each column definition must include the column type, which specifies both storage and presentation details. Figure A-1 lists the available column types.
Figure A-1. Column types
Notice that there are two text types: one for a Single Line of Text and another for Multi Lines of Text. A single line text field is used for shorter fields, like Name. A multi-line text field will take up more space on the form (you can specify the default size) and has additional display options. Figure A-2 shows the column editor for a Multi Line of Text column.
Figure A-2. Multi-line text field settings
One of the particularly interesting features of the multi-line column is the append option. If you select the Append Changes to Existing Text checkbox, the text entered in that field is appended to the existing contents. This is often used on a comments field. If the item is edited multiple times, the comments are appended at the end of the previous comment, giving you a running history of all the comments.
A multi-line column can also support rich text formatting and even pictures. Contrast this to the settings for a Single Line Text column shown in Figure A-3.
Figure A-3. Single-line text field settings
Date & Time Columns
When defining a column you can also specify a default value. For example, when creating a Date & Time column you have an option to default to the current date and time or a fixed date, as shown in Figure A-4.
Figure A-4. The date & time column settings
Notice also that you can choose to display the value as a date only or as both date and time. This only affects how the data is displayed, not how the data is actually stored.
Person or Group Columns
If you use a column type of Person or Group, the edit form will use a PeoplePicker control. You’ll use this control a lot and it’s a very useful way to select users, ensuring only valid choices are allowed. The column editor shown in Figure A-5 illustrates the settings you can use to configure how this control works.
Figure A-5. Person or Group column editor
You can also use these settings to determine what attribute of the user to display. By default this is the account or login name. However, you could display the name, e-mail address, phone number, or whatever is appropriate for your application. You can also control which users or groups are allowed and if multiple people or groups can be selected.
The Choice type is another interesting column type. You’ll use this when you want to provide fixed values for the allowable options. The column editor for a Choice field is shown in Figure A-6.
Figure A-6. Choice column type editor
When defining the column, you’ll specify the available options in the Choices list. You can decide how the choices are presented. There are three options.
· Drop-down list
· Radio button
· Check boxes
Select the Allow Fill-in choices check box if you want the users to enter a value other than one of the pre-defined choices.
The Choice type should not be confused with the Lookup type. A Choice column has a fixed set of allowable values. Often, however, you’ll want to restrict values to a dynamic list. The Lookup type allows you to do this by specifying another list as the source of the allowable values.
For example, the Parent Request column, shown in Figure A-7, references the ID column of the Request list. This means that this column, if not empty, must contain an ID that exists in the Request table. If the Allow blank values? check box is not selected, this column cannot be empty.
Figure A-7. Lookup column type settings
You must first choose the list to be used for the lookup. You’ll then select the field that will be stored in the new column. This is typically an ID field or some other unique identifier. You can also select additional fields that will be displayed on the form.
Lookup columns are the mechanism that you’ll use to ensure referential integrity. In database terms, this is equivalent to a foreign key relationship. By defining a Lookup column, you ensure that selected values are valid. This also improves the user interface. The user can search for the record using any of the additional fields that you specify.
A Calculated column allows you to define a column with a formula that includes the values of other columns. A sample is shown in Figure A-8.
Figure A-8. A calculated column
In this example, the Request Status and Title columns are concatenated to form a new column.
Task Outcome Columns
We demonstrated the use of a Task Outcome column in Chapter 4. This is used by workflow forms to influence the subsequent processing when a task is completed. In the example column shown in Figure A-9, the possible outcomes are defined as:
· Completed - the request is completed and can be closed
· On Hold - the request is not completed and follow-up work is still required
· Need Info - the request must be sent back to the user that requested it, in order to provide more information
Figure A-9. A task outcome column
A Task Outcome column is configured just like a Choice column but has special meaning for the workflow process.
Site Columns Collection
SharePoint provides a set of column definitions referred to as Site Columns. These are defined as independent pieces of information that you can assemble into your own custom lists. You can use any of these existing columns when creating a list. Site columns are organized into groups. You can also define new site columns and new groups to help organize them.
When creating a list you also have the option of creating a new column that is only used by that list. The difference is in how the column is created. In the first case, the column is created, added to the Site Columns collection, and then added to the list. In the second case, the column is created and added to the list. It requires an extra step to create reusable column definitions.
In SharePoint, the mantra is “Build once, use often.” A column definition should be reused wherever appropriate. This means taking the extra step to define the column first and then add it to the list. But it also means carefully considering the design of the column and how you expect it to be used. Keep in mind that if you change an existing site column, every place that it is used will change. This can be a good thing if used properly. Give your columns meaningful names and descriptions that explain the intended use. When choosing an existing column, don’t just look for one with the correct column type. Make sure the description matches how you’re planning to use it.
Content types define a reusable collection of properties and are used throughout SharePoint. One use of content types is to define the items (rows) that are contained in a list or document library. A content type specifies a collection of columns. To control how the field is displayed in the form, columns can be specified as either Required, Optional, or Hidden. For example, the columns included in the Task content type are shown in Figure A-10.
Figure A-10. The columns included in the Task content type
For each content type, you can specify a custom form to be used. SharePoint uses the following three forms for each content type:
· New: Used when creating a new item.
· Display: View-only form used to display an item.
· Edit: Used to modify an item.
Content types support inheritance, which means you can derive a new content type from an existing one. The new content type will inherit the columns and properties of its parent content type. The base content type is Item and all other contents are derived (directly or indirectly) fromItem. The Document content type, which is derived from Item, is the root type for all document libraries.
Lists and Libraries
If content types represent the things in a SharePoint site, lists are the containers they are stored in.
Tip A document library is just a special type of list, so we will often use the term “list” to refer to both.
Supporting Content Types
One thing that is somewhat unique about SharePoint and different from traditional databases is that a list can contain items of different types. For example, the standard Workflow Tasks list that was created in Chapter 4 allows the content types shown in Figure A-11.
Figure A-11. Content types supported by the Tasks list
This is a really handy feature. For instance, a document library can contain different types of documents. The Tasks list is another good example. This allows you to have a single Tasks list that contains different types of tasks. This was demonstrated in Chapter 4.
You can also create a new list and add columns to it without using content types. In this case, a content type definition is inferred from the list definition. This is a quick way to create a custom list.
You can define any number of views for each list. A view usually includes a filter to define a subset of the items in the list. The Tasks list, for example, provides views to show only active tasks or only tasks assigned to the current user. Views can also define a subset of columns that are to be displayed. The views that have been defined for the Workflow Tasks list are enumerated in Figure A-12.
Figure A-12. The views defined for the Workflow Tasks list
View options are best defined using the SharePoint UI, not in SharePoint Designer. A collapsed version of a view definition page in SharePoint is shown in Figure A-13.
Figure A-13. Edit View page
As you can see from the Edit View page, there are a lot of options that you can configure using a view, including sorting, grouping, and subtotals.
You can create subsites on a SharePoint server. Site columns and content types are inherited by all subsites. All the columns and content types that are defined by the home site are also available to any subsite. However, any custom column or content type defined on a subsite is not available on the home site. For this reason, it is best to define site columns and content types at the home (or root) site. Subsites can have their own subsites, creating a hierarchy of sites. Lists are not inherited, however. A Tasks list on one site, for example, is not available to child (or sibling) sites.
Note Columns, content types, forms, and permissions are inherited from the parent site. Lists and content are not inherited. Reusable workflows are also inherited.
When creating a SharePoint site for a large organization, each department will often have their own subsite so they can manage their own lists and libraries. Keep in mind that column and content type definitions are shared across all the subsites. This is why you should give some thought when defining them.
You can create columns and content types at each subsite as well. If a need is unique to a particular department, you may want to consider creating it at that level. If you do, it will not be available to other subsites. If you think other sites may want to use it, create it in the home site.