本内容は、SharePoint Server 2007 をベースに記載しています。(2008 年に記載したコラムです。コラム終了のため、こちらに移動しました . . .)最新の SharePoint 2010 を使用した製品開発手法については、「SharePoint Server 開発 サンプル コード集 : 10 行コードで作る .NET アプリケーション」を参照してください。

今回は、もっとも基本である UI カスタマイズを例に、SharePoint 開発の基盤について説明します。

SharePoint 開発の本質

• はじめに
• UI / Web パーツで見る「フィーチャー フレームワーク」
• ワークフロー フィーチャー
• フィーチャーのカスタマイズ
• インストーラとしてのソリューション パッケージ (wsp)

UI と基本動作

UI 開発の前に、まず相手を知ることが大切です。この ”SharePoint” という怪物がどんな存在であるかを理解しておくことで、実は得体の知れない「怪物」などではなく、非常に柔軟で従順な相手であることを理解できるかもしれません。
例えば SharePoint は、ご存じの通り、配置するドキュメント/バイナリファイルや使用されるコンテンツ (.aspx, イメージファイル, 等) などは、概ねデータベース (SQL Server) の中に登録します。管理上は非常にありがたいことですが、開発者にとっては使い慣れた .NET Framework とはまったく動きの異なる得体の知れないフレームワークのようで、少々うんざりしてしまうかもしれません。しかし、実はそれほどやっかいなものではありません。

もう少し細かくみてみましょう。皆さんが ASP.NET (.NET の Web フレームワーク) で開発したページは、まず Web サーバー (IIS) が拡張子に応じて .NET Framework の Web サーバー上の実行エンジンである ASP.NET (aspnet_isapi.dll) に処理を渡します。この ASP.NET の処理系では「HTTP ハンドラー」と呼ばれる .NET のクラスの決められた手順に沿って処理がおこなわれていました。

補足 : ASP.NETの内部動作の詳細は、「MSDN : セキュリティ保護された ASP.NET アプリケーションの構築 : 認証、認定、および通信のセキュリティ保護」をご参照ください。

では SharePoint の場合はどうでしょう ? 実は SharePoint では、ASP.NET とまったく同じ仕組みで動作しています。違いは、ASP.NET がデフォルトで使用するハンドラー (DefaultHttpHandler) を継承した独自のハンドラー (SPHttpHandler) が使用されているという点です。また、SQL Server からデータを読み込む仕組みは、ASP.NET の仮想パスプロバイダという仕組みが使用されています。つまり、処理の流れ自体は ASP.NET と変わりません。

補足 : SharePoint 用の ASP.NET のハンドラーは、SharePoint の Web アプリケーション フォルダー (通常は、%wwwroot%wssVirtualDirectories<ポート番号> です) の web.config の中に設定されています。

SharePoint のページ上に配置されている独自の UI コントールも、ASP.NET の UI コントロールから派生された独自のクラスが構成されているだけです。つまり SharePoint は、いわば ASP.NET 上に構築された 1 アプリケーションにすぎず、エンジンは ASP.NET そのものに他なりません。ページの記述も ASP.NET 同様、開発者は HTML ではなく、サーバー用のマークアップを記述し、これがサーバー上で処理されて Web ブラウザが理解できる HTML の構文に展開されます。マークアップの仕様も ASP.NET そのものです。

「SharePoint 上で高度な機能実装を考えている開発者」にとっては、こうした仕組みの理解が重要です。例えば、Visual Studio 上で SharePoint のページを開いてもビジュアルに編集できません。理由は、SharePoint が普段使用している構成とは別の web.config が読みこまれ、SharePoint 用のタグプレフィックス (<asp: . . .> などの先頭に付与する「asp」などの文字列) などが理解できず、デザイナーが UI を表示できないためです。逆の言い方をすると、SharePoint が web.config に記述している ASP.NET 用の構成 (設定) をすべて真似して、参照先の必要な仮想フォルダ/ファイルさえ正しく配置しておけば、SharePoint の UI と言えども Visual Studio の上で普通の ASP.NET のように開発をおこなうことができるはずです。

この SharePoint の仕組みそのものを使用して UI 開発ができる唯一のデザイナーが、SharePoint Designer です。今回は製品開発者向けの説明ですので、このツールを使った編集方法については詳述しませんが、編集方法は Visual Studio に類似したもので、ページは通常の ASP.NET で使用されるマスターページとコンテンツ ページの仕組みをそのまま使用しているため、イメージ/テキストなどデザインのほとんどはマスターページ側を編集することになります。

