質問

カスタム SharePoint アプリケーション ページを _layouts フォルダーに展開しています。これは、カスタム コンテンツ タイプのカスタム「新しいフォーム」です。このページを操作しているときに、リストに項目を追加する必要があります。ページが最初に読み込まれるときに、SPContext.Current.List を使用して、作業中の現在のリストを確認できます。しかし、フォームに入力し、フォームがそれ自体にポストバックし、IsPostBack が true になると、SPContext.Current.List が null になるため、内容を追加する必要があるリストが見つかりません。

これは期待されていますか?

ポストバック全体にわたってコンテキスト リストに関する情報を保持するにはどうすればよいですか?asp:hidden コントロールにリストの guid を設定し、ポストバックでそこから取り出すだけでよいでしょうか?それは安全だと思います。

FWIW、これは MOSS 2007 Standard バージョンです。

役に立ちましたか?

解決

一般的に、私は独自の機能を追加しようとする場合、製品グループが採用しているアプローチは何でもコピーしようとします。この場合、リスト定義自体を介して独自の編集/表示/追加ページを追加します。

私が構築したソリューションには、残念ながらオープンソースではなく、独自のカスタム「新規」フォームも必要でした。ただし、興味がある場合は、「タグ付きリンク」(SharePoint のソーシャル ブックマーク)と呼ばれるそれをダウンロードできます。また、私のサイトでいくつかのリンクを見つけることができます。ブログ。

いくつかのヒントとヒントを提供するには、次のことを参考にしてください。正しい方向に進むことができるはずです。

  1. 新しいリスト定義を作成しました。
  2. 新しいコンテンツ タイプの作成 コンテンツ タイプでは、フォームの「中間」ビットに表示される内容を決定するレンダリング テンプレートを参照する独自の「フォーム テンプレート」を定義できます。
  3. 標準のレンダリングテンプレートをコピーしましたが、必要な変更を加えました。
  4. すべてをソリューションにまとめてデプロイしました。

実際、私のレンダリング テンプレートにはオーバーライドされた「保存」ボタンが含まれており、保存中に必要な多くの追加作業をここで実行しました。

いずれにせよ、これは私の意見では少し大変な作業ですが、製品開発者が採用する標準的なアプローチに最もよく一致すると思います。さらに詳しい情報が必要な場合はお知らせください。ステップバイステップのブログ投稿をまとめることができるかどうか確認しますが、これが正しい方向に進むことを願っています。

他のヒント

フォーム テンプレートでは実行できない操作が _Layouts ファイルで実行できるとしたら、驚くでしょう。ほぼ同じテクノロジーを自由に利用できます。

SharePoint が ListItems および Layouts ページ (たとえば、リスト項目の「アクセス許可の管理」) を操作する方法を見ると、クエリ文字列を介していくつかの変数を渡していることがわかります。?obj={76113B3A-FABA-4389-BC85-4BB2CC5AB423},6,LISTITEM&List={76113B3A-FABA-4389-BC85-4BB2CC5AB423}

おそらく、これらの値を使用してプログラムで毎回コンテキストを取得します。

カスタムの「新しいフォーム」を使用していないため、これは当てはまらない可能性があります。イベント レシーバーをカスタム コンテンツ タイプに追加し、ItemAdded イベントまたは ItemsAdding イベントでカスタム コードを実行しました。このコードは、イベントがリストに追加されると起動されます。イベント レシーバー プロパティを使用して、親のリスト、Web、およびサイトにアクセスできます。

カスタムフォームを使用しているため、ここでの問題は「特別」であると考えたいと思います。カスタム FormTemplate ではなくカスタム フォームを使用することを選択したのは、単純に、SharePoint リストらしくない作業 (サードパーティ アプリから情報を取得するために Ajax 呼び出しを実行し、それに基づいて動的フォーム要素を生成すること) を多く行っているためです。その ajax 結果、その後のポストバックでのそのデータの処理)。通常のカスタム レンダリング テンプレート メカニズム内でこれを試すのは悪夢になるだろうと思いました。

また、このリストには複数のコンテンツ タイプが関連付けられており、各コンテンツ タイプには独自のカスタム フォームがあるため、リスト定義自体でカスタム フォーム宣言を指定することはできないと思います (ありがたいことに、もう 1 つのタイプははるかに単純です)。

実際、リスト GUID を非表示フィールドに保持するという私の簡単な方法は、この特定の問題に対処するための非常に影響の少ない方法でした。私の主な懸念は、ここでポストバックすると SPContext がすべての有用性を失う理由がわからないことであり、何か間違ったことをしているのではないかと思われることです。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top