코드 없는 솔루션: 목록 항목이 마지막으로 변경된 이후의 일 표시

작성자: Justin Joyce, LANtek

개요: 코드가 없는 사용자 지정 에이징 보고서

SharePoint 사이트에서 자주 요청되는 기능 중 하나는 작업 또는 목록 항목에 대한 노후화 보고서입니다. 즉, 이 목록 항목을 마지막으로 수정한 지 며칠/몇 개월이 지났습니까?

표면적으로 이것은 매우 간단한 요청처럼 보입니다. 결국 생성 및 수정되는 항목에 대한 날짜가 있으며, 이벤트 수신기를 통해 항목에 대한 특정 변경 사항이 발생할 때 사용자 지정 날짜를 저장할 수 있습니다. 정보로 작업하기 위해 Excel과 유사한 수식을 포함할 수 있는 계산된 열이 있습니다. 이것은 매우 간단한 제안처럼 보입니다. 날짜 필드를 선택하고 계산된 열을 만든 다음 [DateField] – [Today] 줄을 따라 수식을 수행합니다. 아, 그렇게 빠르지는 않지만! 이 "간단한" 작업을 시도해 본 사람이라면 누구나 알고 있듯이 계산된 열에서 [오늘]과 같은 것을 사용하려고 하면 문제가 발생합니다. 계산 열의 수식 상자에 [오늘]을 삽입하면 다음과 같은 오류 메시지가 나타납니다.

그 이유는 무엇입니까? 계산된 열이 계산되는 방식과 관련이 있습니다.

간단한 수식을 예로 들어 보겠습니다.

= IF( [Column1]<=[Column2], "OK", "Not OK")

이 모든 것은 Column1이 Column2보다 작거나 같으면 OK를 표시하고 그렇지 않으면 Not OK를 표시한다는 것입니다. 이는 계산된 열에 대한 매우 일반적인 기본 수식이며 다음 열을 포함하는 목록 항목에 대해 기본적인 가정을 합니다. Column1 및 Column2의 값은 목록 항목에 대한 업데이트 이벤트 없이는 변경할 수 없습니다.

맞습니다, 계산된 열은 계산 중인 정보가 항목 자체에 포함되어 있다고 가정하기 때문에 목록이 업데이트(또는 생성)될 때만 다시 계산됩니다. 이렇게 하면 오늘 날짜와 같이 항목의 필드와 독립적으로 변경되는 항목을 사용하려고 할 때 문제가 발생합니다.

이제 나는 그들이 계산된 열이 작동하는 방식이라고 결정한 회의에 참석하지 않았지만, 교육적인 추측을 해야 한다면 성능을 위해 이러한 방식으로 작동한다고 가정할 것입니다. 수천 개의 항목 목록이 있고 각 항목에 "라이브" 업데이트가 필요한 계산된 열이 포함되어 있다고 상상해 보십시오. 이는 타이머 작업과 같은 일부 메커니즘이 계산된 열을 포함하는 각 항목을 자주 반복하고 값을 업데이트해야 함을 의미합니다. 대규모 배포에서는 이 작업이 지속적으로 실행되고 변경될 수 있으므로 성능 측면에서 매우 부담이 될 수 있습니다. 그것은 단지 내 추측일 뿐이지만 생각해보면 꽤 의미가 있습니다.

먼저 Today라는 열을 만든 다음 수식에 추가한 다음 삭제하여 SharePoint를 속여 Today 값을 수락하도록 하는 유사한 솔루션에 대한 몇 가지 제안이 떠돌고 있습니다. 이것들은 모두 훌륭하지만 계산된 열이 업데이트될 때 내가 말한 것을 기억하십시오. 이 값은 항목이 업데이트될 때만 변경됩니다. 즉, 특히 일일 계산의 경우 값이 곧 올바르지 않게 됩니다.

나는 다른 사람들이 영리한 JavaScript를 사용하여 페이지에 값을 쓰는 것을 보았습니다. 이것도 작동하지만 피할 수 있는 경우 클라이언트 스크립트에 거의 반대합니다.

구현:

