A workflow allows you to attach a business process to items in Windows SharePoint Services 3.0. This process can control almost any aspect of an item in Windows SharePoint Services 3.0, including the life cycle of that item. For example, you could create a simple workflow that routes a document to a series of users for approval.
Workflows can be as simple or complex as your business processes require. You can create workflows that the user initiates, or workflows that Windows SharePoint Services 3.0 automatically initiate based on some event, such as when an item is created or changed.
Windows SharePoint Services 3.0 workflows are made available to end-users at the list or document-library level. Workflows can be added to documents or list items. Workflow can also be added to content types. Multiple workflows may be available for a given item. Multiple workflows can run simultaneously on the same item, but only one instance of a specific workflow can run on a specific item at any given time. For example, you might have two workflows, SpecReview and LegalReview, available for a specific content type, Specification. Although both workflows can run simultaneously on a specific item of the Specification content type, you can't have two instances of the LegalReview workflow running on the same item at the same time.
WSS 3.0 & MOSS 2007 - WebParts
Web Parts in Windows SharePoint Services provide developers with a way to create user interface elements that support both customization and personalization. A site owner or a site member with the appropriate permissions can customize Web Part Pages using a browser or Microsoft Office SharePoint Designer 2007 by adding, reconfiguring, and removing Web Parts.
The term customization implies that changes are seen by all site members. Individual users can further personalize Web Part Pages by adding, reconfiguring, and removing Web Parts. The term personalization implies that these changes will be seen only by the user that made them. Developing custom Web Parts provides an easy and powerful way to extend Windows SharePoint Services sites.
Because the Windows SharePoint Services Web Part infrastructure is now built on top of the ASP.NET 2.0 Web Parts control set, you can reuse your knowledge of ASP.NET programming to create quick and robust custom Web Parts.
Following are some ways in which you can use custom Web Parts:
The term customization implies that changes are seen by all site members. Individual users can further personalize Web Part Pages by adding, reconfiguring, and removing Web Parts. The term personalization implies that these changes will be seen only by the user that made them. Developing custom Web Parts provides an easy and powerful way to extend Windows SharePoint Services sites.
Because the Windows SharePoint Services Web Part infrastructure is now built on top of the ASP.NET 2.0 Web Parts control set, you can reuse your knowledge of ASP.NET programming to create quick and robust custom Web Parts.
Following are some ways in which you can use custom Web Parts:
- Creating custom properties you can display and modify in the user interface.
- Improving performance and scalability. A compiled custom Web Part runs faster than a script.
- Implementing proprietary code without disclosing the source code.
- Securing and controlling access to content within the Web Part. Built-in Web Parts allow any users with appropriate permissions to change content and alter Web Part functionality. With a custom Web Part, you can determine the content or properties to display to users, regardless of their permissions.
- Making your Web Part connectable, allowing Web Parts to provide or access data from other connectable Web Parts.
- Interacting with the object models that are exposed in Windows SharePoint Services. For example, you can create a custom Web Part to save documents to a Windows SharePoint Services document library.
- Controlling the cache for the Web Part by using built-in cache tools. For example, you can use these tools to specify when to read, write, or invalidate the Web Part cache.
- Benefiting from a rich development environment with debugging features that are provided by tools such as Microsoft Visual Studio 2005.
- Creating a base class for other Web Parts to extend. For example, to create a collection of Web Parts with similar features and functionality, create a custom base class from which multiple Web Parts can inherit. This reduces the overall cost of developing and testing subsequent Web Parts.
- Controlling the implementation of the Web Part. For example, you can write a custom server-side Web Part that connects to a back-end database, or you can create a Web Part that is compatible with a broader range of Web browsers.
WSS 3.0 - Content Types & Site Columns
Windows SharePoint Services 3.0 provides two new tools to help you organize and standardize your data: content types and site columns.
Content Types
Content types—a core concept used throughout the functionality and services offered in Windows SharePoint Services 3.0—are designed to help users organize their SharePoint content in a more meaningful way. A content type is a reusable collection of settings you want to apply to a certain category of content. Content types enable you to manage the metadata and behaviors of a document or item type in a centralized, reusable way.
For example, consider the following two types of documents: software specifications and legal contracts. It is reasonable that you might want to store documents of those two types in the same document library. However, the metadata you would want to gather and store about each of these document types would be very different. In addition, you would most likely want to assign very different workflows to the two types of documents.
Content types enable you to store multiple, different types of content in the same document library or list. In the preceding example, you could define two content types named Specification and Contract. Each content type could include different columns for gathering and storing item metadata, as well as have different workflows assigned to it. Yet items of both content types could be stored in the same document library.
You can further extend content type functionality by using content types to assign additional settings, such as workflows or even custom attributes, to your items.
Because you can define content types independently of any specific list or document library, you can make a given content type available for the lists on multiple SharePoint sites. This enables you to centrally define and manage the types of content you store in your site collection. For example, you could use your Specification content type to ensure that all software specifications track the same metadata, even if those specifications are stored across multiple sites.
Content types are independent of file formats. For document libraries, you can specify a document template; when the user requests a new document of this content type, Windows SharePoint Services creates a document based on the template. However, users can still upload a document based on a different template, or even of a completely different file type.
Site Columns
Site columns provide a central, reusable model for column definition. When you create a site column, each list that uses this column has the same definition, and you do not have to do the tedious work of reproducing the column in each list.
A site column is a reusable column definition, or template, that you can assign to multiple lists across multiple SharePoint sites. Site columns decrease rework and help you ensure consistency of metadata across sites and lists. For example, suppose you define a site column named Customer. Users can add that column to their lists and reference it in their content types. This ensures that the column has the same attributes, at least to start with, wherever it appears.
Additionally, site columns provide you with the simplicity of a single maintenance point. For example, you can create a status site column, which might contain multiple choices of an enterprise's specific statuses, and implement the column in dozens of project master lists across the site collection. If you add a new status, you can modify the site column instead of having to modify each list that contains a status column.
Much like site content types, you define a site column at the site level, independent of any actual list or content type.
When you add a column to a list, Windows SharePoint Services copies the site column locally onto the list as a list column. You can then make changes to the list column; these changes apply to the column only as it behaves on that list.
In certain situations, you may want to modify the column for a specific list. For this reason, you still have the option of one-off customization of columns at the list level. For example, suppose all projects within your company's Information Technology department have an additional status of On Hold—Waiting for Hardware. You could add this status to the column within the IT department's master project list.
You can also create your own list columns, directly on a list. Either way, list columns apply only to the list to which you add them; they cannot be added to multiple lists.
You can reference a site or list column in a content type.
Content Types
Content types—a core concept used throughout the functionality and services offered in Windows SharePoint Services 3.0—are designed to help users organize their SharePoint content in a more meaningful way. A content type is a reusable collection of settings you want to apply to a certain category of content. Content types enable you to manage the metadata and behaviors of a document or item type in a centralized, reusable way.
For example, consider the following two types of documents: software specifications and legal contracts. It is reasonable that you might want to store documents of those two types in the same document library. However, the metadata you would want to gather and store about each of these document types would be very different. In addition, you would most likely want to assign very different workflows to the two types of documents.
Content types enable you to store multiple, different types of content in the same document library or list. In the preceding example, you could define two content types named Specification and Contract. Each content type could include different columns for gathering and storing item metadata, as well as have different workflows assigned to it. Yet items of both content types could be stored in the same document library.
You can further extend content type functionality by using content types to assign additional settings, such as workflows or even custom attributes, to your items.
Because you can define content types independently of any specific list or document library, you can make a given content type available for the lists on multiple SharePoint sites. This enables you to centrally define and manage the types of content you store in your site collection. For example, you could use your Specification content type to ensure that all software specifications track the same metadata, even if those specifications are stored across multiple sites.
Content types are independent of file formats. For document libraries, you can specify a document template; when the user requests a new document of this content type, Windows SharePoint Services creates a document based on the template. However, users can still upload a document based on a different template, or even of a completely different file type.
Site Columns
Site columns provide a central, reusable model for column definition. When you create a site column, each list that uses this column has the same definition, and you do not have to do the tedious work of reproducing the column in each list.
A site column is a reusable column definition, or template, that you can assign to multiple lists across multiple SharePoint sites. Site columns decrease rework and help you ensure consistency of metadata across sites and lists. For example, suppose you define a site column named Customer. Users can add that column to their lists and reference it in their content types. This ensures that the column has the same attributes, at least to start with, wherever it appears.
Additionally, site columns provide you with the simplicity of a single maintenance point. For example, you can create a status site column, which might contain multiple choices of an enterprise's specific statuses, and implement the column in dozens of project master lists across the site collection. If you add a new status, you can modify the site column instead of having to modify each list that contains a status column.
Much like site content types, you define a site column at the site level, independent of any actual list or content type.
When you add a column to a list, Windows SharePoint Services copies the site column locally onto the list as a list column. You can then make changes to the list column; these changes apply to the column only as it behaves on that list.
In certain situations, you may want to modify the column for a specific list. For this reason, you still have the option of one-off customization of columns at the list level. For example, suppose all projects within your company's Information Technology department have an additional status of On Hold—Waiting for Hardware. You could add this status to the column within the IT department's master project list.
You can also create your own list columns, directly on a list. Either way, list columns apply only to the list to which you add them; they cannot be added to multiple lists.
You can reference a site or list column in a content type.
Subscribe to:
Posts (Atom)
