Вопрос

Первое, скажем, у меня есть 2 коллекции сайта в одном веб-приложении в порту 80:

  1. Основная коллекция сайтов: /
  2. вложенная коллекция сайта: / сайты / специальные /

    Так, скажем, у меня есть модуль в функции на уровне сбора сайта, целью которого является добавление пары сценариев на протяжении всей коллекции сайта (это так же легко можно развернуть как элементы управления ScriptLink на пользовательской главной странице Для коллекции сайта мой вопрос все еще применяется):

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

    Оба вышеупомянутых работа отлично, если функция активируется в основной коллекции сайта «root». Однако, если я только развернул функцию на вторичную «специальную» коллекцию сайта (новая граница изоляции, вложенный URL-путь), не будет ли ссылочный разрыв сценария?

    Браузер будет искать custom1.js на следующем пути:

    / Стиль Библиотека / mysolution / custom1.js

    Когда действительно файл находится в

    / сайты / специальные / стиль библиотеки / mysolution / custom1.js

    Второй сценарий всегда работает, поскольку _layouts - глобальный, и, таким образом, браузер всегда находит /_layouts/mysolution/custom2.js Независимо от того, какая коллекция сайта была развернута.

    правильно? Я думаю, я просто делаю чешую здравоохранение.

    Я соблазн легким доступом к скриптам, я могу редактировать на специальной основе в библиотеке / в стиле /, но ненависть идею, что такая функция (как указана выше) будет работать только в коллекциях сайта корневого уровня. ,

Это было полезно?

Решение

Попробуйте это для первой ссылки, поскольку она предназначена для того, чтобы удовлетворить именно то, что вы видите, хотя определенные элементы управления не расширяют значение.

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

Что касается того, следует ли оно в _layouts или библиотеке стилей - это дискуссия, с момента бета SP2007 в 2006 году без четкого победителя.Общее правило заключается в том, что если файл - это то, что может быть изменено владельцами сайта, то он должен идти в «библиотеке стилей», и если файл - это то, что только администраторы должны быть в состоянии изменить, то он идет в _layouts.Конечно, я упрощает, поскольку между двумя локациями есть как минимум десятка различий.

Это просто еще одно из мест, где официальный ответ SharePoint на все относится: «Это зависит»

Другие советы

Пожалуйста, посмотрите на ответы на Этот вопрос тоже Отказ Это сложная тема, без «правильного» ответа. Я думаю, что Крис О'Брайен подвел это довольно хорошо в своем ответе.

Мое личное мнение - это то, что это зависит :) В вашем случае, поскольку вы хотите использовать один и тот же файл .js в двух (или более) коллекциях сайта, я бы определенно поместил его под «_layouts».

Другой вопрос: у вас есть этапы развития? Разработка - Принятие-производство? У вас есть какой-то контроль источника? Если ответ на любой из них да, то я бы снова, определенно положил его под «_layouts». Особенно потому, что это файл JavaScript. Почему? Поскольку JavaScript также содержит «код», он выполняет какую-то логику, иногда она даже имеет бизнес-логику (скрыть что-то, если некоторые поля заполнены, проверяют данные перед отправкой и т. Д.). Если весь ваш код .NET Code проходит через Development-> Прием, прежде чем идти на производство, почему код JavaScript будет «привилегирован», идущий непосредственно к производству? Почему это не должно пройти через те же фазы тестирования? Конечно, это должно.

И если у вас есть исходный элемент управления, и вы используете модуль для развертывания вашего файла в библиотеку документов как «GhostableInLibrary», я думаю, что это начало кошмара, если вы позволите людям настраивать его. Представьте, что вы развернули ваш файл (JS или CSS) через модуль на 10 коллекций сайта. На 5 из них администраторы сайта изменили файл. Это означает, что ваш файл теперь отделен из версии в файловой системе. Когда вы хотите развернуть несколько глобальных изменений в этом файле, и хотите, чтобы он был применен на всех коллекциях сайта, он будет не проходить неудачу на тех, где файл был настроен. Вам нужно будет сначала вернуть эти файлы на определение сайта, а затем ваш файл, нажатый модулем, будет учитываться. Но вы потеряете любую модификацию, которые сделали эти администраторы сайта. Или, если вы хотите сохранить некоторые из этих модификаций и поставить его в вашу версию на исходном управлении ... вам придется принять каждый индивидуальный файл, один за другим, сравните их вручную с одним на исходном управлении, и объединить изменения Отказ Нет, я думаю, что это лучше избежать.

Но вы лучше знаете свою ферму SharePoint и как он будет использоваться. Поэтому, возможно, есть некоторые особенности в вашей настройке, которые требуют поместить эти файлы в стильную библиотеку. Если это так, пожалуйста, скажите мне, я любопытно :)

ура!

Лицензировано под: CC-BY-SA с атрибуция
Не связан с sharepoint.stackexchange
scroll top