'분류 전체보기'에 해당되는 글 1243건

대부분의 MOSS 2007 개발자들은 이 사이트와 웹 간의 차이를 명확히 모르거나 어렴풋이 알아도 그게 그거가 아닌가 라는 어조로 표현하곤 한다.
하지만 개념적으로 명확히 틀린 구조이며 그 차이는 명확히 틀리다.

다음 그림을 보면 대략적으로 왜 사이트와 웹이 틀린지 알 수 있다.

즉 사이트 여기서는 SPSite인데, 최상위의 일종의 거대한 상자라고 보면 될 것이다. 이 안에 무수한 SPWeb을 붙여서 하나의 사이트를 만드는 것이다. 즉 사용자들은 SPWeb을 보는 것이지 SPSite를 보는 것은 아니다. 실제 사용자가 보기 위한 페이지, 리스트들의 모든 정보들은 바로 저 SPWeb에서 나오고, 그 외에 전체 검색이나, 차이점 분석 결과 등 전체 사이트에 대한 설정, 구성, 정보들은 SPSite에서 다루게 된다.
우리가 보통 새끼까기 하듯이 사이트 아래에 사이트를 만든다고 하는데, 그건 SPSite를 만든 것이 아니고 바로 저 SPWeb을 만드는 작업이라고 보면 된다.

보통 개발자들이 혼돈을 느끼는 부분이 바로 여긴데, MOSS 관리자 페이지에 가면 사이트 만드는 부분의 명칭이 "사이트 모음 만들기" 라고 적혀 있고, 해당 사이트의 페이지에 가서 사이트 관리 도구에 들어가면 하위 사이트 만들기 라고 적혀 있으니, 사이트 모음 = SPSiteCollection, 사이트 = SPSite 라고 생각하는 우리의 입장에서는 이 또한 무슨 망발이냐!!! 라는 의문을 바로 제기할 수 있다. 

그.러.나. SDK를 보면 우리를 또 한번 더 햇갈리게 한다. 양키 말을 들어보면 Web, Site 구분없이 막지껄이고 떠든다. 뭐가 Web이냐, Site냐.. 최소한 난 이것 때문에 상당한 혼란을 일으켰다. 그러면 저 SPSite와 SPWeb은 1:1로 하나씩 묶여서 구성된 건가... 했다.

그러나 진실은 SPSite는 무조건 한개, 그 하위의 모든 사이트들은 SPWeb이다. 그를 증명하는 부분은 바로 컨텐츠 DB. 만일 사이트 모음을 한개 만들어 놓고, 그 안에 새끼 까듯이 계속 사이트들을 만들어 99개를 만들었다고 하자. 그 때 컨텐츠 DB안에 사이트는 몇개 일까?
    1개다.
궁금하신 분은 테스트 해보시면 알 수 있다.
즉 사이트 모음은 SPSite를 의미하기 때문에, 그 SPSite 갯수인 1개가 들어가고 그 이후에는 어차피 SPSite 내에 포함된 하위 SPWeb들이기 때문에, 컨텐츠 DB 입장에서는 사이트 갯수에 포함 안되고, 단지 1개의 SPSite가 좀 커졌구나... 정도로 인식할 뿐이다.
(즉 늘어나는건 컨텐츠 DB의 사이즈 뿐이다.)

이런 개체들의 관계를 따라, 각 개체를 참조 할 때는 아래와 같이 찾아 들어가면 된다.

Microsoft.SharePoint.Administrator.SPWebApplication 로 가는 방법

  [SPSite 개체].WebApplication

Microsoft.SharePoint.SPWeb로 가는 방법

  [SPSite 개체].OpenWeb("url")

그리고 만일 위의 그림에서 1번 사이트를 연 뒤 (new SPSite("1번 사이트 URL")) 한 뒤, 저 OpenWeb을 써서 2번 사이트 아래의 웹을 찾으려면 당연하게 오류를 뿜는다. 저렇게 그림으로 보면 당연하거 아녀? 라고 되묻겠지만, 간혹 어떤 분들이 1번 사이트 열어놓고, 2번 사이트 내의 웹이 안 열린다고 투덜 댄다. MOSS 2007 버그니 뭐니.. 하는데... 한번 즈음 소스 검사 해보심이 ...

그리고 만일 특정 SPSite 및의 모든 하위 사이트(절대 SPSite가 아니다, SPWeb 이다.)에 대해 세팅을 동일하게 적용한다고 했을 때는 해당 SPSite를 열고 RootWeb을 연 뒤, 그 RootWeb에서 Webs를 이용하여 트리 탐색하듯이 찾아 들어가야 한다. 1번 사이트를 보면 그 아래의 SPWeb 아래 SPWeb들을 뒤져야 된다.
그 검색로직은 트리를 찾는 방법대로 진행되어야 할 것이다.