그래서 무엇을 해야 할까요? 계산된 열은 Today와 같은 소위 "휘발성" 함수의 경우 문제가 되지 않습니다. 계산된 열, 타이머 작업 또는 예약된 프로세스와 같이 이를 처리하기 위해 일부 사용자 지정 코드를 개발하여 이 계산이 필요한 모든 단일 항목을 업데이트할 수 있습니다. 그것은 우리가 마지막 단락에서 언급한 성능 문제로 돌아가게 하며, 또한 문제의 사이트/목록/열에 매우 구체적인 취약한 솔루션입니다. 이 두 가지 우려 사항 외에도 코딩하는 방법을 알고 이 솔루션을 개발하도록 설득하는 저와 같은 괴상한 사람을 찾아야 합니다. 하지만 더 쉬운 방법이 있습니다!

사이트에서 필드를 만들고 페이지를 편집할 권한이 있고 XSLT 및 보기 만들기에 대한 지식이 있는 경우 목록 보기에 포함할 수 있는 XSL 템플릿을 구성할 수 있으며 페이지가 요청될 때마다 값을 충실하게 계산할 수 있습니다. 이 시나리오에서는 성능에 대한 우려가 제거되며, 솔루션을 통해 사용자 지정 코드를 개발하고 배포할 필요가 없습니다.

완벽합니다. 그럼 어떻게 해야 할까요?

1. 원본으로 사용할 필드를 만들거나 선택합니다. 날짜 형식이어야 합니다.
2. 계산 중인 값의 자리 표시자 역할을 할 필드를 만듭니다.
3. 이러한 필드를 콘텐츠 형식에 추가하고 해당 콘텐츠 형식을 목록에 추가합니다.
4. 원본 열과 자리 표시자 열을 모두 포함하는 해당 목록의 보기를 만듭니다.
5. 스타일 라이브러리에 XSL 템플릿을 업로드합니다.
6. UI를 통해 목록 보기 웹 파트에 대한 "XSL 링크" 속성을 설정합니다.
7. 성공!

예제 사용 사례를 살펴보고 구현을 살펴보겠습니다. 고객은 특정 목록 항목이 해당 상태에 있는 시간을 알려주는 기본 목록 보기를 원했습니다. 이 목록에는 항목 유형에서 파생되어 목록에 추가된 사용자 지정 사이트 콘텐츠 형식이 포함되어 있습니다. 목록 항목의 상태 필드가 변경될 때마다 캡처하고 해당 날짜를 "상태 변경된 날짜"라는 열에 저장하는 이벤트 수신기가 이미 있었습니다. 이 모든 배선은 필요하지 않으며 모든 날짜 필드로 수행할 수 있습니다(이것이 우리의 구현이지만 자유롭게 실험하십시오). 필요한 최소한의 것은 목록에 추가된 계산을 보관하기 위한 원본 날짜 필드와 자리 표시자 필드(자세한 내용은 다음 단락에서 설명)이지만, 사이트의 다른 위치에서 이 솔루션을 재사용하려면 사이트 열 및 사이트 콘텐츠 형식을 사용하는 것이 좋습니다.

따라서 오늘 날짜를 계산하는 데 사용할 수 있는 원본 날짜가 있습니다. 이제 계산된 값의 컨테이너로 사용할 사용자 지정 사이트 열을 만들 수 있습니다. 이 경우 새 항목 또는 편집 항목 양식에서 변경할 수 없기 때문에 계산된 열을 사용하기로 선택했지만 사용자가이 열에 임의의 값을 입력하는 것을 원하지 않기 때문에 보기에 표시하도록 선택할 수 있습니다. 보기 등에 표시되지 않는 이유가 혼란스러울 수 있습니다.

이제 사이트 열이 있으므로 목록에서 사용할 콘텐츠 형식에 추가할 수 있습니다. 다음으로 나중에 XSLT로 사용자 지정할 보기를 만들어야 합니다. 원본 날짜 열과 계산된 값의 자리 표시자 역할을 할 새 계산 열이 포함된 표준 보기를 만들어야 합니다.

이제 사용자 지정 에이징 보고서를 지원하는 데 필요한 모든 것이 준비되었습니다. 남은 것은 XSL 템플릿을 만들고, 사이트의 스타일 라이브러리에 업로드하고, 목록 보기에 연결하는 것입니다. 사용할 XSL 템플릿에는 보기를 생성하기 위한 일반적인 SharePoint 생성 태그와 이 항목의 특정 부분을 재정의하고 원하는 값을 계산하는 데 사용되는 사용자 지정 태그가 포함됩니다.

