SharePoint アプリケーション構築の概要

重要:  この記事は機械翻訳されています。機械翻訳についての「免責事項」をお読みください。この記事の英語版を参照するには、ここをクリックしてください。

この記事の内容

はじめに

使用したツールとテクノロジ

アプリケーションのアーキテクチャと開発の方法論

共通の設計パターンの実装

テンプレートを作成する

まとめ

リソース

はじめに

Windows SharePoint Services 3.0は、共同作業とコミュニケーション サービスの統合、ポートフォリオを提供する Windows Server のテクノロジです。Web ベースのビジネス アプリケーションの開発プラットフォームもできます。この機能を活用、Microsoft が図 1 の例に示すように、ヘルプ デスクを調整するか、マーケティング キャンペーンの追跡などの特定のビジネス プロセスのニーズに対応する既定のソリューションを提供するアプリケーション Windows SharePoint Services 3.0 のテンプレート 40 に提供します。

Integrated Marketing Campaign Tracker アプリケーションのホーム ページの表示
図 1: 統合マーケティング キャンペーン追跡アプリケーションのホーム ページ ビュー

これらの無償でダウンロード可能なアプリケーション テンプレートは、展開後すぐに使用できるように設計されています。また、お客様やパートナーの方は、これらのアプリケーション テンプレートを、カスタマイズされたソリューションの土台として使用したり、Microsoft Office SharePoint Designer 2007 を使用して独自の洗練された Windows SharePoint Services 3.0 アプリケーションを構築するための見本として使用したりすることもできます。

この記事の目的が他のでは、Microsoft 開発方法のアプリケーション テンプレートWindows SharePoint Services 3.0およびOffice SharePoint Designer 2007、独自のアプリケーションを作成するのには、促さ顧客やパートナーの目標の内部で主要な機能を使用する方法についてのベスト プラクティスを識別するについて説明します。この記事は、 Windows SharePoint Services 3.0 SDKに代わるものではありませんについてもは主に開発リソース。開発者は、一般にWindows SharePoint Services 3.0を拡張する方法を理解するため、SDK を使用する必要があります。

この記事は、新しいタイプのサイト デザイナー向けのリソースとなるように記述されています。Windows SharePoint Services と Office SharePoint Designer 2007 により、多くのアプリケーション機能を UI から構築できるようになったため、機能豊富なアプリケーションを構築するために高度な開発スキルは必要なくなりました。確かにこの記事では、特に手の込んだ設計パターンに対応するユーザー設定コードの実装について説明していますが、全体的な方法論は開発者以外のユーザーにも理解できる内容となっており、そのような読者を念頭に置いて書かれています。開発者の方は、前半のツールと方法論に関する部分は簡単に目を通すだけにして、設計パターンの説明および設計パターンを実装するための具体的な例の部分を集中的に読んでもかまいません。

記事の構成としては、最初のセクションの「使用したツールとテクノロジ」で、アプリケーションの構築に使用される Windows SharePoint Services 3.0 および Office SharePoint Designer 2007 の機能の概要を示します。次のセクションの「アプリケーションのアーキテクチャと開発の方法論」では、すべてのアプリケーション テンプレートの開発にあたって Microsoft が使用した方法論の概要を説明します。この方法論は、ソリューションの目的、用途、対象ユーザー、およびユーザー設定コードを書かずに最大の効果を上げることができるテクノロジについて真の評価に結びつく常識的なアプローチです。さらに、ユーザー設定コードやその他の特別な作業が必要な領域を特定するためのプロセスを示します。

次の「共通の設計パターンの実装」セクションでは、Windows SharePoint Services と Office SharePoint Designer 2007 の両方の機能を使用して、リストにカスタム アクションを作成する方法など、一般的なアプリケーション設計要件への対処方法を説明します。これは、この記事の中心部分であり、すべてのアプリケーション テンプレート (さらに、実際に作成するアプリケーション) に共通する設計パターンへの取り組みについて説明しています。このセクションでは、5 つの設計パターンのそれぞれについて例を示し、Windows SharePoint Services の UI や Office SharePoint Designer 2007 およびユーザー設定コードを使用するための手順を説明します。

最後の「テンプレートを作成する」セクションでは、Office SharePoint Designer 2007 を使用して実際にテンプレート ファイルを作成する方法を説明します。また、ローカライズなど、その他の問題についても説明します。

この記事を読み終わると、アプリケーションを設計する方法、直接 Windows SharePoint Services 3.0 でサイトの構築を開始する方法 (リンク リスト、カスタム列、ライブラリ、ワークフローなどの作成方法を含む)、Office SharePoint Designer 2007 でサイトを開いて、追加のカスタマイズ作業、ユーザー設定のフォームの作成、特定の動作を変更するためのユーザー設定コードの追加、カスタム ワークフローの作成などを行う方法、さらに、アプリケーション テンプレート自体を作成および展開して使用できるようにする方法について理解を深めることができます。

ページの先頭へ

使用したツールとテクノロジ

アプリケーションをこれまでよりも簡単に作成できるようにするテクノロジおよびツールが数多く用意されています。テクノロジ面では、ワークフローのサポートなどの新機能により、アプリケーションにワークフロー機能を組み込むコードをサイト デザイナーが記述する必要はなくなりました。ツール面では、Office SharePoint Designer 2007、Microsoft Visual Studio 2005、およびその他のツールを利用することで、処理を実行するための煩雑なコーディング作業を大幅に削減できるだけでなく、場合によってはコードの記述がまったく必要なくなります。

全体として、これらのツールとテクノロジ全体にわたって Microsoft が追求してきた方針は、面倒なコーディング作業をインフラストラクチャ自体に組み込むことで、開発者の負荷を軽減して、デザイナーがデザイン作業に専念できるようにすることです。言い換えると、手間のかかるコーディング作業の大部分は既に Microsoft 側で完了しているため、ユーザーは、UI を使った直観的な方法で、これらの機能をアプリケーションで利用するだけで済むようになっています。

さまざまなテクノロジやツールをアプリケーションの作成プロセスで利用する方法を理解できるように、後のセクションでは、Windows SharePoint Services 3.0、Office SharePoint Designer 2007、およびその他のテクノロジについて、関連する新しい機能を中心に説明します。より包括的な説明については、この記事の最後にあるリソースを参照してください。

Windows SharePoint Services 3.0

Windows SharePoint Services 3.0には、いくつかの強力な新機能が含まれています。次の新機能や機能は、カスタム アプリケーションの構築に特にと多くの後のセクションで、もう一度説明が表示されます。

  • ライブラリとリスト    Windows SharePoint Services 3.0 には、新しい種類のライブラリとリストが多数導入されており、アプリケーションを作成するための基盤として使用できます。新しいライブラリの種類には、スライド ライブラリ (再利用可能な Microsoft Office PowerPoint 2007 スライドを格納および管理するための特別なライブラリ)、データ接続ライブラリなどがあります。

  • コンテンツ タイプ     コンテンツ タイプとは、Windows SharePoint Services 3.0 全体で使用される中心概念であり、ユーザーが SharePoint サイトのコンテンツをわかりやすい方法で整理できるように設計されています。コンテンツ タイプは、特定のカテゴリのコンテンツに適用できる設定をまとめて再利用できるようにしたものです。コンテンツ タイプにより、ドキュメントのメタデータや動作、またはアイテムの種類を一元的に管理して再利用できます。たとえば、ワークフローおよびイベントを、複数のドキュメントまたはライブラリに追加する代わりに、コンテンツ タイプに関連付けることができます。

  • サイト内の列    サイト内の列は、列定義に対する一元的で再利用可能なモデルです。サイト内の列を作成すると、この列を使用する各リストに同じ定義が適用されるため、各リストに列を複製していくという面倒な作業が不要になります。サイト内の列を利用することで、エンド ユーザーは、あらかじめ定義された列のセットから、自身のリストで役立つ列を選択できます。サイト内の列を使用すると、既知のリスト テンプレートの列を一元的に定義できるだけでなく、ユーザー設定の意味を持つ特別な列を使用するための手段も提供されます。

  • ワークフロー   Windows SharePoint Services 3.0 では、ワークフローを使用して、ビジネス プロセスをリストおよびライブラリのアイテムに関連付けることができます。このプロセスにより、アイテムのライフ サイクルを含むほとんどすべての面を管理できるようになります。たとえば、一連のユーザーの承認を得るためにドキュメントを回覧する簡単なワークフローを作成できます。通常、サイト デザイナーまたは開発者は、特別なワークフローを作成します。サイト デザイナーは Office SharePoint Designer 2007 のワークフロー デザイナー ウィザード環境を使用して、ワークフローを作成でき、開発者は Visual Studio 2005 を使用して、より強力で複雑なワークフローを作成できます。

  • フィーチャー フレームワーク    Windows SharePoint Services 3.0 には、"フィーチャー" と呼ばれる新しい構造が含まれています。フィーチャーとは、ユーザーが特定の目標またはタスクを完了するのに役立つ Windows SharePoint Services 要素をパッケージ化したものです。フィーチャーには 1 つ以上の要素が格納されます。要素とは、Windows SharePoint Services の概念における最小単位です。Windows SharePoint Services 3.0 のフィーチャーでは、開発者が Windows SharePoint Services ソリューションで独自の機能を実現するために利用できるフレームワーク全体が提供されます。また、フィーチャーにより、管理者は機能の追加と削除をパッケージ単位で簡単に行うことができます。

  • イベント機能拡張    イベントは、次の 2 つの主要カテゴリに分類されます。

    • リスト イベント   リスト アイテムおよびリスト列の変更、追加、削除 (スキーマの変更) を含むコア イベント

    • 単純なサイト イベント   サイトおよびサイト コレクションの削除

      イベントは、同期の "事前" イベント ("XYZing" という形式の名前) か、非同期の "事後" イベント ("ABCed" という形式の名前) のいずれかになります。

  • モバイル デバイスによるアクセス   Windows SharePoint Services 3.0 の新機能により、モバイル デバイスでリストを適切に表示できるようになりました。ユーザーがモバイル デバイスを使用して Windows SharePoint Services 3.0 サイトにアクセスすると、そのサイトのモバイル版に Web ブラウザーがリダイレクトされ、モバイル デバイスに最適な形式でサイト コンテンツおよびリストが表示されます。

