サイトコレクションPOPクイズ：_Layouts vsスタイルのライブラリ

Question

最初に、ポート80で1つのWebアプリ内で2つのサイトコレクションを持っているとしましょう。

1. メインサイトコレクション： /
2. ネストされたサイトコレクション： / sites / special /

   SO、サイトコレクションスコープ機能にモジュールを持っているとしましょう。その目的は、サイトコレクション全体を通していくつかのスクリプトを追加することです（カスタムマスターページでScriptLinkコントロールとしてデプロイできるようにすることができます。サイトコレクションの場合、私の質問はまだ適用されます）：

     <CustomAction Id="script1" Location="ScriptLink" ScriptSrc="/Style%20Library/mySolution/custom1.js" />
     <CustomAction Id="script2" Location="ScriptLink" ScriptSrc="/_layouts/mySolution/custom2.js" />
   

   .

   本根元のサイトコレクションで機能が有効になっている限り、上記の両方が微調整します。ただし、セカンダリの「特別な 'サイトコレクション（新しい絶縁境界、ネストしたURLパス）にフィーチャを展開した場合は、Script1の参照がブレークしませんか？

   ブラウザは、次のパスにcustom1.jsを探しています。

   /スタイルライブラリ/ mysolution / custom1.js

   本当にファイルがにあるとき

   /サイト/スペシャル/スタイルライブラリ/ mySolution / custom1.js

   _Layoutsがグローバルなので、2番目のスクリプトリンクは常に機能します。したがって、どのサイトコレクションに展開されていても、常にブラウザが常に/ layouts/mysolution/custom2.jsを見つけます。

   正しい？私はちょうど健全性チェックをしていると思います。

   私は/スタイルのライブラリ/の広告ベースで編集できるスクリプトへの簡単なアクセスに魅了されていますが、（上で設計されたように）そのような機能がルートレベルのサイトコレクションでのみ機能するという考えを嫌います。 。

Answer 1

これを最初のリンクに試してみてください。

<CustomAction Id="script1" Location="ScriptLink" ScriptSrc="~SiteCollection/Style%20Library/mySolution/custom1.js" />

.

それが_layoutsまたはスタイルライブラリにあるべきかどうかに関して、2006年にSP2007ベータ以降は明確な勝者なしで怒鳴っていた議論です。一般的な規則は、ファイルがサイトの所有者によって変更されることができるものであるならば、それは「スタイルライブラリ」に入るべきであり、そのファイルが管理者だけが変更できるようにする必要がある場合は、_Layoutsに入ります。私は2つの場所の間に少なくとも1十分の違いがあるので、もちろん単純化しています。

これは、すべてのものに対する公式のSharePointの回答が適用される場所のもう1つのものです。 "それは"

Answer 2

この質問 。それは複雑なトピックです、「正しい」答えはありません。 Chris O'Brienが彼の答えでかなりよくそれを合計したと思います。

私の個人的な意見は、それが依存するのです。

もう一つの質問は、開発段階がありますか？開発受付産生産いくつかのソース管理がありますか？これらのどちらかに対する答えがYESであるならば、私は再び、「_layouts」の下にそれを絶対に置くでしょう。特にJavaScriptファイルであるためです。どうして？ JavaScriptには「コード」も含まれているため、ある種のロジックを実行します。時にはビジネスロジックを持つことさえあります（一部のフィールドが入力されている場合は何かを隠し、送信前にデータを検証するなど）。すべての.NETコードが生産に進む前に開発 - >承認を経ている場合は、プロダクションに直接行くことでJavaScriptコードが「特権」になるのでしょうか。なぜそれが同じテスト段階を通過しないのですか？もちろんそれはそうです。

そしてソース管理を持っていてモジュールを使用してファイルを「GhostableInlibrary」としてドキュメントライブラリにデプロイする場合は、人々にカスタマイズする場合は、悪夢の始まりだと思います。モジュールを介してファイル（JSまたはCSS）を10サイトコレクションに展開したと想像してください。そのうち5でサイト管理者はファイルを変更しました。つまり、ファイルはファイルシステム上のバージョンから切り離されていることを意味します。次にこのファイルにグローバルな変更を展開し、それをすべてのサイトコレクションに適用したい場合は、ファイルがカスタマイズされているもので静かに失敗します。これらのファイルをサイト定義に戻すには、最初にサイト定義に戻す必要があり、そのモジュールによってプッシュされたファイルが考慮されます。しかし、あなたはそれらのサイト管理者が行ったのはどんな変更でも失うでしょう。あるいは、それらの変更をいくつか保持してソースコントロールであなたのバージョンに置きたいのであれば...あなたは1つずつ、カスタマイズされたすべてのファイルを1つずつ実行する必要があります。 。いいえ、これは避けたいと思います。

しかし、あなたはあなたのSharePointファームがより良く知っていて、それがどのように使われるかを知っています。だからあなたのセットアップには、これらのファイルをスタイルライブラリに入れることを要求する特定のものがいくつかあります。もしそうなら、私に言ってください、私は興味があります：）

歓声！