Questionário pop do conjunto de sites:_layouts vs biblioteca de estilos

Question

Primeiro, digamos que eu tenha dois conjuntos de sites em um único aplicativo Web na porta 80:

1. Conjunto principal de sites: /
2. Conjunto de sites aninhados: /sites/especial/

Então, digamos que eu tenha um módulo em um recurso com escopo de conjunto de sites, cujo objetivo é adicionar alguns scripts em todo um conjunto de sites (isso pode ser facilmente implantado como controles de scriptlink em uma página mestra personalizada para um site coleção, minha pergunta ainda se aplica):

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

Ambos os itens acima funcionam bem, desde que o recurso esteja sendo ativado no conjunto de sites 'raiz' principal.No entanto, se eu implantar o recurso apenas no conjunto de sites 'especial' secundário (novo limite de isolamento, caminho de URL aninhado), a referência do script1 não será quebrada?

O navegador procuraria custom1.js no seguinte caminho:

/Biblioteca de estilos/mySolution/custom1.js

quando realmente o arquivo está em

/sites/special/Biblioteca de estilos/mySolution/custom1.js

O segundo scriptlink sempre funciona, já que _layouts é global e, portanto, o navegador sempre encontra /_layouts/mySolution/custom2.js, independentemente de em qual conjunto de sites o recurso foi implantado.

Correto?Acho que estou apenas fazendo uma verificação de sanidade.

Sinto-me tentado pelo fácil acesso a scripts que posso editar ad-hoc na /Style Library/, mas odeio a ideia de que tal recurso (conforme projetado acima) só funcionaria em conjuntos de sites de nível raiz.

Answer 1

Tente isso para o primeiro link, pois o objetivo é abordar exatamente o que você está vendo, embora alguns controles não expandam o valor.

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

Se deveria estar em _layouts ou em Style Library é um debate que tem ocorrido desde o beta do SP2007 em 2006, sem um vencedor claro.A regra geral é que se o arquivo for algo que pode ser modificado pelos proprietários do site, ele deverá ir para a "Biblioteca de Estilos" e se o arquivo for algo que apenas os administradores devem poder modificar, ele deverá ir para _layouts.Estou simplificando, é claro, pois há pelo menos uma dúzia de diferenças entre os dois locais.

Este é apenas mais um dos locais onde a Resposta Oficial do SharePoint para Tudo se aplica:"Depende"

Answer 2

Por favor, veja as respostas em essa questão também.É um tema complexo, sem resposta “correta”.Acho que Chris O'Brien resumiu muito bem em sua resposta.

Minha opinião pessoal é que depende :) No seu caso, como você deseja usar o mesmo arquivo .js em dois (ou mais) conjuntos de sites, eu definitivamente o colocaria em "_layouts".

Outra questão é:você tem estágios de desenvolvimento?Desenvolvimento-Aceitação-Produção?Você tem algum tipo de controle de origem?Se a resposta para qualquer uma dessas perguntas for SIM, então eu definitivamente colocaria em "_layouts".Principalmente porque é um arquivo javascript.Por que?Como o javascript também contém "código", ele executa algum tipo de lógica, às vezes até possui lógica de negócio (ocultar algo se alguns campos forem preenchidos, validar dados antes de enviar, etc).Se todo o seu código .Net passa por Desenvolvimento-> Aceitação antes de ir para produção, por que o código javascript seria "privilegiado" indo diretamente para produção?Por que não deveria passar pelas mesmas fases de testes?Claro que deveria.

E se você tem controle de origem e usa um módulo para implantar seu arquivo em uma biblioteca de documentos como "GhostableInLibrary", acho que será o começo de um pesadelo se você permitir que as pessoas o personalizem.Imagine que você implantou seu arquivo (js ou css) por meio do módulo em 10 conjuntos de sites.Em 5 deles, os administradores do site modificaram o arquivo.Isso significa que seu arquivo agora está desacoplado da versão no sistema de arquivos.Da próxima vez que você quiser implantar algumas alterações globais nesse arquivo e que ele seja aplicado em todos os conjuntos de sites, ele falhará silenciosamente naqueles em que o arquivo foi personalizado.Você precisará primeiro reverter esses arquivos para a definição do site e então o arquivo enviado pelo módulo será levado em consideração.Mas você perderá qualquer modificação feita pelos Administradores do Site.Ou, se você quiser manter algumas dessas modificações e colocá-las em sua versão no controle de origem...Você terá que pegar cada arquivo personalizado, um por um, compará-los manualmente com aquele no controle de origem e mesclar as alterações.Não, acho que é melhor evitar isso.

Mas você conhece melhor o seu Sharepoint Farm e como ele será utilizado.Então talvez existam algumas particularidades na sua configuração que exigem colocar esses arquivos na Biblioteca de Estilos.Se sim, por favor me diga, estou curioso :)

Saúde!