Office SharePoint Designer 2007:SharePoint アプリケーションを構築するための主要ツール

Office SharePoint Designer 2007 は、SharePoint の製品とテクノロジ (Windows SharePoint Services 3.0 および Microsoft Office SharePoint Server 2007) を利用して構築された Web サイトおよびワークフローの作成とカスタマイズに役立つように設計されています。IT プロフェッショナルとソリューション作成者が SharePoint ベースのアプリケーションおよびワークフロー ソリューションを開発するために必要なツールがすべて用意されており、組織の機敏性とビジネス プロセスの自動化を推進します。Office SharePoint Designer 2007 を使用すると、以下の作業を行うために、従来の手続き型コーディング言語や手法を使用する必要がなくなります。

  • XML ファイル、SQL データベース (たとえば、Microsoft SQL Server 2005)、Web サービスなどのさまざまなデータ ソースに基づいて、コードなしのデータ ビューおよびフォームを作成する。

  • 動的で洗練された、コードなしのワークフローを作成する。

  • ページのレイアウトおよびデザインを行う。

  • マスター ページを作成する。

  • カスケード スタイル シート (CSS) を編集および適用する。

  • Web パーツ ページを作成し、Web パーツを接続して、洗練されたビジネス アプリケーションを作成する。

Visual Studio 2005

Visual Studio 2005 を使用すると、アプリケーションにユーザー設定コードを追加できるほか、カスタム ワークフローを作成することもできます。Visual Studio 2005 Designer for Windows Workflow Foundation では、ワークフロー テンプレートおよびカスタム ワークフローのアクティビティを作成できます。ワークフローにコードや、ワークフローで使用するデザイン フォームを追加すると、関連付け時や実行時にワークフロー ユーザーとやり取りできます。

Visual Studio 2005 Extensions for Windows SharePoint Services 3.0 は無償でダウンロードすることができ、Visual Studio 2005 を使用してカスタム SharePoint アプリケーションを開発するための一連のツールがバンドルされています。このバンドルには、Web パーツ、サイト定義、リスト定義用の Visual Studio プロジェクト テンプレート、および既存の SharePoint サイトからサイト定義プロジェクトを生成するためのスタンドアロン ユーティリティ プログラムである SharePoint Solution Generator が含まれています。このプログラムを使用すると、開発者は、ブラウザーおよび Office SharePoint Designer 2007 を使用してサイトのコンテンツをカスタマイズしてから Visual Studio 2005 でコードを作成できます。

Windows SharePoint Services 3.0 の Visual Studio 2005 拡張子は廃止されました] は、 Visual Studio 2008 拡張子の Windows SharePoint Services 3.0、v1.3にもアクセスすることができます。

Microsoft Office Access 2007

Microsoft Office Access 2007では、入力、管理、およびデータを対象となるシナリオのレポートのユーザー エクスペリエンスを提供する、追跡アプリケーションを作成することができます。デザイン、作成、および Access テンプレートを共有する方法の詳細については、 「『 Rational ガイドを Microsoft Office Access 2007 テンプレート帳を参照してください。

アプローチおよび一般的な手法

次のセクションで説明する開発手法では、アプリケーションを作成するために以下のような基本的な手順を採用しています。

  1. サイト定義とサイト テンプレートのどちらが必要かを決めます。

  2. Windows SharePoint Services 3.0 または Office SharePoint Server 2007 で中心となるサイトを作成します。

  3. Office SharePoint Designer 2007 を使用してサイトを開き、変更を加えます。

  4. 必要に応じて、Visual Studio 2005 を使用して、追加のユーザー設定コード、カスタム ワークフローなどを作成します。

ページの先頭へ

アプリケーションのアーキテクチャと開発の方法論

どの開発プロジェクトもそうであるように、Windows SharePoint Services アプリケーションを設計および構築する際は、実証済みの方法論に従うことで、成功の可能性を大幅に高めることができます。ここでは、ダウンロード可能なすべてのアプリケーション テンプレートを設計する際に Microsoft が使用した方法論について説明します。ここに記載した方法論は、経験豊富な開発者にとっては目新しいものではありませんが、SharePoint 環境の細部に触れており、Microsoft が学んだ教訓を反映したものとなっているため、その意味では価値があります。前に述べたように、このセクションは、Windows SharePoint Services 3.0 および Office SharePoint Designer 2007 の使用方法を知っている、開発者以外のユーザーに特に役立つ内容となっています。

手短に言うと、この方法論では、まず、アプリケーションで実行する必要がある処理、アプリケーションの対象ユーザーなどについて大まかに検討することから始めます。次に、アプリケーション内でのデータの流れ、データの保管場所、さまざまなデータ間の関係について詳細を検討します。データ モデルおよび使用シナリオを十分に理解したら、Windows SharePoint Services 3.0 でアプリケーションの大まかな形の構築を開始し、おおむね目的の外観と動作になるまで、リスト、ライブラリ、ワークフローなどを反復的に作成していきます。最後に、アプリケーションをビジネス プロセスのニーズに合わせるために微調整とカスタマイズが必要な箇所を特定して構成します。

アプリケーションの機能要件を定義する

Windows SharePoint Services ソリューションを構築する前に詳細な技術仕様書は必要ありませんが、アプリケーションがどのように機能する必要があるかを適切に理解しておく必要があります。これは当然のことのようですが、多くの開発者は、関係者がアプリケーションに求めるものと、ビジネス プロセスが成功するために実際に必要なものとが一致しないことで痛い思いをしています (通常、関係者はほぼ完成したアプリケーションを見たで、このことに気付くのです)。

簡単に言うと、最初に機能要件の収集を開始し、アプリケーションで実行する必要がある処理内容について検討することが大切です。たとえば、プロジェクト進捗管理ソリューションが必要な場合は、少なくとも、以下の点を洗い出す必要があります。

  • ビジネス プロセスのアクターとロールは何か。    この例の場合、プロジェクト所有者はプロジェクトを作成し、タスク、懸案事項などに関する情報を管理します。タスク所有者は、割り当てられた懸案事項とタスクを持っていて、相互にやり取りして各自の仕事を完了する必要があります。管理者は、プロジェクトの全体的な進捗をまとめた情報を表示できる必要があります。

  • さまざまなアクターに必要な UI は何か。    この例の場合、プロジェクト所有者、タスク所有者、および管理者のそれぞれに、各自のアクティビティに関連するさまざまなビューが必要です。たとえば、タスク所有者は自身に割り当てられたすべての懸案事項を表示できる必要があり、プロジェクト所有者は期限切れのすべての懸案事項を表示できる必要があります。

  • どのようなビジネス プロセスなのか。    この例の場合、プロジェクト所有者はプロジェクト、マイルストーン、タスク、および予算項目を作成し、経時的に進捗を追跡します。プロジェクト所有者はあらゆる情報に頻繁にアクセスし、タスク所有者は自身に割り当てられたタスクなどがある場合にデータを処理する必要があります。

  • データの格納場所はどこか。    Windows SharePoint Services のデータのみを使用するのか、(データベース、Web サービス、ビジネス データ カタログなどの) 外部データにアクセスする必要があるのか、Windows SharePoint Services の外部にデータを格納する必要があるのかを確認します。

  • データ間の関係はどうか。    この例の場合、プロジェクト アイテム、マイルストーン アイテム、タスクおよび懸案事項アイテムが必要で、これらは論理的な階層構造を形成します。ユーザー、予算、日数などもデータ要素です。