이 솔루션에 사용하는 실제 계산을 수행하기 위한 XSL 템플릿은 MSDN 포럼의 "swirch"에서 친절하게 제공되었습니다.
http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/

여기에 있는 XSL 스타일시트(aging.zip)를 다운로드하십시오.
https://OneDrive.live.com/?cid=c262e8e2d59a86d9&permissionsChanged=1&id=C262E8E2D59A86D9!104

즐겨 찾는 텍스트 편집기에서 이것을 열면 보기를 렌더링하기 위한 많은 일반 SharePoint XSL 마크업을 볼 수 있으며, 357행까지 계속 아래로 스크롤하면 마크업에 추가한 사용자 지정 템플릿의 시작 부분을 볼 수 있으며, 첫 번째 템플릿은 "DateDiff" 템플릿 다음에 "calculate-julian-day" 및 "FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status"가 옵니다. 다음은 계산을 만들고 보기에 표시하는 세 가지 템플릿입니다. 이 문서의 앞부분에서 지정한 것과 다른 필드 이름을 사용하려는 경우 이러한 템플릿을 검토하여 다른 이름에 대한 참조를 바꿔야 합니다. 이를 위해서는 표시 이름이 아닌 필드의 내부 이름을 사용해야 합니다.

템플릿을 사용할 준비가 되었다면 스타일 라이브러리로 이동하여 "XSL 스타일 시트" 폴더에 업로드한 다음 파일 링크를 복사합니다. 이렇게 하면 나중에 쉽게 변경하거나 원하는 대로 사이트의 다른 부분에 추가할 수 있습니다.

다음으로, 목록으로 이동하여 이 문서의 앞부분에서 만든 보기를 선택합니다. "사이트 작업" 메뉴에서 "페이지 편집"을 클릭합니다.

페이지에서 목록 보기 웹 파트를 찾고 오른쪽 위 모서리에 있는 작은 아래쪽 화살표를 클릭하여 웹 파트 메뉴를 엽니다. 이 메뉴에서 "웹 파트 편집"을 선택합니다.

그러면 브라우저 창의 오른쪽에 웹 파트 메뉴가 열립니다.

"기타" 섹션의 +를 클릭하고 "XSL 링크" 속성을 찾습니다.

앞서 복사한 스타일 라이브러리의 XSL 파일에 대한 링크를 붙여넣습니다(상대 또는 절대 링크일 수 있음).

"확인"을 클릭하여 변경 내용을 저장한 다음 페이지 상단의 "페이지" 리본에서 "편집 중지" 버튼을 클릭합니다.

모든 항목이 올바르게 구성된 경우 이제 "상태 일" 열에 숫자가 표시됩니다.

마지막으로, 다양한 날짜의 일부 테스트 데이터로 어떻게 표시될지 다음과 같습니다.

요약:

여기 있습니다: SharePoint에서 에이징 보고서를 만드는 멋지고 형식이 좋고 강력하며 성능이 뛰어난 방법입니다. 간단한 코드 없는 구현으로 완성됩니다. 여기에는 여기에서 살펴본 한 가지 사용 사례 외에 꽤 많은 잠재적인 응용 프로그램이 있습니다. 이러한 보고서 유형의 또 다른 일반적인 시나리오는 작업을 만든 이로부터 경과된 시간을 한눈에 확인할 수 있도록 작업 목록에 첨부하는 것입니다.

사용을 즐겨 보세요!

--저스틴

Justin Joyce, LANtek

메모

누락된 단계
2012/10/8 오전 3:51
좋아, 나는 단계를 따랐지만 뭔가 빠져야합니다 - XSL은 어떤 날짜를 사용할지 또는 그 이후의 일을 추가할 필드를 어떻게 알 수 있습니까? 단계를 놓친 것을 싫어합니다.

노코드, 동의합니다!
2012/8/30 오후 12:12
나는 동의합니다 - 나는 이것이 실제로 "코드 없음"으로 간주되지 않는다고 생각합니다.
흥미롭게도 SharePoint의 일부 실패를 통해 Today를 사용하여 작동하는 계산 열이 생겼습니다. 다시 할 수 없기 때문에 방법이나 이유를 잘 모르겠지만 여전히 거기에 있고 작동하고 있습니다.

