SharePoint 2010 Training, Part 1: The Building Blocks

SharePoint 2010 Training, Part 1: The Building Blocks

by | Jan 14, 2011 | SharePoint 2010

Over the years as SharePoint has grown its features into the platform that we love and appreciate, it has also grown in complexity. Even for a technical person like myself, understanding the different aspects of SharePoint has become a daunting job.

So I asked myself, is it really that complex or there is there something else to it?

I thought about this for a while, and came to the realization that it’s really just the buzzwords that people use around SharePoint that tend to throw me off. But in the end, the core of SharePoint is actually not complex at all and is, in fact, very straightforward.

In this and subsequent blog posts – using simple language –  I will traverse the SharePoint landscape in small steps, where I will look into SharePoint building blocks, how they are used to build an application (i.e., how to build Web-based collaborative solutions) and what has evolved in SharePoint 2010.

If you have worked with SharePoint in the past, then you already know that SharePoint is geared towards increasing office productivity. Its core strength is in providing a centralized repository for documents and information for people to collaborate on.

But have you ever wondered how it’s possible for software to capture our working patterns? In other words, how can someone build a software application that knows how I work, what my information structure looks like, or how I need to manage my documents, etc.? Perhaps you guessed it – it doesn’t know. I have to define them instead.

How do I tell SharePoint what I want to manage?

Well, let’s start looking into SharePoint’s building blocks. These are the basic elements that let us “define” and “manage” the information, “build” the interface and “share” the information with others. These building blocks are flexible and can be easily used to build a Web application that meets my needs.

Let me list the core blocks and what they are first, and then I will take a closer look at each of them:

  • Site
  • Page
  • Web Part
  • List

 

Site

In SharePoint, the “site” has two faces. For the casual user, it’s an ordinary website URL. You type the URL in the browser and get to a site where there are Web pages and links that let you move around the website.

With SharePoint though, it is a single point where users are authenticated, groups and people work together, workflows can be initiated, Microsoft Office business solutions can be integrated to manage information and application services (search, Excel etc) can be attached to extend its usefulness. In other words, a site is an entry point to a Web-centric collaboration application. It provides a necessary context to apply business rules and a container to hold application-specific Web pages, data, users and the like together.

You will need at least one site to start using SharePoint, and design there will be one site created at the end of a SharePoint installation. And if you are curious, under the hood it’s just a Web application running under IIS.

 

Page

A Page, on the other hand, is an ASP.NET Web page. It provides HTML base user interface that resides inside a SharePoint site. The page will also serve to build website layout with navigation links, banners, menus and, most importantly, pages to display and manage data. Sites that are created SharePoint will have at least a Web page to begin with.

 

Web part

In simple words, a Web Part is a special, pre-built ASP.NET control or widget that can be added to a SharePoint page from the browser to build a better user experience. In a SharePoint page, we add Web Parts to build navigational systems, tabs, menus, forms to create and manage data, views to display tabulated data, and much more. The best part is if out-of-the-box Web Parts don’t meet your needs, you can always build (or buy) one and use it with other Web Parts seamlessly.

 

List

So far we have looked at three building blocks that help us create a site and site layout. A List, on the other hand, is a mechanism through which we create and manage data in SharePoint.

For an average user, a List looks like a spreadsheet or database table, even though it fits the paradigm. But from a SharePoint perspective, a List has three aspects.

First it let me define the data structure that I want to manage. For example, I can create a contact list with name, address, and phone columns. Or a task list with description, assigned to, and due date columns, and manage them all through SharePoint.

Second, it works as a container or a subfolder under a site where all the ASP.NET pages related to managing and viewing my data is stored (edit forms, list view, etc.).

Third, it provides a context to fine-tune user access, associate workflows, and apply publishing rules (check-in, check-out, versioning etc.).

Why are these building blocks important?

To appreciate their significance, let me step back in time and look at how we would have developed a Web application to manage – my contacts, for example – without SharePoint. Just remember that I am in a small company and would like to share my customer contacts with rest of the group. What could be a better way than a Web application?

Here are some common steps that I could have taken to share my contacts:

  1. Create a table in database with appropriate columns to hold the needed data.
  2. Use C# classes to interact with the database data (data access layer with ADO.NET).
  3. Create a user interface using HTML and ASP.NET controls (presentation layer).
  4. Use C# to create a business logic layer – this acts as the glue between #2 and #3.
  5. Create a Web application in IIS to host the Web pages.
  6. Update web.config with connection strings so my Web application can access the database.
  7. Import data – use a database import tool to bring in my contacts.
  8. If I want to control who has access to my contacts, I need to write a membership provider again in C# and configure it in IIS.

 

These are pretty standard steps in developing a dynamic Web application. They’re also quite cumbersome, and unquestionably beyond the average user’s capabilities. Not to mention the time that it would take to build such an application.

SharePoint shines here as it empowers the end user. By abstracting the whole process mentioned above, sharing the information is reduced to matter of few simple clicks.

Now let’s see what I would have done if my company was using SharePoint. I still want to share my customer contacts with my group.

  1. By default, I have access to a Web site that is already configured to authenticate users from the company. No action needed.
  2. From Site Actions, create my contact list choosing the contacts template (more on templates later). This step will define my data in the database, and create all the Web pages needed to handle and view my contacts.
  3. From my contacts main page, use the List Settings link to control who can access my list.
  4. Using a third party tool, import existing contacts to my SharePoint contact list.
  5. Done!

 

Now we can appreciate the power and the magic of the building blocks. Sharing information within a company (or beyond) can never be the same again.

In my next post, I will explore in more detail the building blocks “templates” – the layer that hides all the tedious work behind the scenes – that SharePoint provides out-of-the-box and what has changed in the recent release of SharePoint 2010.

Meanwhile, please give me your thoughts on the question I posted above.

 

Useful links:

Get a Demo
Contact Us
Newsletter Signup