これらの質問の答えを見つけるには、ホワイトボードに実際にビジネス プロセス全体の図を描いてみて、少しずつ変えて何回か作図を繰り返すのがよいでしょう (いくつかのプロジェクトを作成し、2 ~ 3 人のメンバーにプロジェクトのタスクを割り当てるなど)。概念的には、プロジェクト進捗管理アプリケーションはごく単純な設計であり、要件はこの時点でほとんど明らかになっています。

データ モデルを検証する

データ モデルについては既に説明しましたが、非常に重要な概念なので、詳しく検討する必要があります。データ モデルについて誤解していると、後でシステム全体に対して大幅な変更が必要になる可能性があるため、正しく理解しておくことが大切です。

関連し合う情報が多数あり、特定の情報がビジネス プロセス内のどこに位置するかを記述および定義するメタ情報も多数あることを理解する必要があります。プロジェクト進捗管理アプリケーションの場合、プロジェクト、マイルストーン、タスク、および懸案事項が存在するということだけでなく、もっと多くの情報を把握する必要があります。たとえば、プロジェクトがトップレベルのアイテムであり、プロジェクトに複数のマイルストーンが存在することを認識する必要があります。また、プロジェクトには、複数のタスクおよび懸案事項が存在する場合もあります。

必要なコンポーネントとコンポーネント間の関係を決定する

この時点で、アプリケーションの機能については明確になっています。次に、アーキテクチャを計画して、Windows SharePoint Services 3.0 と Office SharePoint Designer 2007 の各種テクノロジおよび機能をどのように使用するかを決定します。各アプリケーションでは、前の「使用したツールとテクノロジ」セクションで説明した、次のような機能を組み合わせて使用します。

  • リストとルックアップ

  • カスタム リスト ビュー (Windows SharePoint Services の UI によるグループ化、並べ替え、フィルター処理など)

  • ワークフロー

  • Office SharePoint Designer 2007 のカスタム ページとカスタム データ ビュー

リストとルックアップでは、実際にデータ モデルを実装します。このため、プロジェクト進捗管理アプリケーションの場合は、プロジェクト用のリスト、(プロジェクト リストへのルックアップ フィールドを持つ) マイルストーン用のリスト、(プロジェクト リストへのルックアップ フィールドを持つ) 懸案事項用のリストなどが必要です。カスタム ページ ビューについては、進捗状況でのグループ化や状況別での並べ替えができる既定のビューを設定するだけでよい可能性があります。

まとめとして、ここでもう一度、ホワイトボードを使ってアプリケーションの簡単なモデルを作成し、各コンポーネントで使用するテクノロジを確認します。

アプリケーション コンポーネントの構築を開始する

この時点でも、厳密な技術仕様書は必要ありません。基本的なデータ フローと UI 要件についてよく理解しているのであれば、重要なのは、実際に構築を開始することです。

実際には、Windows SharePoint Services 3.0 ですぐに利用できるテンプレートのいずれかを使用して新しいサイトを作成するか、または独自のサイト テンプレートを先に作成し、そのテンプレートに基づいて新しいサイト インスタンスを作成することになります。多くのアプリケーションは、チーム サイト テンプレートまたは空のサイト テンプレートを元にして作成できます。

プロジェクト進捗管理アプリケーションの場合、最初に行うことは、4 つのリスト (プロジェクト リスト、プロジェクト タスク、プロジェクト懸案事項、およびプロジェクト マイルストーン) を作成することです。次に、この 4 つのリストそれぞれについてユーザー設定の列を作成します。Windows SharePoint Services 3.0 を使用すると、[選択肢]、[数値]、[ユーザーまたはグループ]、(このサイト上の情報の) [参照] など、さまざまな種類の列を作成できます。図 2 に示すように、Microsoft のプロジェクト進捗管理アプリケーション テンプレートのプロジェクト リストでは、さまざまなユーザー設定の列が使用されています。

リストのカスタム列
図 2:リスト内のユーザー設定の列

たとえば、Health 列は [選択肢] の種類の列、Budget 列は [数値] の列 (通貨を使用) です。

プロジェクト マイルストーンのリストでは、[参照] 列を使用することで、プロジェクトとマイルストーンとの間に親子型のリレーションシップで関連付けが行われています。参照列を作成するには、図 3 に示すように、単に参照先のリストを選択し、そのリストから列を選択します (Windows SharePoint Services によって自動的にドロップダウンが作成されます)。

他のリストから情報を取得するためのルックアップ列の定義
図 3: 参照列を定義して別のリストから情報を取得

この時点で、一部のアプリケーション ロジックを組み込み、新しいプロジェクトが作成されたときにメンバーに通知するための簡単なワークフローを作成できます。Windows SharePoint Services の UI を使用して、目的に応じて並べ替えやフィルター処理を行うことで、リスト内にカスタム ビューを作成する作業を開始することもできます。

アプリケーションに必要なカスタマイズを決定する

機能的には、Windows SharePoint Services の UI だけで、プロジェクト進捗管理アプリケーションの大部分の実装は完了しています。この時点で、Windows SharePoint Services の UI で機能しているものの問題がある領域や、機能していない領域などがわかります。次のような領域については、Office SharePoint Designer 2007 を利用する必要があります。

  • ワークフロー内のアプリケーション ロジック    Windows SharePoint Services 3.0 および Office SharePoint Server 2007 にあらかじめ用意されているワークフローでは、タスクの割り当て先のユーザーまたはグループを指定する必要があります。この例のプロジェクト進捗管理アプリケーションでは、懸案事項またはタスクの所有者プロパティに基づいて、ワークフロー アクションの受信者を動的に決定する方法が必要です。Office SharePoint Designer 2007 を使用すると、このソリューション用にコードなしの動的なワークフローを作成できます。

  • ダッシュボードおよび管理者ビュー    すべてのプロジェクト、すべての予算などの統合ビューを表示するための方法が必要です。コードなしのデータ ビューを簡単に構築して、結合して統合された情報をダッシュボードに表示できます。

  • 親子型のリレーションシップ   タスクを作成する際の使い勝手に関する問題がいくつかあります。表示しているページに応じて、タスクが特定のプロジェクトに既定で設定されるようにすると便利です。Office SharePoint Designer 2007 を使用して、アイテム間のリンクの作成を自動化するロジックを追加できます。

Microsoft では、40 種類のアプリケーション テンプレートを作成する際に同じ反復型の手法を使用して、Windows SharePoint Services 3.0 の機能を使用して実行される操作と Office SharePoint Designer 2007 やその他のツールを使用して実行される操作を最適化するために、一貫したベスト プラクティス、デシジョン ツリーなどを備えた一貫した手法を策定しました。次のセクションでは、これらの手法について説明し、5 つの "設計パターン" とその実装方法を、多数のアプリケーション テンプレートの例を示しながら解説します。このため、この後の説明は、方法論の説明よりも技術的に詳細で高度な内容となっています。

ページの先頭へ

共通の設計パターンの実装

このセクションでは、5 つの基本的な設計パターンを示し、Microsoft がこれらの設計パターンを実際にどのように使用したかを説明します。テンプレート全体からいくつかの異なる例を示し、コード例や手順についての説明も適宜行います。このセクション以降では、主に開発者向けにアプリケーション テンプレートを実際に作成する方法を説明しますが、開発者以外のユーザーにも理解できるように書かれています。

まず、設計パターンには、次の種類があります。

  • ユーザー設定フォーム    ビジネス プロセスの一定の時点におけるアクションのガイダンスを示すユーザー設定の外観を作成します (これには、特定の段階で変更可能なプロパティ、または関連するプロパティのみを公開することが含まれます)。

  • アクション フロー    それぞれのアクターを適切な場所に導くための明確なアクションを定義します (このためには、実行するアクションおよびそのアクションを実行するアクターに応じて選択される優れたナビゲーション コントロールが必要です)。

  • 親子型のリレーションシップ    ルックアップと参照のために複数の SharePoint リスト間のリレーションシップを作成します。

  • ワークフロー    Office SharePoint Designer 2007 を使用して、Windows Workflow Foundation ベースのビジネス プロセスを作成します。

  • ダッシュボード    Web パーツを使用して、サイト内のさまざまな場所に分散している情報を 1 か所にまとめた統合ビューを作成します。

ユーザー設定のフォームを使用する

ユーザー設定のフォームは、Windows SharePoint Services のデータ入力ユーザー インターフェイスをカスタマイズする上で重要な役割を担います。カスタム リスト ビューを使用するとリスト データをさまざまな方法で表示できるように、ユーザー設定のフォームを使用すると、ユーザー入力をさまざまな方法で収集できます。ユーザー設定のフォームを作成する必要性は、ビジネスのニーズに応じて、さまざまな理由から発生します。

タスク ベースのカスタマイズ