아침을 좀 빠르게 일어나 앉았다.
사실 MP3 찾는 거라든가, 어제밤에 챙겨 놓지 않은 노트북등 정리안된 부분을아침으로 미루었기에 당연히 일찍 일어나야 하는데, 문제는 내가 보통 때 그 시간에 잘 일어나지 못한다는게 핵심이다. 어쨌던 일찍 일어난 아침 덕에, 그간 찾지 못해 못들었던 모차르트 K183 알레그로 콘 브리오를 다시 듣기 위해 뒤적였고, 못챙겼던 출근 가방 챙겼다. 그리고 여유 있는 아침과 함께 너무 일찍 일어나 생긴 현기증을 동시에 느끼면서 따듯한 방바닥을 바로 비비며 미묘한 유혹에 져볼까 말까 하는 아슬아슬한 도전도 즐겼다.

그리고 옷 챙겨 입고 나서는 순간 온 세상은 잿빛 속 흰색으로 가득찼다.
우중충한 하늘에서 무수하게 떨어지는 눈은 한가득 내려 우리집 앞쪽의 모든 지붕들을 감싸버렸다.
길가에는 덩어리 진 흰 눈덩이들이 나돌아 다니고, 사람들은 우산 챙겨 들고 이리저리 바쁘게 지나가고 했다.
나도 그 속에 파묻혀 회사로 향하다, 문득 이른 아침의 시간을 보고 사진기를 꺼내들었다.

집 앞쪽에 위치한 공원도 아닌 조그만한 휴식처에 소복히 쌓인 눈이 이뻐보였다고나 할까.
가끔은 이런 여유도 즐겨 볼만 한 것 같다.

예전에 매일 매일 포스팅을 목적으로 잡글들을 올리고, 또 올리고 올리다가,

까먹고 한참 동안 안올리고.

바빠서 안올리고.

핑계의 핑계를 계속 하다가, 일주일에 한번? 심지어는 한달에 2~3번 포스팅에 마치는 경우도 있었다.

(대표적인 예로 10월달, 11월 달? 그 때 한창 프로젝트 말기에 치닫다 보니....)

이번에 한번 내가 생각난 것들에 대해 조금이라도 짬을 내서 포스팅에 포스팅을 계속해온 결과,

근 한주 연속 포스팅을 기록했다. 스스로 축하(自祝)

아마도 오늘 이후에도 계속 포스팅이 이어질지는 모르겠지만,

가급적 자주 포스팅을 해야 겠다.

한 10여년 전.
아무도 없는 곳이라도, 컴퓨터와 게임만 있으면 그다지 심심하지 않게 살 수 있으리라 믿었다.
그런데, 조금 열악한 환경에서 네트워크 안되고, 사람없는 곳에서 게임은 아니지만,
이런저런 놀이 도구들이 있었지만, 무척이나 심심했다.

지금.
다른 건 모르겠지만, 인터넷만 되면 그다지 심심할 것 같진 않다. 각종 잡다한 자료들을 다운로드 받아서 공부하고 보고 즐기며, 커뮤니티 사이트에서 서로간의 공감대를 찾아보고, 관심을 가지고 이야기하고 채팅을 하며 글을 남기는 것으로 충분하리라 생각된다.

하지만, 역시 직접 사람을 만나 얼굴 맞대고 이야기하고 떠들고 먹는 것.
그리워지지 않을까?

어떻게 흘러갈진 알 수 없는 듯.

기본 제공하는 Field 중 User 필드가 있다.  이 안의 값을 가져오면 다음과 같은 형식으로 저장되어 있다.

WebID#;사용자이름.

만일 해당 SPWeb 내에 Users 내에 강냥이 라는 사용자가 등록되어 있을때,

44#;강냥이

이런 식으로 기록된다. 물론 저 44라는 것은 SPUser의 ID를 의미한다. ( 무슨 숫자가 될지는 SPWeb 이 알아서 결정한다. )
예전에 이 필드 내에 있는 값을 참조할 때는 #;를 구분자로 나누어 44로 SPUser를 찾아 값을 처리하고 그 뒤의 문자열로 값을 처리했다. 언제나 저 문자열에 대해 SPlit 로 해서 배열 짜서, 하나씩 대응 했다.

이 작업이 쉽다고 하면 쉬울 수 있겠지만, 은근히 짜증나는 작업이 아닐 수 없다. 그렇다고, 이 작업을 위한 별도의 Static 함수 만들기도 애매모호 할 때 가 있다. ( Utility 함수들이 담긴 별도의 DLL을 만든다고 할 때, 그 DLL을 모든 프로젝트에 포함시켜줘야 할 것이다.)

이 때 해결해주는 구세주가 있으니 바로 SPFieldUserValue 라는 클래스 이다.
이 클래스를 사용하면 모두 끝난다고 보면 된다.
사용방법은 간단하다.