補足 : SharePoint では、表示するページの内容によって外観 (外枠) のイメージが変更されず、内容だけが更新されます。これは HTML によるフレームなどを使っているのではなく、ASP.NET のマスターページ/コンテンツページという仕組みが使用されています。サーバー側では、枠に相当するマスターページと、中身に相当するコンテンツページを別々に構成することで、サーバー側で 1 つの HTML ページとして組み立てがおこなわれます。
この詳細については、本連載の「インストーラとしてのソリューション パッケージ (wsp)」の章で説明したいと思います。

しかし、この SharePoint Designer で手の込んだマスターページを作成しようと試してみた方はおわかり頂けると思いますが、簡単な行の挿入や、イメージファイル/テキストの追加、スタイル変更まではビジュアルにできても、手の込んだページを作成しようとすると一筋縄ではいきません。例えば、余計な余白を削除しようと勝手にコントロールを削除してしまうとページでエラーが発生することがあります。SharePoint では、タイトル、操作メニュー、左のナビゲーションバーに至るまで、多くが ASP.NET の「コンテンツプレースホルダ」を使用しています。このため必要なコンテンツプレースホルダを削除してしまうとページが表示されなくなってしまうのです。
つまり、SharePoint Designer は、エンドユーザーが簡易なカスタマイズ (例：マスターの簡易な変更、など) をおこなうために用意されているツールで、高度な開発者がまったく独自のマスターページを構成したいようなケースには万能ではありません。SharePoint Designer では ASP.NET のプログラムコードの記述もできないようになっていますから、ASP.NET AJAX の組み込みなども大変になってくることでしょう。

実は、海外のインターネット上のページには SharePoint で動いているページが数多く存在しています。あるものは、顧客の予約フォームなどを InfoPath の Web フォームで実現していたり、またあるものはバックエンドでワークフローを使用していたり、またあるものはコンテンツ管理の仕組みを利用していたりとさまざまですが、UI については SharePoint とはまったくわからないほど見事に整形がおこなわれ、Ajax などのテクノロジーも融合し、エンドユーザーにとってより違和感のないものに差別化されています。また日本でも SharePoint を使用したパッケージ化されたソリューション製品などの UI ではこうしたものがいくつか存在しています。
では、これらはどのように編集されたのでしょうか ?

こうした高度なページのカスタマイズをおこなうには、実は冒頭でご説明した ASP.NET を理解していることが鍵になります。仕組みを理解してれば、Visual Studio でビジュアル編集をしたり、部品ごとにわけてデザインをおこなうということも不可能ではありません。

一例をご紹介しましょう。

1. Visual Studio を使用して、マスターページとコンテンツページを持った ASP.NET の Web ページを作成し、マスターページを自由にデザインしてみましょう。
   
2. SharePoint のマスターページでは、上述の通り決められたコンテンツプレースホルダが挿入されたページであれば問題ありません。MSDN ではこうしたニーズに対して、SharePoint 用に、必要なプレースホルダのみを使用したまっさらなページ (空白のページ) のサンプル「最低限のマスターページ」が提供されています。
   そこで、サイトに掲載されている「最低限のマスターページ」 (minimal master page) のコードをそのままコピーして、SharePoint Designer のマスターページのコードとして入れ替えてしまいましょう。
3. ページ上のメインのプレースホルダ (PlaceHolderMain) の箇所に、先ほど Visual Studio で自由にデザインしたマスターページのマークアップコードの該当部分をそのままコピーして貼り付けます。 (尚、スタイルシートを使用している場合などは、ヘッダーにも必要なマークアップを追加しておきましょう)
   
4. あとは、メインのコンテンツプレースホルダを SharePoint のものと入れ替え、使用したスタイルシート (.css)、イメージファイルなどをテンプレート フォルダ (下記の「補足」を参照) などにコピーして、参照先の URL を変えておきましょう。
   

補足 : SharePoint で共通に使用されるファイルなどは、データベース(SQL Server)ではなく以下のテンプレート フォルダ下のファイルが参照されています。
%ProgramFiles%\common files\microsoft shared\web server extensions\12\template

これは編集の一例ですが、ASP.NET の初歩的なルールさえ理解していれば、このように何も恐れることなく自由度の高いレイアウトができることがおわかり頂けるでしょう。現実の開発では、上記のような作業分担をおこない、デザイン会社などへのデザイン発注もおこなう場合もあるでしょう。 (ASP.NET さえ理解していれば、かなりの部分のデザインが可能です。)