ビジネス プロセスでは、ユーザーはプロセスのさまざまな時点でビジネス データに影響する特定のアクションを実行する必要があります。優れたビジネス プロセスは、プロセスの各段階で適切な情報をユーザーに表示することで、ユーザーが容易に作業できるようにします。

Windows SharePoint Services には、既定で各リストに編集フォームが用意されています。ただし、このフォームでは、ビジネス プロセスの特定の段階に最適なフィールドが表示されるとは限らず、必要なアクションが明確になるような方法でフィールドが配置されるわけでもありません。必要なアクションを実行する際にユーザーが適切な情報を編集しやすくするように、各アクションについてユーザー設定のフォームを作成できます。

バグ追跡ソリューションでは、カスタム編集フォームを使用して、バグ追跡プロセスの各段階でバグ アイテムに対して入力する必要がある情報がすぐにわかるようにします。バグ追跡プロセスにおけるそれぞれのアクションには、独自のフォームがあります。たとえば、ユーザーがバグを解決することを選択すると、解決ページ (Resolve.aspx) に転送されます。このページでは、バグの解決方法と、バグを解決したユーザーの名前を入力できます。ユーザーが [解決] をクリックすると、変更内容が送信されます。これにより、使いやすく、エラーや入力漏れのないアクション フローを実現します。

Office SharePoint Designer 2007 を使用すると、次のように、比較的簡単にカスタム編集フォームを作成できます。

  1. 既定の EditForm.aspx のコピーを作成し、名前を変更します。

    重要: このプロセスの最初の手順として、既定の EditForm.aspx のコピーを作成し、名前を変更するのは重要な作業です。元の EditForm.aspx ページに対して手順 2. を実行すると、リストが壊れて修復できなくなります。

  2. 新しい編集フォームからリスト フォーム Web パーツを削除します。

  3. 公開するデータを含むデータ ビューを挿入します ([挿入] メニューの [SharePoint コントロール] をクリックし、[ユーザー設定のリスト フォーム] をクリックします)。

  4. [挿入] メニューを使用した方法では、Office SharePoint Designer 2007 によってフォームに [Save] ボタンが自動的に作成されます。次のコードは、[Save] ボタンのカスタム HTML の例を示しています。

<input type="button" value="Save" name="btnSave" onclick="javascript: {ddwrt:GenFireServerEvent('__commit;__redirectsource')}"/>

ナビゲーション

ロールに対応するページを作成したら、関連するダッシュボードにユーザーがすばやくアクセスできる方法を用意します。イベント企画ソリューションでは、XSL テンプレートを使用して、現在のユーザーのロールに基づいて、適切なダッシュボードへのリンクが作成されるようにしました。

この方法の場合、ソリューションにロールを追加し、ロールに合わせたユーザー設定のダッシュボードを用意するためには、追加の .aspx ページを作成しなければならないという制限事項があります。

この方法では、サイトの情報へのアクセスを制御する追加のコントロールは追加されないことに注意してください。理論的には、任意のユーザーが、ソリューション内の任意の情報を引き続き表示できます。

ユーザーにロールを割り当てる

ロールを作成し、ユーザーに割り当てるための方法は複数あります。どの方法が最も適しているかは、個々のアプリケーションや組織の要件によって異なります。Windows SharePoint Services には、ロールを割り当てるための方法はあらかじめ用意されていません。サイトを展開した後にロールを用意するか、必要に応じてユーザーが自分でロールを割り当てればよい場合もあります。

イベント企画ソリューションでは、ユーザーは、自分に最も適したロールに登録できます。これは、[イベント企画] ワークスペースのトップ ページにあるカスタム Web パーツで行います。

この設計パターンのその他の例

別のサーバー管理者がユーザー設定フォームを使用する例、 Windows SharePoint Services 3.0 のアプリケーション テンプレートを貸出を参照してください。

サイト管理者の例では、 Windows SharePoint Services 3.0 のアプリケーション テンプレートを製造プロセス管理を参照してください。

アクション フローを制御する

ビジネス プロセスをモデルとした実際の Web アプリケーションが単一の Web ページまたは Web パーツ内に収まることはまれです。通常は、複数のコンポーネントにまたがり、それぞれのコンポーネントがビジネス プロセス内の個別のステップを担当します。したがって、アプリケーションのコンポーネント間を簡単かつスムーズに移動できることが、アプリケーション設計の重要なポイントになります。重要な設計パターンの 1 つは、ビジネス プロセスのアクションをナビゲーションにバインドすることでアクション フローを制御して、特定のアクションを実行すると適切な次のページまたは次のアクションにユーザーが誘導されるようにすることです。

アクション フローを制御する方法の 1 つは、Windows SharePoint Services 3.0 のユーザー設定のアクション機能を使用して、ライブラリのアイテムについて独自のアクションを埋め込みコンテキスト ボタンに追加することです。ただし、この機能には、アクションがハードコーディングされている必要があり、アイテムの名前または他の動的な値でパラメーター化できないという制限があります。

ビジネス プロセスに動的アクションを組み込むために、カスタム SharePoint リストを作成し、"計算フィールド" を使用する方法もあります。バグ追跡アプリケーション テンプレートでは、ユーザー設定のバグ リストを使用してバグの状態および情報を追跡します。Microsoft では、計算フィールドを使用してユーザー設定のリンクをリスト ビューに組み込むことで、ユーザーがバグに対して "アクティブ化" や "解決" などのアクションを実行できるようにしました。ユーザーは、これらのアクションに設定されたナビゲーションによって適切なユーザー設定のフォーム (前の設計パターンを参照) に誘導され、バグをアクティブ化または解決するために必要な操作を行います。

計算フィールドは Windows SharePoint Services 3.0 の機能の 1 つであり、SharePoint リストの列としてユーザー設定の表示パターンを適用できるようにします。たとえば、(バグのアクティブ化という) ビジネス プロセス アクションが列内のボタンとして表示され、ユーザーがこのボタンをクリックすると、そのビジネス アクションを実行するための適切なユーザー設定のフォームが表示されます。

計算フィールドでは、アクションを表示するかどうかを選択するための条件ロジックがサポートされます。たとえば、バグが既にアクティブ化されている場合、[アクティブ化] ボタンは表示されません。計算フィールドは、リストを定義するスキーマ XML ファイルに Field 要素を追加することで、SharePoint リストに追加されます。<Field ID="{EA1D0509-767B-4576-ABEF-FC66647037B9}" Name="ActivateBug" Group="_Hidden" Type="Computed" Sortable="FALSE" Filterable="FALSE" DisplayName="$Resources:tsa,Activate_DispName;" ClassInfo="Icon" AuthoringInfo="$Resources:core,Linked_Item;"> <FieldRefs> <FieldRef ID="{94f89715-e097-4e8b-ba79-ea02aa8b7adb}" Name="FileRef"/> <FieldRef ID="{3f277a5c-c7ae-4bbe-9d44-0456fb548f94}" Name="Status"/> <FieldRef Name="ID" /> </FieldRefs> <DisplayPattern> <IfEqual> <Expr1>$Resources:core,Status_Active;</Expr1> <Expr2> <Field Name="Status"/> </Expr2> <Then> </Then> <Else> <HTML><![CDATA[<a href="]]></HTML> <HttpHost/> <UrlDirName> <HTML>/</HTML> <LookupColumn URLEncodeAsURL="TRUE" Name="FileRef"/> </UrlDirName> <HTML><![CDATA[/Activate.aspx?ID=]]></HTML> <Column HTMLEncode="TRUE" Name="ID"> </Column> <HTML><![CDATA[" onclick="GoToLink(this);return false;" target="_self">]]></HTML> <HTML><![CDATA[<img border="0" alt="]]></HTML> <HTML>$Resources:tsa,Activate_DispName;</HTML> <HTML><![CDATA[" src="]]></HTML> <HttpHost/> <UrlDirName> <HTML>/</HTML> <LookupColumn URLEncodeAsURL="TRUE" Name="FileRef"/> </UrlDirName> <HTML><![CDATA[/IMNBUSY.GIF">]]></HTML> <HTML><![CDATA[</a>]]></HTML> </Else> </IfEqual> </DisplayPattern> </Field>

このコードは、[アクティブ化] 計算フィールドの XML を示しています。バグがアクティブ化されていない場合、このフィールドにはクリック可能なオレンジ色の状態リンクが表示されます。ユーザーがリンクをクリックすると、このバグのアクティブ化フォームが表示されます。

FieldRefs 要素には、バグ リストの状態フィールドへのフィールド参照があります。この参照により、バグの状態に応じてこの計算フィールドのカスタム表示を行うことができます。

計算列の DisplayPattern フィールドには、列の計算と表示パターンが設定されています。この例では、if-then-else ステートメントを使用して、バグがアクティブ状態であるかどうかを判定しています。バグがアクティブである場合は、[アクティブ化] フィールドには何も表示されません。バグがアクティブでない場合は、Else 要素の HTML が表示されます。この HTML コードは、ユーザーがクリックしてバグをアクティブ化できる画像とリンクを表しています。

