.net - SharePoint のフォーム

Question

SharePoint にフォームを配置したい場合、InfoPath を使用するか、C# でカスタム Web パーツを構築する方が簡単ですか? 他に考慮すべきオプションはありますか?

各オプションの要件とハードルは何ですか?

Answer 1

InfoPath を使用してフォームを作成することは、SharePoint でフォームを発行する最も簡単な方法です。多くの制限があることに注意してください。問題のあるロジックを入れようとしたり、追加の機能が必要になったりすることがあります。

C# でプログラミングするには、C# の知識 (もちろん) と SharePoint の API の知識が必要です。また、完了したら、結果の DLL を発行し、SharePoint によって信頼する必要があります。これには、sysadmin の介入が必要です。これは常に利用できるとは限らず、次に SharePoint をアップグレードしようとしたときに問題になる可能性があります。

最後に、SharePoint の組み込み機能を使用して、ほとんどの作業 (フォームを含む) を達成することをお勧めします。少し掘り下げてみると、リストのビューをカスタマイズしたり、フィールドの順序を調整したり、独自の列 (およびサイト列) を追加したりするだけで、複雑なアプリケーションを実際に構築できることがわかります。このアプローチは純粋な SharePoint です。余分な知識 (および人) は必要ありません。

Answer 2

実際には、カスタム Web フォームを作成するために SharePoint API の知識はあまり必要ありません。これは非常に簡単なプロセスです。便利なリンクはありませんが、開始するための "hello world" の例がいくつか出回っているはずです。SharePoint Web パーツの扱いが難しいのは、それらを最適にデバッグして展開する方法です。

ラップトップでローカルに実行されている仮想サーバーの完全なスイートを持っているコンサルタントを何人か知っています。それは私にとって選択肢ではありません。私のグループは System.Web.UI.WebControls.WebParts.WebPart を利用しているので、開発環境にデプロイする前にローカルでテストできます。この方法を使用すると、スタイル シートやシステム提供の Web パーツなどの SharePoint 要素が不足するため、ローカルで完全にテストできないことに注意してください。展開に関しては、まだ詳細に取り組んでいます。手動で行うこともできますが、ロックダウンされた運用環境には適していません。レビューへの 1 つのアプローチは「機能」です。新しい拡張機能を単一のインストーラーとして適用することは有望に思えますが、バグ修正をどのように処理するかはわかりません。

Answer 3

フォームとシェアポイントのバージョンについて、より具体的に教えていただけますか?

Sharepoint のバージョンによって異なります。2003 を取得した場合、InfoPath を使用する場合は、クライアントにもインストールする必要があります。SharePoint 2007 では必要ないと思います。

ビジネス ルールがほとんどない大規模なフォームの場合は、InfoPath が最適です -> wysiwyg、および展開が容易です。

フォームにさらに多くのビジネス ルールが含まれる場合、_layouts の Web パーツまたはページは「よりシンプル」で保守しやすくなります。

Answer 4

考え方にもよるかもしれませんが

たとえば、1. フォームを独自にカスタマイズするためにエンド ユーザーにコントロールを与えようとしている場合は、Infopath を使用できます。

Infopath は非常に理解しやすく、開発も容易です。Infopath を使用するには、Infopath、Infopath Form Services、Sharepoint API を学習して、Dotnet (C#) と Sharepoint を統合する必要があります。

Answer 5

Infopath は、すばやくフォームを作成して SharePoint にアップロードするのが苦手です。カスタム C# アプリをビルドするよりも 1000 倍速いと思います。