フィーチャー フレームワーク

上記では、SharePoint の基本が ASP.NET であるということにフォーカスを当てて説明しましたが、最初に記載したように SharePoint が持っている独自な仕組みというものも少なからず存在しています。以降は、Web パーツ開発の説明と共に、逆にこうした SharePoint が持つ独自のフレームワークにフォーカスを当てて説明します。

SharePoint では .NET のマスターページ (.master) が大きく「デザイン」に影響していることを上記で説明しました。では、中身に相当するコンテンツはどのように作成されているのでしょうか ?
例えば、default.aspx を SharePoint で開き、操作メニューの [ページの編集] を選択してみてください。

実はメインのコンテンツページの正体は、上図のように「Web パーツ」の組み合わせになっていることがわかります。むしろそれ以外のコントロールはまったく見当たらないといった感じです。 普通にテキストボックスなどの標準的な ASP.NET のコントロールを組み合わせてページを作ることももちろん可能ですが、SharePoint のページの多くがこのように Web パーツの組み合わせになっている理由は、「始めに」の章でも述べたように、エンドユーザーに対して部品組み立て型のアプリケーションを提供するという思想にあります。以降はこの Web パーツを独自に作成する方法についてふれていきます。

さて、Web パーツと言えども「基本は .NET」です。この根本原理は変わりません。以前のバージョンの SharePoint では ASP.NET の Web パーツとは異なるコントロールでしたが、Office SharePoint Server 2007 / Windows SharePoint Services 3.0 からは完全に ASP.NET の Web パーツと統合されました。

例えば Visual Studio で ASP.NET の標準的な Web パーツを作成してみましょう。クラスライブラリを作成して以下の簡単なコードを記述します。(あらかじめ System.Web.dll の参照を追加しておきましょう)

public class DotNetWebpartDemo : WebPart{    TextBox textBox1 = new TextBox();    Button button1 = new Button();    protected override void CreateChildControls()    {        base.CreateChildControls();        this.Controls.Add(textBox1);        button1.Text = "Press Me";        button1.Click += new EventHandler(button1_Click);        this.Controls.Add(button1);    }    void button1_Click(object sender, EventArgs e)    {        textBox1.Text = "Hello World";    }}

リビルドをしたら、SharePoint が参照できるように SharePoint の仮想ディレクトリー (※1) の bin 下に dll をコピーし、SharePoint の web.config に以下の通り追加をおこないます。(アセンブリ名、名前空間、クラス名などは、適宜変更してください)

補足 : ファーム作成時に特に変更していなければ、%wwwroot%\wss\VirtualDirectories\<ポート番号> がルートの仮想ディレクトリになります。

<?xml version="1.0" encoding="UTF-8"?><configuration>  . . . . .  <SharePoint>    <SafeControls>      . . . . .      <SafeControl         Assembly="SimplestWebPartDemo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"         Namespace="SimplestWebPartDemo" TypeName="DotNetWebpartDemo" Safe="True" />    </SafeControls>    . . . . .

あとは SharePoint 上で Web パーツギャラリを開いて [新規] をクリックするとこの Web パーツが見つかりますので、これをチェックして [ギャラリーに追加] ボタンを押します。

これで Web パーツが使用できるようになりました。ページ上にこの Web パーツを張り付けて使用すると、見ごと自作の Web パーツが動作することでしょう。

このデモは、ASP.NET で標準的に作成した Web パーツが SharePoint でも区別なく使用できるという重要な点を意味していますが、もう 1 つの側面も表しています。このようにして作成した Web パーツは、他の Web パーツと異なり、表題も「DemoDotNetWebPart」という粗末な名称のままであり、Web パーツを選択する際も他の Web パーツのように親切な説明 (Description) は表示されません。またグループも「その他」のまま、さらに登録のためにいくつか手続きを踏む必要がある、といった具合であり、エンドユーザーに開放されたプラグイン可能な部品と呼ぶにはまだ不出来な部分がいくつか存在するようです。

実は SharePoint では、この連載の「はじめに」の章でも説明した部品組み立て型の機能 (フィーチャー) をエンドユーザーに提供可能にするため、.NET の上に SharePoint 独自の「展開」のための層が構成されています。その重要な要素が フィーチャー フレームワーク です。エンドユーザー向けの「タイトル」、「説明 (Description)」、「グループ」、さらには展開の方法などについては、SharePoint 独自の XML 形式の定義ファイル (CAML) を作成し、これを専用の管理コマンド (stsadm.exe) で配置 (デプロイ) することですべてが解決できるよう、このフレームワークがプロダクティビティ層の一翼を担っているのです。