この設計パターンのその他の例

別サーバー管理の操作フローの制御の例では、 Windows SharePoint Services 3.0 のアプリケーション テンプレートを貸出を参照してください。

サイト管理者の例では、 Microsoft Windows SharePoint Services 3.0 のアプリケーション テンプレートの従業員の活動サイトを参照してください。

親子型のリレーションシップを使用する

ビジネス ソリューションでは、他のデータとのリレーションシップに照らしてデータを表示および使用する必要が生じることがよくあります。たとえば、プロジェクト進捗管理アプリケーションの場合は、プロジェクト、タスク、懸案事項、およびマイルストーンのそれぞれが独自の SharePoint リストに格納されています。それぞれのタスク、懸案事項、およびマイルストーンは、プロジェクト リストのアイテムと関連付けられています。リストと、他のリストに格納されている "子" 情報との間のリレーションシップの管理が、やっかいな問題になることがあります。

新しいリスト アイテムと既存のリスト アイテムとの間の既定のリンクを作成する

親リストのアイテムに関連する新しいリスト アイテムを作成する必要がある場合、1 つの問題がよく発生します。複数プロジェクト進捗管理ソリューションでは、ユーザーが既存のプロジェクトに関連するタスクを作成しようとしたときに問題になります。つまり、既定の Windows SharePoint Services 3.0 には、作成する新しいリスト アイテムと既存のリスト アイテムとの間のリレーションシップを自動的に作成するしくみがありません。

ユーザーは、複数プロジェクト進捗管理アプリケーション テンプレートのプロジェクトの詳細ページ (DispForm.aspx) から、そのプロジェクトに新しいタスクを作成できます。新しいタスクの作成ページ (NewForm.aspx) には、このタスクの親プロジェクトを選択できるドロップダウン メニューが含まれています。ユーザーがこのページに誘導される前に表示されていたプロジェクトが、親プロジェクトとしてこのドロップダウンに既定で表示されるようにするには、親プロジェクトの ID をクエリ文字列に含めて NewForm.aspx に渡します。次に、JavaScript を使用してプロジェクト ID 値を解析し、関連するプロジェクトをドロップダウン ボックスで選択します。<a href="../ProjectTasks/NewForm.aspx?ProjectID={$ProjectID}" onclick="javascript:this.href = unescapeProperly(escape(this.href)); GoToLink(this); return false;" target="_self">Create a new Task...</a>

このコードは、DispForm.aspx からのリンクを示しています。クエリ文字列に ProjectID が含まれていることに注意してください。

NewForm.aspx が読み込まれると、クエリ文字列からプロジェクト ID が解析され、プロジェクトのドロップダウンが変更されて適切なプロジェクトが選択されます。

この JavaScript は、NewForm.aspx のコンテンツ エディター Web パーツに含まれています。この Web パーツはクロムなしに設定されているため、ページが編集モードでない場合は表示されません。JavaScript は、コンテンツ エディター領域内に挿入されています。<script type="text/javascript"> _spBodyOnLoadFunctionNames.push("fillDefaultValues"); function fillDefaultValues() { var qs = location.search.substring(1, location.search.length); var args = qs.split("&"); var vals = new Object(); for (var i=0; i < args.length; i++) { var nameVal = args[i].split("="); var temp = unescape(nameVal[1]).split('+'); nameVal[1] = temp.join(' '); vals[nameVal[0]] = nameVal[1]; } setLookupFromFieldName("Project", vals["ProjectID"]); setLookupFromFieldName("Milestone", vals["MilestoneID"]); } function setLookupFromFieldName(fieldName, value) { if (value == undefined) return; var theSelect = getTagFromIdentifierAndTitle("select","Lookup",fieldName); if (theSelect == null) { var theInput = getTagFromIdentifierAndTitle("input","",fieldName); ShowDropdown(theInput.id); var opt=document.getElementById(theInput.opt); setSelectedOption(opt, value); OptLoseFocus(opt); } else { setSelectedOption(theSelect, value); } } function setSelectedOption(select, value) { var opts = select.options; var l = opts.length; if (select == null) return; for (var i=0; i < l; i++) { if (opts[i].value == value) { select.selectedIndex = i; return true; } } return false; } function getTagFromIdentifierAndTitle(tagName, identifier, title) { var len = identifier.length; var tags = document.getElementsByTagName(tagName); for (var i=0; i < tags.length; i++) { var tempString = tags[i].id; if (tags[i].title == title && (identifier == "" || tempString.indexOf(identifier) == tempString.length - len)) { return tags[i]; } } return null; } </script>

_ spBodyOnLoadFunctionNames.push コマンドにより、読み込み時に実行されるスクリプト リストに fillDefaultValues 関数が追加されます。

fillDefaultValues 関数は、クエリ文字列からプロジェクト ID またはマイルストーン ID を取得し、これを setSelectedOptions に渡します。次に、setSelectedOptions が、ドロップダウン メニューの値を親プロジェクトの ID に設定します。

この設計パターンのその他の例

別のサーバー管理者が親と子のビューを使用する例、 Windows SharePoint Services 3.0 のアプリケーション テンプレートの在庫管理を参照してください。

サイト管理者の例では、 Windows SharePoint Services 3.0 のアプリケーション テンプレートを新しいストア開くを参照してください。

ワークフローを使う

Windows SharePoint Services 3.0 は、Windows Workflow Foundation をホストすることで、ワークフロー ロジックをアプリケーションに追加できるようにしています。Office SharePoint Designer 2007 には、すぐに利用できるワークフローを元に条件ロジックのカスタマイズや追加を行うための強力なルール ベース設計ツールが用意されています。Visual Studio 2005 および Visual Studio 2005 Extensions for Windows Workflow Foundation を組み合わせて使用することで、より複雑なカスタマイズされたワークフローを作成することもできます。いずれの場合も、ワークフローを使用するタイミングとその方法については、次のような考慮事項があります。

ワークフローの使用に関する考慮事項

ワークフローは、非同期操作に適したソリューションです。貸出図書ソリューションでは、ユーザーが新しいライブラリ資産を提案する際にワークフローを使用します。このソリューションでワークフローが選択された理由の 1 つは、提案者と承認者の間のプロセスが同期していないためです。

ワークフローは、スケジュールされたイベントにも適しています。貸出図書ソリューションでは、資産のチェックアウトと期日のリマインダーを処理するためにワークフローを使用します。アイテムがチェックアウトされると、アイテムの期日が到来したときにリマインダーが自動的に送信されます。

ワークフローは、それ以外の場合、シンプルに手段として使用できる、サーバー上の複雑なプログラミング作業します。Windows SharePoint Services 3.0 のアプリケーション テンプレートをタイムカード管理例を示します。このアプリケーションは、パンチの間の時間差を計算することで、特定の従業員の作業の期間を追跡し、パンチのタイムスタンプをします。通常、タイムスタンプの追跡が必要ログ (おそらくデータベース) – にサーバーにこれら 2 つの活動に注目を開発します。代わりに、このアプリケーションは、1 つの簡単なワークフロー ステップに依存します。ユーザーはパンチ、ワークフローは時間ログ リストのエントリを作成し、現在のタイムスタンプの開始時刻の値を設定します。同様に、ユーザーは、パンチ、ワークフローは同じリストに関連する行を更新し、終了時刻の値を設定します。ユーザーの作業の期間の違いをだけで、開始時刻の値と終了時刻する時間のラベルが付いた集計列に反映されます。

ワークフローは非同期に実行されます。あるアクションの結果が完了した直後に次のページに移動する必要があるソリューションを作成するときは、ワークフローはソリューションとして適していません。たとえば、バグ追跡ソリューションでは、バグのアクティブ化と解決の処理にはワークフローを使用していません。この設計上の選択肢の理由の 1 つは、バグの状態に対する変更は、ユーザーがバグに対するアクションを実行した直後にユーザー インターフェイスに反映されなければならないからです。

Office SharePoint Designer 2007 を使用してカスタム ワークフローを作成する

Office SharePoint Designer 2007 を使用してワークフローを作成する場合、コードを記述する必要はありません。サイトを開き、[ファイル] メニューの [新規作成] をポイントし、[ワークフロー] をクリックして、ワークフロー デザイナーを使用します。ワークフロー デザイナーを使用すると、高度なルールおよびアクションを作成し、SharePoint のリストとライブラリに統合して、リスト アイテムおよびライブラリ アイテムからフィールドや値を直接使用することで、ワークフロー ロジックを実行できます。

たとえば、新しいタスクまたは懸案事項が作成されたときにタスク所有者に電子メールを送信するワークフロー アクションを作成するとします。プロジェクト進捗管理テンプレートでは、所有者は SharePoint リスト内のユーザー設定の列であるため、ワークフローは、この列の値を使用して実際の電子メール アドレスを実行時に動的に確認できます。

