Sharepoint 用の Web パーツを作成する場合、実際の Web パーツを作成する方が良いですか、それとも ASP.NET ユーザー コントロール (.ascx) を使用する方が良いですか?
必要なユーザー コントロールを作成する方法は既に知っているので、Web パーツを作成するための余分な労力は、不必要な手間のように思えます。
ASP.NET ユーザー コントロールを作成するだけでなく、Web パーツを使用する利点は何ですか?
Sharepoint 用の Web パーツを作成する場合、実際の Web パーツを作成する方が良いですか、それとも ASP.NET ユーザー コントロール (.ascx) を使用する方が良いですか?
必要なユーザー コントロールを作成する方法は既に知っているので、Web パーツを作成するための余分な労力は、不必要な手間のように思えます。
ASP.NET ユーザー コントロールを作成するだけでなく、Web パーツを使用する利点は何ですか?
私は、最も単純な Web パーツを除いて、ユーザー コントロールの大ファンです。ユーザー コントロールをインスタンス化して読み込む Web パーツを作成します。smartpart など、ユーザー コントロールを公開するために使用できるツールは他にもありますが、良い学習体験になるので、自分でまとめることをお勧めします。1 回実行すると、基本的に、作成する他の Web パーツのテンプレートが作成されます。
幸運を!
裸の ASP.NET ascx コントロールをカスタム レイアウト ページに追加する必要があります。これは、「どこにでも」追加できないため、コントロールの有用性を少し制限します。
Web パーツを使用すると、コントロールをサイトの異なる場所に複数回追加したり、同じページに異なるプロパティで複数回追加したりする柔軟性が得られます。
前述のようCreateChildControls()
に、Web パーツでコントロールを作成するために使用するのは適切であり、Web パーツをコーディングしてソリューションにパッケージ化することはそれほど大したことではないため、余分な労力を費やす価値があります。
Web パーツは、同じページの "フィルター" Web パーツからの接続を受け入れることもできるため、サイトで ascx コントロールをホストする場合と比較して、Web パーツにさらなる柔軟性が与えられます。
サイトを使用する編集者にとって、ページ レイアウトを編集して公開し、そのページ レイアウトに基づいてページを作成する場合と比較して、Web パーツを追加できることは大きな違いを生むので、サイトの観点から使いやすさの違いは本当に大きいです。
さらに進んで、xslt ファイルを使用してコンテンツを表示するように Web パーツをコーディングし、その xslt の場所を Web パーツの構成可能なプロパティにすることをお勧めします。これにより、コントロールの柔軟性が大幅に向上します。
Dataview Web パーツを見て、カスタム レンダリングを追加することでどれだけのことができるかを確認してください。