この SharePoint 用の XML を無論最初から手作業ですべて記述することも可能ですが、こうした開発を容易にするために Visual Studio のアドインも用意されています。ダウンロードセンターから「Windows SharePoint Services 3.0 ツール: Visual Studio 2008 Extensions Version 1.2」(VSeWSS 1.2) をダウンロードしてインストールをおこない、今度は以下のプロジェクトテンプレートを使用して同じように Web パーツを作成してみましょう。

プログラムコードは先ほどと同様で充分ですが、今度は、プロジェクトに付属の <クラス名>.xml に下記のように追加をおこない、<クラス名>.webpart の中の Title と Description の要素も適当な名前に変更します。さらに、F5 を押すだけでデバッグ用に配置 (※2) をおこなうことができます。今回は web.config を手で書き換える必要はありません。

<?xml version="1.0" encoding="utf-8"?><Elements Id="c5f5c2fc-2b73-48c9-b8f9-f7e37d631db1" xmlns="http://schemas.microsoft.com/sharepoint/" >  <Module Name="WebParts" List="113" Url="_catalogs/wp">    <File Path="WebPart1.webpart" Url="WebPart1.webpart" Type="GhostableInLibrary">      <Property Name="Group" Value="検証用のデモ一式" />    </File>  </Module></Elements>

補足 : 配置をおこなう前にプロジェクトのプロパティを表示して [デバッグ] タグを表示し、[ブラウザ開始時に使用する URL] として展開先のサイトコレクションを設定しておきます。
また、アンインストールするには、以下を実行します。
setup.bat /uninstall /siteurl [SPSiteのURL] /weburl [SPWebのURL]
ただし、ギャラリーにはエントリーが残りますので (削除はおこなわれています)、不要な場合は SharePoint Designer などでこのエントリーを削除しておきます。また開発時などでデバッグをおこなうには、SharePoint の web.config に以下の通り設定をおこないます。

<compilation batch=”false” debug=”true” . . .

このようにして配置された Web パーツは、さきほどのものとは異なり、エンドユーザーにもわかりやすく、かつ配置の面倒な手間もいくつか省いてくれます。管理者は、作成された setup.bat コマンドを実行するだけです (この setup.bat の中では、stsadm.exe が使用されています)。そして、SharePoint の操作メニューで [サイトの設定] を選択して [サイトコレクションの機能] をクリックしていただくとわかりますが、インストールした機能のオン・オフが切り替えられるようになっています (下図)。つまり、このフレームワークは、エンドユーザーが使いやすいように、多くの組み込みに関する事柄を「フィーチャー」という形でラッピングしてくれているのです。

フィーチャーで使用する定義ファイルは、どのフィーチャーレシーバーを使うか (例：ワークフロー展開用のレシーバーか、InfoPath フォーム展開用のレシーバーか、など)、どのようなエレメントマニフェストを使うか、などを定義した feature.xml 本体と、そこから参照されるフィーチャーの定義内容そのものを記述したエレメントマニフェスト (上記で編集した .xml ファイルです) があります。上記のサンプルでは feature.xml が見当たりませんが、Visual Studioで [WSP ビュー] というウィンドウを表示すると下図のように内部で使用されているフィーチャー定義ファイルをすべて表示 (変更) することができます。

実は、上記で説明したマスター ページも、同様に「フィーチャー」として SharePoint に組み込むことができます。フィーチャーとして登録されたマスター ページはギャラリーに登録され、エンドユーザーは登録されたマスターページを SharePoint 上から好きなタイミングで利用することができます。そろそろ紙面がなくなってきましたのでここでは詳細を割愛しますが、マスター ページ用のフィーチャー定義の記述方法については以下を参考にしてみてください。

[MSDN] フィーチャーの操作 -ファイルを準備する

http://msdn.microsoft.com/ja-jp/library/ms441170.aspx

マスターページの場合には、ファイル内からスタイルシート (.css) やイメージファイルなども参照していました。ではこれら付属のファイルはどのように配置したら良いのでしょうか ? その点については「最後の仕上げ、インストーラとしてのソリューションパッケージの作成」の章で詳しく述べていきましょう。
ここで説明した SharePoint 独自の「フィーチャーフレームワーク」は、SharePoint を使用した多くの開発において関わってくることになる重要な要素ですのでおぼえておいてください。