Office SharePoint Designer 2007 のワークフローの詳細については、「Microsoft Office SharePoint Designer 2007 の概要」を参照してください。

この設計パターンのその他の例

別サーバー管理者のワークフローの使い方の例では、求人と Windows SharePoint Services 3.0 のアプリケーション テンプレートの面接管理を参照してください。

サイト管理者の例では、臨床試用期間の開始と Windows SharePoint Services 3.0 のアプリケーション テンプレートの管理を参照してください。

ダッシュボードを使う

Windows SharePoint Services 3.0 の Web パーツ インフラストラクチャには多くの利点がありますが、そのうちの 1 つが、SharePoint サイト内またはサイトの外のさまざまな場所にある情報を 1 つの概要ページとして表示できることです。これをダッシュボードと呼びます。共有環境における一般的なビジネス ニーズの 1 つに、ロールまたはユーザーに関連する情報を表示できる、ロール ベースのダッシュボードがあります。このようなダッシュボードでは、Web パーツのフィルター処理および対象ユーザーの設定などの強力な組み込み機能を利用して、ページに表示される情報をユーザー単位で制御できます。

この機能を応用して、ロールごとに個別のページを作成し、表示される情報だけでなく、ページのレイアウトなどを含めた本格的なカスタマイズを行うこともできます。このようにしてカスタマイズしたロール ベースのページは、アプリケーション テンプレート内のさまざまな場所で使用できるほか、フィルター処理や対象ユーザーの設定機能を含めることもできます。

たとえば、貸出図書アプリケーションでは、ロール ベースのダッシュボードを使用して、ユーザーのロールに基づき最も関連性の高い情報をユーザーに表示します。このサイトのメイン ページで選択できるページは 2 種類あり、1 つは図書館の利用者向けのページ (既定のページ) で、もう 1 つは図書館員向けのページです。

同様に、ヘルプ デスク アプリケーションのメイン ページには、サービス担当者ホーム、技術情報管理者ホーム、サービス担当管理者ホームという 3 種類のダッシュボード ビューがあります。ユーザーは、自分のロールに最も関連するハイパーリンクを選択します。ダッシュボードに表示される Web パーツ ビューでも、ユーザーに関連するコンテンツが表示されるようにフィルター処理が行われます。この処理は、ビューにフィルターを適用することによって行います。このようなフィルターを既存のリスト ビューに適用する手順を次に示します。

  1. ブラウザーでリスト ビュー ページに移動します。

  2. リスト ツールバー上のドロップダウン コントロールで、変更するビューが選択されていない場合は、そのビューをクリックします。

  3. 同じドロップダウン コントロールに再度移動し、[このビューの変更] をクリックします。

  4. [ビューの編集] ページで、下へスクロールして [フィルター] セクションに移動します。フィルター値を次のように設定します。

    アイテムを表示する条件として、[作成者] 列が [Me] であるか、[顧客] 列が [Me] である場合を指定します。

  5. [OK] をクリックします。

図 4 に示すヘルプ デスク アプリケーションのサービス担当管理者ホーム ページには、サービス リクエストを状態別および優先順位別のバー グラフでまとめた 2 つのダッシュボード Web パーツが表示されています。

[ダッシュボード] ページ
図 4:ダッシュボード ページ

これらは、サービス リクエストというリストに格納されたデータを反映するデータ ビュー Web パーツであり、ヘルプ デスク ソリューション サイトの一部でもあります。このような Web パーツがどのように作成されているかを理解するには、Office SharePoint Designer 2007 でサイトを開き、これらの Web パーツを含む HelpDeskManager.aspx ページを読み込みます。ページを分割ビューで表示すると、この Web パーツの背後にあるコードは XLST、HTML、および CSS の各マークアップ言語を組み合わせたものであることがわかります。

Web パーツのバー グラフがどのように作成されているかを確認してみましょう。例として、全サービス リクエスト (優先順位別) Web パーツを取り上げます。Office SharePoint Designer 2007 で、[挿入] メニューの [SharePoint コントロール] をクリックし、[データ ビュー] をクリックして [データ ソース ライブラリ] 作業ウィンドウを開きます。この作業ウィンドウでは、サイト内に既に存在するリストなど、サイトから現在アクセス可能なさまざまなデータ ソースにアクセスできます。ここでは、[SharePoint リスト] という名前のセクションを展開し、[サービス リクエスト] という名前のリストをクリックして、このリストをデータのソースとして指定します。表示されるコンテキスト メニューの [データの表示] をクリックします。サービス リクエストのリストに格納されたすべてのフィールドおよびサンプル データが表示される作業ウィンドウ内に、[データ ソースの詳細] という名前の新しいパネルが表示されます。このパネルで、Web パーツに表示するフィールドの名前 (ここでは [優先度] フィールド) をクリックし、[選択したフィールドの挿入] の [単一アイテム ビュー] をクリックします (図 5 を参照)。

ここでの目的は、すべてのタスクを優先度別でまとめた件数を表示することです。つまり、[優先度] フィールドで選択可能な各オプションを 1 回だけリストし、各優先度の値の件数をリストの横に表示します。このため、カスタム設定の最初の時点で、優先度の値を [単一アイテム ビュー] で表示することを選択しました。[複数アイテム ビュー] を選択すると、すべての行がリストに表示されます。

SharePoint Designer でのダッシュボード ページの作成
図 5:Office SharePoint Designer 2007 でのダッシュボード ページの作成

これにより、ページのカーソル位置にデータ ビュー Web パーツが挿入されます。ただし、この Web パーツにはデータ行が 1 つ表示されるだけで、サービス リクエストを優先度別でまとめたバー グラフは表示されません。幸い、この Web パーツは HTML および XSL のコードを使用して表示されているため、ニーズに合わせてコードを自由にカスタマイズできます。次のセクションでは、この Web パーツをバー グラフに変換するための主なカスタマイズ作業について説明します。

リスト データ ソースの優先度の値には、(1) High、(2) Normal、(3) Low の 3 つがあります。したがって、それぞれの値に対応する XLST 変数を次のように宣言します。<xsl:variable name="High" select="count(/dsQueryResponse/Rows/Row[normalize-space(@Priority) = '(1) High'])" /> <xsl:variable name="Normal" select="count(/dsQueryResponse/Rows/Row[normalize-space(@Priority) = '(2) Normal'])" /> <xsl:variable name="Low" select="count(/dsQueryResponse/Rows/Row[normalize-space(@Priority) = '(3) Low'])" /> <xsl:variable name="AllTasks" select="count(/dsQueryResponse/Rows/Row)" />

XSL パラメーター @Priority は、データ ソース フィールドの名前を表します。3 つの優先度値のそれぞれをグラフ化するコードは似ているため、優先度 (1) の値をグラフ化する手順を中心に説明します。パーセント値を取得するために、新しい変数 percetHigh を定義して、優先度の高いリクエストのパーセント値を計算します。<xsl:variable name="percentHigh" select="$High div $AllTasks" />

実際のバーを作成するコードは、次に示すような XSL テンプレートです。<xsl:template name="ChartRow"> <xsl:param name="RowName"></xsl:param> <xsl:param name="Value"></xsl:param> <xsl:param name="PercentValue"></xsl:param> <tr> <td class="ms-formbody" width="125px" style="vertical-align:middle"> <xsl:value-of select="$RowName"/>: <xsl:value-of select="$Value" /> <xsl:text xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime" ddwrt:nbsp-preserve="yes" disable-output-escaping="yes"> &amp;nbsp; </xsl:text>( <xsl:call-template name="percentformat"> <xsl:with-param name="percent" select="$PercentValue"/> </xsl:call-template>) </td> <td> <table width="100%" > <tr> <td width="{round($PercentValue*100)+1}%" height="15px" class="ms-selected"><xsl:text xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime" ddwrt:nbsp-preserve="yes" disable-output-escaping="yes">&amp;nbsp;</xsl:text> </td> <td width="100%" > <xsl:text xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime" ddwrt:nbsp-preserve="yes" disable-output-escaping="yes">&amp;nbsp;</xsl:text> </td> </tr> </table> </td> </tr> </xsl:template>

バー自体は、2 つのセルを持つ表です。グラフのバーの幅を表す最初のセルの幅は、PercentValue 変数によって決定され、コードで次のように表されています。td width="{round($PercentValue*100)+1}%"

