SharePoint is pretty darn big. It's so big in fact that figuring out where to get started almost inevitably ends up leading you down a rabbit hole.
Now I'm not about to try to explain everything that SharePoint is in a single post. But I AM going to try to tell you (IMHO) what simple SharePoint constructs you should understand before you start developing/working on it.
SharePoint 2007 Glossary
Lists are the containers in which SharePoint stores data. Pretty much everything in SharePoint is stored in a list. From all the pages you create, to all the CSS in the Style Library, all the Master Pages...all stored in Lists. Lists aren't just important because they're so prevalent. A lot of SharePoint's functionality is derived from the fact that all content is stored in a list of some sort. On every list you can get all of the following:
- Check in/out behavior
- Outlook Synchronization
- Views (different ways of viewing data including filtering/sorting)
- Security (can be redefined for each list)
- Policy (how long we keep things until we delete them/kick of some process)
- Default (and customizable) Add/Edit/View forms for adding items.
Lists store one or more types of Content Types (will be explained later). Each item that you put in a list has a content type, the default content type is Item. It's important to note that lists can store multiple kinds of Content Types, this allows a list to store many different types of data under the same roof. For instance, a realtor might use a list to store both Listings and Offers in the same SharePoint list. He would create two content types (Listings and Offers) and add them as different content types the list can store. He would break them up since Listings and Offers have different metadata requirements.
A site column is a lot like a column you might have in a database table. It has a name and a data type. SharePoint works at pretty high levels so the data types aren't int, float, real, varchar etc.. Instead they're a lot more high level like: Picture, Rich HTML, Single Line of Text, Currency, etc... The data type of the Site Column is called the Field Type and you can create your own if you have a type which is not represented by WSS out of the box.
A content type is a collection of Site Columns grouped together to define an item that you would like to store.
Example. Lets say I wanted to store information about vehicles and I decided to store them all in a List. First I would create a list. I would note thought that I may want to track different types of metadata about different types of vehicles though. It's kind of silly to track information about trunk space when we're talking about motorcycles, but for passenger vehicles that's probably information I might care about. I would create various Site Columns for tracking the types of meta data (horsepower, model name, weight, FWD/AWD/RWD, etc...). I would create these as Site Columns. I would then create different Content Types (Motorcycle, Passenger Vehicles, Commercial Trucks, etc...) that tie these Site Columns together and correctly describe the item I'm trying to store. Finally I would add these different Content Types to my list. When a user visits my list and clicks New, they will see all the different kinds of Content Types they can add to this list. Based on the Content Type that they choose to add they will be asked to input different information. It's important to note that each Content Type can have it's own New/Edit/Display form. This is important since most content types will use completely different fields (Site Columns) from each other.
Web Applications, Site Collection and Site
Web applications are really a IIS Web site and application pool. When you create a new Web Application in the WSS Central Administration you will have to specify either a port or host header, and application pool for the Web App to run under. At this point there's still no site though.
You actually create something that a user can use when you create a Site Collection in the web application based off of some Site Definition. A Site Collection contains a single root site which can have any amount of child sites. You can alter security, enable/disable features, anonymous access and many other things at the Site Collection level. By default these settings bubble down into the Site Collection's sub sites.
Sites are groupings of lists, workflows, pages, master pages, pages layouts and other WSS constructs that make up a usable web site.
It's important to note that a single Web Application contains one or more Site Collections which as one or more Sites which contains many Lists that have one or more Content Types (the default of which is Item) which group together multiples Site Columns to define an object for storage. Wow, what a mouthful.
Site Definition and Site Template
A Site Definition is a grouping of lists, features, settings, style sheets, themes master pages and a bunch of other stuff that define a web site. An example of a site definition would be Team Site, Publishing Site with Workflow, or Blank Site. You need to choose a site definition when you create a new Site Collection or a new Site.
A Site Template is a customized Site Definition. Site Templates are usually used to save small changes done to a Site Definition so that they can be reused over and over again. For example, lets say your company liked the Team Site Site Definition but wanted to make some small changes (add a couple lists, some default content etc...). You could save these changes as a Site Template and then create new sites based on this Site Template.
It's important to note that a Site Template is just a collection of delta's. They also run slower than a site definition and cannot be used if the Site Definition on which it's based is not on the server (because of this they're less portable than Site Definitions).
Ok that ended up being quite a bit longer than I expected. I hope that shed some light on some of the nomenclature that you'll see decorating most WSS discussions.