사이트 모음 팝 퀴즈 : _layouts vs 스타일 라이브러리

Question

첫째, 포트 80 : 에 단일 웹 응용 프로그램 내에 2 개의 사이트 모음이 있다고 가정 해 봅시다.

1. 주요 사이트 모음 : /
2. 중첩 사이트 컬렉션 : / sites / special /

   이므로 사이트 모음에서 모듈을 가지고 있다고 가정 해 보겠습니다. 그로 인해 사이트 모음을 통해 두 개의 스크립트를 추가하는 것입니다 (사용자 정의 마스터 페이지에서 스크립트 링크 컨트롤로 배포 할 수있는 것처럼 쉽게 배포 할 수 있습니다. 사이트 모음의 경우 내 질문이 여전히 적용됩니다) :

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

   .

   은 메인 '루트'사이트 컬렉션에서 기능이 활성화되는 한 위의 작업이 모두 잘 작동합니다. 그러나 I 단지 보조 특별한 '특수'사이트 모음 (새 격리 경계, 중첩 된 URL 경로)에만 기능을 배포 한 경우 Script1 참조가 중단되지 않습니까?

   브라우저는 다음 경로에서 custom1.js를 찾고 있습니다.

   스타일 라이브러리 / mysolution / custom1.js

   실제로 파일이 에있을 때

   / 사이트 / 특별 / 스타일 라이브러리 / mysolution / custom1.js

   두 번째 스크립트 링크는 _layouts가 전역이므로 항상 브라우저가 항상 기능이 배포 된 사이트 모음을 상관없이 항상 /_layouts/mysolution/custom2.js를 찾습니다.

   수정? 나는 정신 검사를하고 있다고 생각합니다.

   스크립트에 쉽게 액세스 할 수 있습니다 / 스타일 라이브러리에서 광고를 편집 할 수있는 스크립트에 쉽게 액세스 할 수 있지만, 그러한 기능 (위의 설계된대로 설계)이 루트 레벨 사이트 컬렉션에서만 작동하는 아이디어를 싫어합니다. .

Answer 1

첫 번째 링크는 사용자가보고있는 것을 정확히 주소하기위한 것이므로 특정 컨트롤이 값을 확장하지 않도록하십시오.

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

.

_layouts 또는 style library에 있어야하는지 여부는 2006 년 SP2007 베타가 2006 년 SP2007 베타 이후로 분명한 승자가 없었습니다.일반적으로 파일이 사이트 소유자가 수정할 수있는 것이면 "스타일 라이브러리"로 이동해야합니다. 파일이 관리자 만 수정할 수 있어야합니다.나는 두 위치간에 적어도 12 가지 차이가 있으므로 단순화합니다.

이것은 모든 것이 적용되는 공식적인 SharePoint 답변이 "그것은 의존합니다"

Answer 2

이 질문 도

내 개인 의견은 다음과 같습니다. :) 귀하의 경우, 두 (또는 그 이상) 사이트 모음에서 동일한 .js 파일을 사용하려고하기 때문에 "_layouts"아래에 확실히 넣을 것입니다.

다른 질문은 다음과 같습니다. 개발 단계가 있습니까? 개발 수락 - 생산? 소스 컨트롤이 있습니까? 이 중 하나에 대한 답변이 '예'라면, 다시 "_layouts"아래에 확실히 넣을 것입니다. 특히 JavaScript 파일이기 때문입니다. 왜? JavaScript에는 "코드"가 포함되어 있기 때문에 일부 종류의 논리를 수행합니다. 때로는 비즈니스 논리가 있지만 일부 필드가 채워지면 일부 필드가 가득 차면 숨기기, 등록하기 전에 데이터 확인 등을 확인합니다. 모든 .NET 코드가 생산에 가기 전에 개발 -> 수락을 거치면 JavaScript 코드는 프로덕션에 직접 가면 왜 JavaScript 코드가 "특권"될 것인가? 왜 동일한 테스트 단계를 거치지 않아야합니까? 물론 그것은해야합니다.

원본 제어가 있고 모듈을 사용하여 파일을 "GhostableInlibrary"로 문서 라이브러리에 배포하는 경우, 사람들이 사용자 정의 할 수있게 해주는 경우 악몽의 시작이라고 생각합니다. 모듈을 통해 10 개의 사이트 모음으로 파일 (JS 또는 CSS)을 배포 한 것을 상상해보십시오. 5 개 사이트에서 사이트 관리자가 파일을 수정했습니다. 즉, 파일은 이제 파일 시스템의 버전에서 분리됩니다. 다음 으로이 파일에 전역 변경 사항을 배포하고 모든 사이트 모음에 적용하려면 파일이 사용자 정의 된 파일이 자동으로 실패합니다. 먼저 해당 파일을 사이트 정의로 되돌리려면 모듈에 의해 푸시 된 파일을 고려해야합니다. 그러나 사이트 관리자가 만들었던 수정을 잃어 버릴 것입니다. 또는 일부 수정 사항을 유지하고 소스 컨트롤에서 버전에 넣으려면 ... 하나씩 사용자 정의 된 파일을 하나씩 복용하고 수동으로 소스 컨트롤을 사용하여 수동으로 비교해야하며 변경 사항을 병합해야합니다. ...에 아니, 나는 이것이 피해야 할 것이 낫다고 생각한다.

그러나 SharePoint Farm 및 그것이 어떻게 사용되는지 더 잘 알고 있습니다. 따라서 이러한 파일을 스타일 라이브러리에 넣으려면 설정할 수있는 몇 가지 특수성이있을 수 있습니다. 그렇다면, 나는 말해 주시기 바랍니다, 나는 호기심이 있습니다.)

환호!