Collezione sito Pop Quiz: _Layouts vs Style Library

Question

In primo luogo, diciamo che ho 2 raccolte di siti all'interno di una singola app Web alla porta 80:

.
1. Raccolta del sito principale: /
2. Collezione di siti nidificati: / Sites / Special /

   Allora, diciamo che ho un modulo in una caratteristica scoperta di collezione del sito, lo scopo è quello di aggiungere un paio di script in tutta una raccolta di siti (questo è possibile facilmente essere facilmente distribuiti come controlli ScriptLink in una pagina master personalizzata in una pagina master personalizzata Per una raccolta di siti, la mia domanda applica ancora):

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

   .

   Entrambi il funzionamento di cui sopra funziona finché la funzione viene attivata nella principale collezione del sito "root". Tuttavia, se ho schierato solo la funzione della "speciale collezione speciale del sito speciale (nuovo confine di isolamento, percorso dell'URL annidato), non sarà la rottura di riferimento Script1?

   Il browser cercherebbe personalizzato1.js al seguente percorso:

   .

   / biblioteca stile / mysoluzione / custom1.js

   Quando veramente il file è a

   .

   / Siti / Libreria speciale / stile / Mysolution / Custom1.js

   Il secondo ScriptLink funziona sempre, dal momento che _Layouts è globale, e quindi il browser trova sempre /_Layouts/mysolution/custom2.js, non importa quale raccolta del sito sia stata distribuita la funzione.

   corretto? Immagino che stia solo facendo un controllo sanitario.

   Sono tentato dal facile accesso agli script che posso modificare su base ad hoc nella libreria / stile /, ma, odiare l'idea che tale caratteristica (come progettato sopra) funzioni solo nelle raccolte del sito di livello root .

Answer 1

Prova questo per il primo link in quanto intende affrontare esattamente ciò che stai vedendo, anche se alcuni controlli non espandono il valore.

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

.

Per quanto riguarda se dovrebbe essere in _Layouts o in stile libreria è un dibattito che si è infuriato dalla beta SP2007 nel 2006 senza vincitore chiaro.La regola generale è che se il file è qualcosa che può essere modificato dai proprietari del sito, quindi dovrebbe andare in "Biblioteca stile" e se il file è qualcosa che solo gli amministratori dovrebbero essere in grado di modificare, allora va in _Layout.Sto semplificando, naturalmente, poiché ci sono almeno una dozzina di differenze tra le due località.

Questo è solo un altro dei luoghi in cui si applica l'ufficiale SharePoint a tutto ciò che si applica: "Dipende"

Answer 2

Guarda le risposte su Questa domanda . È un argomento complesso, senza risposta "corretta". Penso che Chris O'Bien lo abbia riassunto abbastanza bene nella sua risposta.

La mia opinione personale è che dipende da :) Nel tuo caso, dal momento che vuoi usare lo stesso file .js in due (o più) collezioni di siti, lo metterò sicuramente sotto "_layouts".

Un'altra domanda è: hai stadi di sviluppo? Produzione di sviluppo-accettazione? Hai qualche tipo di controllo sorgente? Se la risposta a uno di questi è sì, allora lo farei, di nuovo, lo mette sicuramente sotto "_layouts". Soprattutto perché è un file JavaScript. Perché? Poiché JavaScript contiene anche "codice", esegue una specie di logica, a volte ha anche la logica aziendale (nascondi qualcosa se alcuni campi sono compilati, convalidare i dati prima di inviare, ecc.). Se tutto il tuo codice .NET passa attraverso lo sviluppo-> Accettazione prima di andare alla produzione, perché il codice JavaScript sarebbe "privilegiato" andando direttamente alla produzione? Perché non dovrebbe passare attraverso le stesse fasi di prova? Ovviamente dovrebbe.

E se si dispone del controllo di origine e si utilizza un modulo per distribuire il file in una libreria di documenti come "GhostableinLibrary", penso che sia l'inizio di un incubo se lasci a personalizzarlo. Immagina di aver distribuito il tuo file (JS o CSS) attraverso il modulo su 10 raccolte di siti. Su 5 di loro gli amministratori del sito hanno modificato il file. Ciò significa che il tuo file è ora disaccoppiato dalla versione sul file system. Quando il prossimo si desidera distribuire alcune modifiche globali in questo file, e voler essere applicata su tutte le raccolte di siti, fallisce silenziosamente su quelle in cui il file è stato personalizzato. Avrai bisogno prima di ripristinare quei file alla definizione del sito e quindi il file spinto dal modulo verrà preso in considerazione. Ma perderai qualsiasi modifica che gli amministratori del sito hanno fatto. Oppure, se vuoi mantenere alcune di queste modifiche e metterlo nella tua versione sul controllo della fonte ... dovrai prendere ogni file personalizzato, uno per uno, confrontali manualmente con quello sul controllo sorgente e unire le modifiche . No, penso che questo sia meglio evitare.

Ma tu sai meglio della tua farm di SharePoint e come sarà usato. Quindi forse ci sono alcune particolarità nella tua configurazione che richiedono di mettere questi file nella libreria di stile. Se è così, per favore dimmi, sono curioso :)

Cheers!