このセルには CSS スタイル クラス ms-selected も適用されています。このスタイル クラスは、core.css スタイル シート ファイルで次のように定義されています。.ms-selected { background-position:left top; color:#000000; background-image:url("/_layouts/images/filedialogselected.gif"); background-color:#FFE499; border-top:1px solid #FFE499; border-bottom:1px solid #FFE499; background-repeat:repeat-x; }

セル (つまりバー) が黄色で表示されるのは、背景イメージ filedialogselected.gif が指定されているためです。

この設計パターンのその他の例

ダッシュ ボードを使用する別のサーバー管理者など、 Windows SharePoint Services 3.0 のアプリケーション テンプレートのコール センターを参照してください。

サイト管理者の例では、 Windows SharePoint Services 3.0 のアプリケーション テンプレートをビジネス パフォーマンス レポートを参照してください。

ページの先頭へ

テンプレートを作成する

Windows SharePoint Services のアプリケーション テンプレートには、サイト定義とサイト テンプレートの 2 種類があります。40 個のアプリケーション テンプレートには、この 2 種類が混ざっています。ユーザーは、両方の種類のテンプレートを [新しい SharePoint サイト] ページから選択可能で、エンド ユーザーに対しては、どちらの種類のテンプレートも同じように機能します。ただし、これらのテンプレートを作成してサイト作成フォームで使用できるようにする方法はまったく異なります。

サイト定義

サイト定義は、基本的に XML ファイル、アセンブリ、および .aspx ページ (サイトの構造と、サイト内の基になるアプリケーションが実行する処理を定義) の集まりです。ベースとなる XML ファイルと .aspx ファイルにはファイル システムからアクセスできるため、これらのファイルを複製および編集して新しいサイト定義を再作成するのは簡単で、サイト定義は高度なカスタマイズが可能です。

サイト定義からサイトを準備 (作成) した後で、ファイル システム内のサイト定義ファイルに対して行った変更を、準備したサイトに反映することもできます。ただし、Microsoft では、サイトを準備した後でサイト定義ファイルを変更することはサポートしていません。準備したサイトのいずれかのページを Office SharePoint Designer 2007 などの外部エディターを使用して変更した場合、そのページはファイル システム内のサイト定義との接続を失います。代わりに、そのページが Windows SharePoint Services データベース システムに保存され、"カスタマイズ" または "ゴースト解除" ページとして認識されます。

既存のサイト定義をカスタマイズする必要がある場合を既存の代わりに、サイト定義の名前が変更されたコピーを開始する方法があります。サイトはプロビジョニングされるフォームに既にされた後は、既存のサイト定義の変更を実装するために、たいを作成して、サイト定義ソリューションのアップグレード パッケージを展開します。これを行う方法の詳細については、 Windows SharePoint Services 3.0 SDK内の対応する記事を参照してください。

サイト テンプレート

サイト テンプレートとは、SharePoint サイトを 1 つのファイルにパッケージ化したもので、展開して同じ構造とコンテンツを持つ新しいサイトを作成できます。つまり、サイト テンプレートを作成するには、ベースとなる既存の SharePoint サイトが必要になります。ページ レイアウト、スタイル シート、イメージ、マスター ページ、ドキュメント、リスト、リスト コンテンツなど、サイトのカスタマイズは、テンプレート内に取り込むことができます。

既存のサイトをテンプレートに取り込む処理は、([サイトの設定] の) サイトの管理タスクから、または Office SharePoint Designer 2007 から開始します。作成されたサイト テンプレートは、現在のサイト コレクションのサイト テンプレート ギャラリーに保存されます。ファイルには、拡張子 .stp が付けられます。このファイルは、サイト テンプレート ギャラリーからダウンロードして、別のサイト コレクションや別のサーバー環境に移行できます。このセクションの後半では、サイト テンプレートの作成と使用の詳細について説明します。

サイト定義の使用とサイト テンプレートの使用の比較

前に述べたように、サイト テンプレートは、実際にはサイト定義から作成されます。新しいサイト定義とサイト テンプレートのどちらを作成するか決める場合は、次の点を考慮してください。

  • アプリケーションの複雑さ    主に外観上の変更 (既存のサイトに対するレイアウト変更やイメージの操作など) が必要な場合は、サイト テンプレートを選択します。これに対し、新しい Web パーツ定義を追加する必要がある場合や、ユーザー設定コードや計算フィールドを使用する場合は、カスタム サイト定義を作成します。

  • サーバーでのアクセス レベル    Web サーバー全体にアクセスできますか。それとも、アクセスできるのは特定のサイト コレクションだけですか。サイト定義を作成して展開するには、サーバーのファイル システムにアクセスする必要があります。ファイル システムへのアクセス権がない場合、アクセスできるサイト コレクション レベルでしかサイト テンプレートを作成できません。ただし、このアクセス要件はサイト管理者には適用されないこと、また、サイト テンプレートの展開後は、新しいサイトを作成する権限を持つすべてのユーザーが両方の種類のアプリケーション テンプレートにアクセスできることを覚えておいてください。

  • 将来の更新/変更の頻度    サイト テンプレートを変更しても、既に作成済みのサイトには影響がなく、変更後に新しく作成されたサイトのみが影響を受けます。サイト定義アップグレード ソリューション パッケージを展開すると、そのサイト定義に基づいて既に作成されているすべてのサイトが影響を受けます。

サイト テンプレートおよびサイト定義の作成のためのガイダンス

サイト テンプレートの作成とサイト定義の作成では、複雑さのレベルが異なります。基本的な方法は、次のセクションで説明します。

サイト テンプレートを作成する

前に述べたように、サイト テンプレートは、実際には SharePoint サイトをパッケージ化して再利用できるようにしたものです。このパッケージ ファイルは、サイト コレクション レベルのサイト テンプレート ギャラリーに存在します。ギャラリー内のサイト テンプレートを使用して、サイト コレクションのすべての子サイト レベルで新しいサイトを作成できます。既存のサイトから新しいサイト テンプレートを作成する手順を次に示します。

  1. Office SharePoint Designer 2007 で既存のサイトを開き、サイトのコンテンツとレイアウトが目的に適っていることを確認します。

  2. [ファイル] メニューの [エクスポート] をポイントし、[SharePoint サイト テンプレート] をクリックします。[サイトの設定] Web ページが表示されます。

  3. テンプレートのファイル名、タイトル、および説明を入力します。

  4. 必要に応じて、リストおよびドキュメント ライブラリのデータをテンプレートに含める場合は [コンテンツを含む] チェック ボックスをオンにします。ワークフローを含める場合にも、このオプションを選択します (ワークフローは実際にはドキュメント ライブラリに格納されているコンテンツであるため)。

  5. [OK] をクリックします。サイトに基づいて拡張子 .stp を持つテンプレート ファイルが作成され、このファイルが親サイトのサイト テンプレート ギャラリーに格納されます。

サイト テンプレート ギャラリーから、テンプレートの名前をクリックして .stp ファイルをローカルのディスクにダウンロードできます。そこから、別のサイト テンプレート ギャラリーにファイルをアップロードできます。

サイト定義を作成する

サイト テンプレートとは違い、サイト定義はファイル システムに格納されます。各サイト定義は、サーバー上で次の場所にある独自のフォルダーに格納されます。

% CommonProgramFiles %\Microsoft shared \web server extensions\12\TEMPLATE\ SiteTemplates

このサイト テンプレート フォルダーには、.aspx ファイル、.html ファイルのほか、イメージや JavaScript ファイルなどの関連リソースを含むさまざまなサイト要素が格納されます。ONET.XML は、サイト定義のさまざまな構成やモジュールを指定するコア サイト定義ファイルです。ONET.XML は、"XML" という名前のサブディレクトリに格納されます。

サイト定義は Windows SharePoint Services に登録され、WEBTEMP XML ファイルを介して使用できるようになります。すべての WEBTEMP XML ファイルは次の場所に格納されます。

% CommonProgramFiles % \ \Microsoft Shared\Web サーバー extensions\12\TEMPLATE\ < LCID > \XML

<LCID> は、ロケール ID (1033 など) を表します。XML ファイルの実際の名前には、接頭辞 "WEBTEMP" が付きます (例: WEBTEMPBT.XML)。

基本的に、新しいサイト定義の作成は、(1) サイト定義フォルダーの設定、および (2) サイト定義を Windows SharePoint Services に登録するための WEBTEMP XML ファイルの作成、という 2 つの主な手順で構成されます。最初の手順は、既存のサイト定義フォルダーを複製し、ビジネス要件に合わせてコンテンツを変更することです。ONET.XML ファイルには、サイト ページを準備するためのさまざまなパーツ (ナビゲーション バー、ドキュメント テンプレート、リスト テンプレートなど) を指定する要素が定義されています。Configurations 要素には、サイト定義のインスタンスを作成する際に既定で作成されるリストおよびモジュールを指定します。バグ追跡のサイト定義の ONET.XML から抜粋した、Configurations 要素の部分を次の例に示します。<Configurations> <Configuration ID="0" Name="Default"> <SiteFeatures> <!-- BasicWebParts Feature --> <Feature ID="00BFEA71-1C5E-4A24-B310-BA51C3EB7A57" /> <!-- Three-state Workflow Feature --> <Feature ID="FDE5D850-671E-4143-950A-87B473922DC7" /> <!-- TSA Fields and Content Types --> <Feature ID="75A0FEA7-CD50-401e-AF0E-782F3662A299" /> </SiteFeatures> <WebFeatures> <!-- TeamCollab Feature --> <Feature ID="00BFEA71-4EA5-48D4-A4AD-7EA5C011ABE5" /> <!-- MobilityRedirect --> <Feature ID="F41CC668-37E5-4743-B4A8-74D1DB3FD8A4" /> <!-- Bug Tracking Categories List --> <Feature ID="75A0FEA7-42E8-4527-8313-F63C4C49A7E6" /> <!-- Bug Tracking Bugs List --> <Feature ID="75A0FEA7-2D1E-451a-B445-16BC346D7D8E" /> <!-- Bug Tracking Bugs List Instance --> <Feature ID="75A0FEA7-2D1E-451a-B445-16BC346D7D8F" /> ... ... <!-- Post Provisioning Event Handler --> <Feature ID="75A0FEA7-B0EF-434e-90D6-CE997D970564"> <Properties> <Property Key="ZonedWebPartsUrlList" Value="$Resources:core,lists_Folder;/Bugs/Resolve.aspx,$Resources:core,lists_Folder;/Bugs/Activate.aspx,$Resources:core,lists_Folder;/Bugs/Close.aspx"/> </Properties> </Feature> </WebFeatures> </Configuration> </Configurations>

このサイト定義では、Bugs List、Bug Categories List、Mobility Redirect などのさまざまなフィーチャーを使用しています。これらのフィーチャーは、SiteFeatures 要素および WebFeatures 要素の下に、フィーチャーの GUID と共に列挙されています。GUID は、次のフォルダー内の対応する Feature.XML ファイルの Feature 要素で定義されています。

% CommonProgramFiles %\Microsoft Shared\Web server extensions\12\TEMPLATE\FEATURES

ONET をカスタマイズする方法の詳細については、 Windows SharePoint Services 3.0 SDKを参照してください。XML します。

ユーザー設定のサイト定義を作成するための 2 つ目の手順では、次のフォルダー内に WEBTEMP*.XML ファイルを作成します。

% CommonProgramFiles %\Microsoft shared \web server extensions\12\TEMPLATE\ < LCID > \XML

このファイルの Templates 要素では、このサイト定義から作成されたサイトのインスタンスを作成する際に使用できる構成を指定します。次の抜粋は、バグ追跡サイト定義で使用されている構成ファイル WEBTEMPbt.XML ファイルの形式を示しています。<?xml version="1.0" encoding="utf-8" ?> <Templates xmlns:ows="Microsoft SharePoint"> <Template Name="BT" ID="75801"> <Configuration ID="0" Title="Bug Database" Hidden="FALSE" ImageUrl="/_layouts/images/stsprev.png" Description="A site for teams to track bugs in their shared software projects." DisplayCategory="Application Templates" > </Configuration> </Template> </Templates>

上記の Template ノードの Name 属性は、ファイル名 WEBTEMP*.XML の "*" 部分と一致している必要があります。また、Configuration 要素の DisplayCategory 属性により、[サイトの作成] Web ページの [テンプレートの選択] セクションで構成が表示されるタブが指定されます。この属性に独自の値を挿入することにより、独自のタブを作成できます。

サイト定義ファイルを作成し、ファイル システム内の適切なフォルダーに配置されているが、IIS のサービスを再起動します。新しいサイト定義Windows SharePoint Servicesの新しい SharePoint サイトのページの[テンプレートの選択] セクションで、選択した表示されます。サイト定義ファイルは、ソリューションを別の SharePoint 環境または同じ環境で再配置に簡単に移行ファイルとしてもパッケージ化します。ソリューションのファイルがファイル キャビネットをします。Web ソリューション パッケージ) (WSP 拡張します。機能を Web パーツ、アセンブリが含まれているクラスのリソースなどのサイト定義で使用します。Makecab.exe ツールを使用して作成します。WSP ファイル。ソリューションのファイルを作成する方法のWindows SharePoint Services 3.0 SDKを参照してください。

サイト定義をローカライズする

リソース ファイルおよびカルチャ検出を使用すると、サイト定義のローカライズを簡単に行うことができます。一般的な ASP.NET 2.0 アプリケーションのローカライズはコンパイル時に行いますが、SharePoint サイトのローカライズはサイトのプロビジョニング時に行います。アプリケーション テンプレートのうち、20 個のサイト定義テンプレートはすべて 10 か国語にローカライズされています。サイト定義自体は言語に依存しない形式で作成されますが、文字列リテラルがリソース ファイル (.resx) に格納されています。独自のサイト定義にローカライズを追加する場合、または既存のサイト定義に新しい言語のサポートを追加する場合は、新しいリソース ファイルを作成します。このファイルは、次の場所にある Resources ディレクトリに格納します。

% CommonProgramFiles %\Microsoft Shared\Web server extensions\12\Resources

このファイルは、基本的に任意のテキスト エディターで編集可能な XML ファイルです。サイト定義で使用する新しいローカライズ ファイルを作成する手順を次に示します。

  1. 上記の Resources ディレクトリを参照し、新しい言語にローカライズする既存の .resx ファイルを探します。

  2. このファイルを複製し、ファイル名の <言語名>-<カルチャ名> の部分を変更し、それ以外は元のファイルと同じにします (たとえば、tsa-en-us.resx を tsa-es-es.resx という名前にします)。

  3. 複製したファイルをテキスト エディターで開きます。

  4. このファイルの 2 行目で、言語を表す lcid コードを設定します。たとえば、言語をスペイン語に設定する場合は、次のようにします。

<!-- _lcid="3082" _version="12.0.5006.3000" _dal="1" ––>

  1. 下へスクロールして、data 要素と value 要素がペアになっている部分に移動します。ここで、リソース名とローカライズした文字列値のペアを定義します。value 要素の文字列値を、目的のロケールに合わせて変更します。create new customer アクションに対応するスペイン語のリソース文字列を次のコード例に示します。

    <data name="Action_NewCustomer">
    <value>Crear un Nuevo cliente</value>
    </data>
  2. このファイルに myCustomResource.es-es.resx (実際の名前はリソース ファイルで指定する言語とカルチャの名前に依存します) のような名前を付けて Resources フォルダーに保存します。これで、このファイルをアプリケーションのサイト定義ファイルで参照できるようになります。

ローカライズされたサイト定義が、目的の言語の [新しい SharePoint サイト] ページで利用可能なテンプレートとして表示されるようにするには、該当する <LCID> ディレクトリにも WEBTEMP ファイルを追加します。新しい WEBTEMP ファイルを追加する方法については、以前の「サイト定義を作成する」セクションを参照してください。

.aspx ファイルでは、ローカライズされたリソース参照の動作は、XML ファイルの場合と異なります。たとえば、.aspx ファイル内の参照は実行時に評価されますが、XML ファイルの参照は Web サイトのインスタンス作成時に評価されます。サイト定義ファイルでリソース ファイルの XML 要素にアクセスするには、構文 $Resources:myCustomResource, DataName を使用します。たとえば、.aspx ファイルのリソース文字列を使用する場合は、次のようなマークアップになります。<div> <asp:Label runat="server" Text="<%Resources:myCustomResource, Action_NewCustomer %>" /> </div>

ページの先頭へ

まとめ

Windows SharePoint Services 3.0 と Office SharePoint Designer 2007 の両方を使用することで、ワークフロー対応の対話型アプリケーションの構築とカスタマイズに必要な強力なツールが提供されます。この記事では、40 種類のダウンロード可能なアプリケーション テンプレートのいずれかをカスタマイズする場合にも、独自のアプリケーションを構築する場合にも適用でき、開発者以外のユーザーでも簡単に使用できる、実証済みの方法論とベスト プラクティスについて説明しました。

まだアプリケーション テンプレートをダウンロードしていない場合は、次のステップとして、アプリケーション テンプレートをダウンロードし、Office SharePoint Designer 2007 で開いて使い始めてみてください。次の「リソース」セクションには、独自のアプリケーションを構築するために役立つリソースが記載されています。

ページの先頭へ

リソース

Windows SharePoint Services 3.0 および Office SharePoint Designer 2007 の詳細については、次のリソースを参照してください。

開発者向けのリソースとしては、次を参照してください。

ページの先頭へ

注: 機械翻訳についての免責事項: この記事の翻訳はコンピューター システムによって行われており、人間の手は加えられていません。マイクロソフトでは、英語を話さないユーザーがマイクロソフトの製品、サービス、テクノロジに関するコンテンツを理解するのに役立てるため、こうした機械翻訳を提供しています。記事は機械翻訳されているため、用語、構文、文法などに誤りがある場合があります。

スキルを磨く
トレーニングの探索
新機能を最初に入手
Office Insider に参加する

この情報は役に立ちましたか?

ご意見をいただきありがとうございます。

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×