"상태 일수" 계산 열에 대한 수식을 사용하나요?
2012/5/2 오전 7:39
Justin - "상태 일수" 계산 사이트 열(자리 표시자 열)에 사용한 수식은 무엇인가요? "=오늘"이었나요?

SharePoint 2007
2011/12/2 오전 11:29
현재로서이 솔루션을 SharePoint 2007에 적용하려고 시도하지는 않았지만 조사하고 있습니다. 아쉽게도 UI를 통해 웹 파트에 XslLink 속성이 표시되지 않습니다.

좋은 게시물
2011/11/30 오전 9:53
안녕하세요
좋은 게시물입니다.
SharePoint 2007을 사용하고 있습니다.
위에서 언급한 기타 섹션이 없습니다.
SP2007 구성을 위한 단계가 있습니까?
감사합니다.

Re: 코드 없는 솔루션: SharePoint 목록 항목이 마지막으로 변경된 이후의 일 표시
2011/10/11 오전 8:24
안녕하세요, Chris.
좋은 발견!
오늘 후반에 게시한 내용을 살펴보고 이 솔루션을 좀 더 강력하게 만들 수 있는지 알아보겠습니다.
게시물이 마음에 드셔서 기쁘고, 유럽식 날짜 형식에 대한 해결책을 찾을 수 있어서 매우 기쁩니다. :)
-저스틴

유럽 날짜 형식용 솔루션
2011/10/11 오전 6:45
안녕하세요, Justin,
참고로, 이 페이지에서 이전에 언급한 문제에 대한 해결책을 찾았습니다.
https://sharepointbydummies.wordpress.com/2011/07/13/possible-work-around-to-date-format-issue-sharepoint-2010/

유럽식 날짜 형식
2011/10/7 오전 3:59
안녕하세요, Justin,
이것은 정말 좋은 해결책입니다. 감사하며, 지난 이틀 동안 내가 찾던 것과 같은 종류의 것입니다! 그러나 나는 그것에 대해 약간의 문제가 있고 당신이 나를 도울 수 있기를 바랐습니다.
"DateDiff" 함수의 마지막 줄에 있는 변수를 전환하여 이후가 아니라 어떤 일이 일어날 때까지의 일수를 계산하기 위해 코드를 약간 변경했습니다.

<xsl:value-of select="$JulianToday - $JulianStartDate"></xsl:value-of>

그러나 절반의 시간만 차이를 올바르게 계산할 수 있습니다. 따라서 이 날짜(dd/MM/yyyy 형식)를 instance 사용합니다.

30/12/2011

올바르게 계산되지만 이 날짜(동일한 형식)로

12/10/2011

2011년 10월 12일이 아닌 2011년 12월 10일인 것처럼 계산됩니다.
다음과 같이 "JulianStartDate"변수에서 일 및 월 값의 위치를 간단히 전환하려고 시도했습니다.

<xsl:with-param name="Month" select="substring(ddwrt:FormatDateTime(string($StartDate), 1033, 'yyyyMMdd'),7,2)"/>
<xsl:with-param name="Day" select="substring(ddwrt:FormatDateTime(string($StartDate), 1033, 'yyyyMMdd'),5,2)"/>

그리고 이것은 두 번째 데이트의 문제를 해결했지만 첫 번째 데이트에서는 부정확했습니다!
또한 유럽 LCID를 사용하도록 FormatDateTime 호출을 변경하고 FormatDateTime의 마지막 매개 변수 (예 : ddMMyyyy, MMddyyyy)에 대한 다양한 변경을 시도했지만 성공하지 못했습니다.
어떤 조언이든 주시면 대단히 감사하겠습니다.
감사합니다.
Chris

No-Code
2011/9/21 오전 4:27
XSL 언어를 이해하는 것이 모든 사람을 위한 것은 아니지만 프로그래밍을 포함하지는 않기 때문에 XSL이 "no-code"솔루션으로 자격이 있다고 생각하지 않습니다. 그 외에도: 좋은 해결책, 감사합니다!