SPList list = web.GetList(http://wataru/Lists/Test);
SPListItem item = list.Items[0];
string sAuthorContext = item["Author"] as string;
SPFieldUserValue authorValue = new SPFieldUserValue(list.ParentWeb, sAuthorContext);
if(authorValue.User != null)
{
    String sLoginName = authorValue.User.LoginName;
}
else
{
      // 웹 내에 사용자가 없음
}

즉 SPFieldUserValue 클래스를 new로 생성할 때, 해당 SPWeb 개체와 User 필드내의 값 String만 넣으면 그 결과값을 바로 확인 할 수 있다.

.......

이 내용은 http://www.sharepoint-tips.com/2007/10/another-simple-code-snippet-using-user.html 에서 본 뒤 쇼크 받고 올린다.

Document Library는  SPList의 한 종류인 동시에, 오로지 File만을 저장할 수 있는 일종의 웹폴더와 같은 구조로 된 변종 List 이다.
SPList로써 생성을 할 때, List Template 중 “문서 라이브러리”라는 형태로 만들어 주면 탄생하게 된다.그러나, 일반 Customize List 처럼 다양한 Field들을 엮는 형태가 아니고, 기묘하게 그 안에 폴더를 넣을 수 있으며 다양한 종류의 파일을 독자적으로 넣을 수 있게 되어 있다.

그러기에 지금까지 게시판 류와 같은 형태로 다루기에는 조금 내용이 다르게 진행 된다.
이 작업 중 가장 나에게 큰 태클을 걸어주신 부분은 바로 Folder 만들기.
이 부분을 하기 위해 SPList의 각종 메소드들과 속성들을 확인해 봤는데, 가장 근접한 내용은 바로 Folders라는 항목을 이용하는 것까지는 알았는데, Add를 해도 Item을 업데이트 해도 반응이 없었다. 게다가, Add 안에 들어가는 Url의 의미도 정확히 알 수도 없었다.

이에 몇 개 사이트를 돌아다니다가, 겨우 방법을 찾았다.

만일 아래와 같은 구조의 문서 라이브러리 가 있다고 할 때 생성 방법은 아래와 같다.

// 문서라이브러리1 ---> AAAA -> BBBB
//                      |
//                       --> AAAA2


// 문서 라이브러리에 해당하는 List를 얻어온다.
SPList docLib1 = web.Lists[“문서라이브러리1”];

// 문서 라이브러리의 옵션 중 폴더 생성 가능하도록 한다.
docLib1.EnableFolderCreation = true;

// AAAAA 폴더를 생성한다.
SPFolder fld_AAAAA = docLib1.RootFolder.SubFolders.Add(docLib1.RootFolder.Url + “/” + “AAAAA”);
fld_AAAAA.Update();

// AAAAA 밑의 BBBB를 생성한다.
SPFolder fld_BBBB = fld_AAAAA.SubFolders.Add(fld_AAAAA.Url + “/” + “BBBB”);
fld_BBBB.Update();

// AAAAA와 동일한 레벨로 AAAA2를 생성한다.
SPFolder fld_AAAA2 = docLib1.RootFolder.SubFolders.Add(docLib1.RootFolder.Url + “/” + “AAAA2”);
fld_AAAA2.Update(); 

즉 리스트의 RootFolder라는 부분에서 시작하여 SubFolder라는 속성값을 이용해 계속 Add로 추가해 준다. 해당하는 Url은 리스트의 RootFolder URL을 시작으로해서 계속 내려가 주면 된다. 무엇보다 제일 먼저 SPList의 EnableFolderCreation을 반드시 true로 만들어 준다.

생각보다 재미있는 사이트를 발견했다.

http://me2day.net/neohind

위의 URL은 현재 내가 만든 사이트 인데, 이 사이트는 대략 250자의 글을 등록할 수 있는 단순한 페이지.

그리고 그 글에 동감하면 me2 카운트가 오르게 된다.

사실 다른 복잡한 부분을 떠나서, 단순한 댓글 수준의 글로

수많은 댓글과 동감이 어울어 진다는게 단순미 넘치는

훌륭한 커뮤니티 인듯 싶다.

단순한 기능에서 날카로운 커뮤니티의 장점을 살린듯.

MOSS 2007 을 설치한 후, 예전에 CPU 개수(또는 코어) 만큼 웹가든을 만드는 것이 좋다는
의견이 있었다. 그런데, 이 내용은 32bit에서나 적용될 내용이라는 것이다.
그 이유는 보통 32Bit에서는 내부 가상 메모리의 최대 크기가 2G 뿐인데,
만일 700M 이상 넘어가면, 가비지 Collection 작업이 돌게 되는데,
이 때 CPU 사용률이 엄청나진다는 것이다. 그래서 가급적 32Bit 머신에서는
여러개의 웹가든을 두어 이 가비지 Collection 작업을 적게 발생하도록 하는 것이다.

그런데, 64Bit 에서는 최대 가상 메모리 크기가 7T 이기 때문에,
이 가비지 Collection 작업이 전무 하다. 그러므로 여러개의 웹 가든을 잡을 필요조차 없다.
이 사항은 MS SharePoint 프로덕트 팀에서 말한 내용에서 언급 되어 있다.
( MOSS 2007 SP1 배포 문서에 이 내용이 담겨 있다고 한다. )