COLECCIÓN DEL SITIO POP QUIZ: _LAYOUTS VS Style Library

Question

Primero, digamos que tengo 2 colecciones de sitios dentro de una sola aplicación web en el puerto 80:

1. Colección principal del sitio: /
2. Colección anidada del sitio: / sites / especial /

   Entonces, digamos que tengo un módulo en una función de colección de sitios, cuyo propósito es agregar un par de scripts a lo largo de una colección de sitios (esto tan fácilmente podría implementarse como controles de ScriptLink en una página maestra personalizada Para una colección de sitios, mi pregunta todavía se aplica):

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

   Tanto el trabajo anterior) Multa siempre que la función se esté activando en la colección principal del sitio 'Root'. Sin embargo, si solo implementé la característica a la colección de sitios "especial" secundaria (un nuevo límite de aislamiento, ruta de URL anidada), ¿no se rompe el script1?

   El navegador estaría buscando Custom1.js en la siguiente ruta:

   / Biblioteca de estilo / MySolution / Custom1.js

   cuando realmente el archivo está en

   / Sitios / Biblioteca especial / estilo / MySolution / Custom1.js

   El segundo Scriptlink siempre funciona, ya que _layouts es global y, por lo tanto, el navegador siempre encuentra /_layouts/mysolution/Custom2.js, sin importar en qué colección del sitio se implementó la función.

   correcto? Supongo que solo estoy haciendo un cheque de cordura.

   Estoy tentado por el fácil acceso a los scripts. Puedo editar una base ad-hoc en la biblioteca / estilo /, pero odio la idea de que tal característica (como se diseñó anteriormente) solo funcionaría en colecciones de sitios de nivel raíz .

Answer 1

Intente esto para el primer enlace, ya que está destinado a abordar exactamente lo que está viendo, aunque ciertos controles no amplían el valor.

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

En cuanto a si debería estar en _layouts o style biblioteca es un debate que se ha emitido desde la beta SP2007 en 2006 sin un ganador claro.La regla general es que si el archivo es algo que puede ser modificado por los propietarios del sitio, entonces debería ir en "biblioteca de estilo" y si el archivo es algo que solo los administradores deben poder modificar, entonces va en _layouts.Estoy simplificando, por supuesto, ya que hay al menos una docena de diferencias entre las dos ubicaciones.

Este es solo otro de los lugares donde se aplica la respuesta oficial de SharePoint a todo: "Depende"

Answer 2

Mira las respuestas en esta pregunta también . Es un tema complejo, sin respuesta "correcta". Creo que Chris O'Brien lo resumió bastante bien en su respuesta.

Mi opinión personal es que depende :) en su caso, ya que desea usar el mismo archivo .js en dos (o más) colecciones de sitios, definitivamente lo pondré en "_layouts".

Otra pregunta es: ¿Tienes etapas de desarrollo? ¿Desarrollo-aceptación-producción? ¿Tienes algún tipo de control de origen? Si la respuesta a cualquiera de estos es sí, entonces lo haría, de nuevo, definitivamente lo puse debajo de "_Layouts". Especialmente porque es un archivo JavaScript. ¿Por qué? Debido a que Javascript también contiene "código", realiza algún tipo de lógica, a veces tiene una lógica empresarial (ocultar algo si se completan algunos campos, valida los datos antes de enviar, etc.). Si todo el código de .NET pasa por el desarrollo-> Aceptación antes de ir a la producción, ¿por qué el código JavaScript sería "privilegiado" al ir directamente a la producción? ¿Por qué no debería pasar por las mismas fases de prueba? Por supuesto que debería.

Y si tiene un control de origen y usted usa un módulo para implementar su archivo en una biblioteca de documentos como "GhostableInlibraryInlibrary", creo que es el comienzo de una pesadilla si deja que las personas lo personalicen. Imagine que implementó su archivo (JS o CSS) a través del módulo a 10 colecciones de sitios. El 5 de ellos los administradores del sitio han modificado el archivo. Esto significa que su archivo ahora está desacoplado de la versión en el sistema de archivos. Cuando lo siguiente desea implementar algunos cambios globales en este archivo, y desea que se aplique en todas las colecciones de sitios, fallará en silencio en las que el archivo haya sido personalizado. Primero, necesitará primero revertir esos archivos en la definición del sitio y luego su archivo empujado por el módulo se tomará en consideración. Pero perderá cualquier modificación que los administradores del sitio han hecho. O, si desea mantener algunas de esas modificaciones y colocarlo en su versión en el control de origen ... Tendrá que tomar todos los archivos personalizados, uno por uno, compararlos manualmente con el de control de origen y fusionar los cambios . No, creo que esto es mejor ser evitado.

Pero sabe mejor su granja de SharePoint y cómo se va a utilizar. Así que tal vez haya algunas particularidades en su configuración que exigen que coloque estos archivos en la biblioteca de estilo. Si es así, por favor dime, tengo curiosidad :)

vítores!