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

MOSS의 기능 중(WSS의 상위 제품) 게시라는 기능이 있다.
Publish 라고 하며, ASPX 페이지 자체를 보관할 수 있고, 다양한 마스터를
미리 얹어 놓고, 변경해줄 수 있는 진정한 포탈을 위한 사이트라고 보면 된다.

이렇게 구성된 사이트에서 시작페이지와 마스터페이지를 프로그램 상으로 변경하는
방법을 소개한다.

1. 시작 페이지 변경 방법.

보통 시작페이지 설정은 사이트 설정 페이지 내에서 시작페이지 변경에 들어가,
설정하려는 페이지의 URL을 넣어서 처리하곤 했다. 그런데, 프로그램 상에서는
어떻게 처리해야 되는지 전혀 나와있지 않아 조금 곤란했다.
같은회사에 있는 녀석이 이 내용을 찾았는데, 그 내용을 정리하면 아래와 같다.

SPFolder forder = web.RootFolder;
forder.WelcomePage = "Pages/MyStartPage.aspx";
forder.Update();

저 Pages라는 내용이 있는데, 게시 사이트를 만들게 되면 자동으로 생성되는 ASPX 저장용 SPList이다. 이 SPList 상에 저 페이지를 넣어주면 된다. 해당 SPList 에 파일 넣는 방법은 아래와 같다.

FileStream chgstartFile = new FileStream(this.MapPath("/_layouts/MyStartPage.aspx"), FileMode.Open)
SPFolder forder = web.RootFolder;
web.Files.Add("MyStartPage.aspx", chgstartFile.OpenBinary(), true);
folder.Update();
chgstartFile.Close();

일단 Pages 라는 List에 잘 들어가면 한큐에 끝난다.( 사이트 생성용 ONET.XML에서도 처리할 수 있다고 한다. )

2. 마스터 변경 방법

이 방법이 제일 쉽다. 일단, 위의 파일 업로드하는 로직을 이용하여, /_catalogs/masterpage/ 라는 SPList에 변경할 마스터 파일을 업로드 해준다.

그리고 난 뒤 아래의 로직을 실행하면 된다.

web.MasterUrl = "/_catalogs/masterpage/MyMaster.master";
web.Update();

일단 web의 Root 폴더와 web 자체의 Update 해야 하므로, 최소한 모든 권한을 가진 사용자여야만 사용가능한 명령이다.

WSS/MOSS 들고 다양한 사이트에 가다보면, 마스터를 심각하게 뜯어버려, "사이트 작업" 이라는 버튼이 없어졌을 때 발생하는 문제가 종종 있다.

그 중, 페이지 편집이라는 버튼이 없어진 경우가 그 경우이다.

사이트 작업 버튼이 있을 때는 간단하게 되었는데, 없어지면 웹파트 추가건 뭐건
아무것도 안된다. 이럴때.... 이렇게 한다.

페이지 편집을 시도할 페이지에서 주소 창에 아래의 내용을 입력한다.

그러면 자동적으로 페이지 편집 모드로 들어가게 된다.

아주 간단한 팁.

공지에도 언급했지만, 이번에 파일들을 정리하면서, 이 Text Cube도 업그레이드 작업을 시행했습니다.
처음에는 Setup.php가 동작하지 않아, 많이 곤란했었는데,
알고 보니, Library에 파일들이 전부 다 올라가지 못해 발생한 문제였더군요.
파일들을 완전히 다 올리고 나니 정상 작동하더군요...
많이 애 먹었읍니다.

바뀐 김에 스킨도 바꿨습니다.
원본 스킨은 [TT,TC,Tistory] Easy Black - 2단 스킨 인데 무척 깔끔하고 딱 정형적인
제 스타일이더군요. 군더더기도 없고, 깔끔하니...
단지 영어로 너무 점철되어 있는데다(디자인상 어쩔 수 없는듯...)
제가 안쓰는 메뉴링크들은 일부 수정했습니다.
재 배포는 전혀 할 수 없기 때문에, 제작자에게 알리지는 않았지만요 ㅎㅎ.

뭐 일단, 나름대로 정리되서 마음은 한결 낫습니다.

이제 남은건 포스팅만 남은 건지도 모르겠군요.

사실 이 부분에 대한 글은 외국 사이트들에 많이 소개 되어 있다.
그러나, 정작 사용하려 하면 헷갈리게 구성되어 있어 이기회에 정리하도록 한다.

이전에 사용해 왔고 계속 진행해온 방법이 아래와 같은 방법이다.

<a href="javascript:" onclick="IMNImageOnClick();return false;" class="ms-imnlink">

<img title="" alt="No presence information" name="imnmark" border="0" valign="middle" height="12" width="12" src="/_layouts/images/blank.gif" sip="administrator@trainsbydave.com" id="imn0,type=smtp" >

</a>

즉 저 내용 중 SIP 라는 항목에 실제 OC 에 필요한 SIP를 넣어서 처리하곤 했다.

그런데, 간혹 위와 같이 표기하면 Presence 정보가 제대로 표시되지 않거나(SIP가 잘못된 것 처럼 아예 표시 조차 안되는 경우), 2개 씩 나오는 경우가 있다.

이에 MOSS에서 제공하는 스크립트를 가만히 뜯어 보았다. MOSS에서 제공하는 자바스크립트는 두가지 인데, 하나는 /_layouts/{LCID_CODE}/init.js 고 다른 하나는 /_layouts/{LCID_CODE}/ows.js 이다. ( LCID_CODE란 언어별 코드로 한국어면 1043 일 것이다. )

그 자바스크립트를 가만히 보게 되면 위와 같은 형태의 코로는 도무지 제대로 찾지 못하는 구조일 수 밖에 없다. ( 도리어 표시되는게 무척이나 신기한 구조다. )

예전 WSS v2 에서는 아래와 같이 구성되어 있었다.

<img border="0" height="12" width="12" src="http://portal.blackbladesystems.com/_layouts/images/blank.gif" onload="IMNRC('erosenfeld@blackbladesystems.com')" id="imn0" >

그래서 해당 Img가 Load될때 IMNRC라는 자바스크립트가 실행되면서 동작했는데, WSS v3 부터는 ProcessImn() 이라는 함수를 부르면 알아서 찾아 처리하는 것이다.

아무것도 없는데 알아서 처리할리는 없고, 실제 자바스크립트에서 찾는 방법을 간단하게 서술하면 아래와 같다.

1. name="imnmark" 라는 이름을 가진 element를 모두 검색한다.

2. 검색한 element가 span이라고 가정하고, OC의 active X에 이벤트를 연결한다.

3. 이벤트에서는 active X의 presence가 변경될 때 마다, 해당하는 이미지로 변경할 수 있도록한다. 이 때 이미지 id는 span에서 제공한다.

혹시 이 Presence 정보에 골머리를 싸아보신 분은 헉.... 이라는 한마디를 할 것이다. 저 1,3 번이 바로 OC Presence 정보의 함정인 것이였다.

먼저 아래와 같은 구조가 되어야 한다는 것이다.

<span id="{고유ID-1}" name="imnmark" >
  <img id="{고유ID-1}" src="blank.gif" >
</span>

서두에 전달드렸던 태그와는 전혀 생뚱맞지 않은가?

즉 <a> <img> </a> 형태가 아닌 <span><img></span>이되어야 한다는 것이다.

그런데, 여기서 잠깐!. 저 ID가 무척 웃기는 구조이다. 정말이지 고유 ID가 되어야 정확한 이미지 변경이 가능하다.만일 모든 Presence 정보의 ID를 맨 위의 코드 처럼 id="imn0,type=smtp"  라고 쓰면 한개의 이미지만 그럴싸하게 나오고 나머지에서는 제대로 표시도 안된다.

그렇다면, 저 ID는 어떻게 뽑을까?

물론 한 페이지에 이 Presence 정보를 뽑는 곳이 딱 한개의 웹파트에서 모두 표시된다면 문제가 없다. 그 안에서 int nIndex = 0; 한다음에 뺑뺑이 돌면서 ID를 만들면 된다. id="imn0,type=smtp" , id="imn1,type=smtp", id="imn2,type=smtp", id="imn3,type=smtp"... 이런 식으로 표시만 되면 된다.

그런데.. 만일 멀티 웹파트 인경우에는 어떻게 해야 할까?

사실 이것 때문에 조금 고민했다.  웹 구성요소(웹 컨트롤, 웹 파트 등)에서 모두 공유해서 쓸만한 변수라는게 있을까? 웹 컨트롤 내에 백개의 변수를 정해줘바야 다른 웹 컨트롤이나 웹 파트에서 접근도 못할 뿐더러, 이미 접근할 때에는 그 객체는 Render 하고 끝났을 테니깐...

그러다가, 이렇게 생각을 조금 다르게 바라보자,  웹페이지에서도 나름대로 공용 변수를 하나 세울 수 있었다.

바로 HttpContext.Current.Cache라는 것이였다.

즉 저 안에는 Key 값을 정해준뒤, object 형태의 값을 넣을 수 있는데, 바로 그 점에 착안한 것이다.

즉 Presence 정보를 표시하는 모든 웹 구성요소들은  아래와 같은 캐쉬를 꼭 읽도록 한다.

object val = HttpContext.Current.Cache["PRESENCE_COUNT"];

만일 val이 null 이라면 새로 값을 넣고, 그렇지 않으면 그 값을 사용한다.

presence 정보를 쭉 나열한 뒤, 전체 인덱스가 변했다면, 이젠 그 값을 Set 해준다. 이 때 만료시간은 2~3초로 잡아주면 끝날 것이다.

아래의 코드를 참고하도록 한다.

static public string GetPresenceInfoHtml(string sSipAddress)
{
      string CacheName = CACHE_PRESENCE_COUNT_PREFIX +   UserData.GetCurrentUserId();
       int nCount = 0;
       object val = CacheHelper.GetCache(CacheName);
       if (val != null)
       {
            nCount = (int)val;
            nCount++;
        }

        string sId = "imn" + nCount.ToString() + ",type=smtp";
        StringBuilder sbContent = new StringBuilder();
        sbContent.Append("<span name=\"imnmark\" ShowOfflinePawn=\"true\" id=\"" + sId + "\" sip=\"" + sSipAddress + "\">");
         sbContent.Append("<img border=\"0\" id=\"" + sId + "\" valign=\"middle\" height=\"12\" width=\"12\" src=\"/_layouts/images/blank.gif\" onload=\"IMNRC('" + sSipAddress + "');\" sipaddr=\"" + sSipAddress + "\" />");
         sbContent.Append("</span>");
        CacheHelper.SetCache(CacheName, DateTime.Now.AddSeconds(5), nCount);

         return sbContent.ToString();
}

( 위의 코드 중 CacheHelper.SetCache와 GetCache는 신경 쓰지 않도록 한다. HttpContext.Current.Cache를 쉽게 사용할 수 있도록 구성한 함수 들이다. )

* 주의! : Presence를 표시하는 Html 부분을 AJAX 기법으로 동적으로 추가되도록 구성하지는 말자. <div> 안에 innerHTML 같은 것으로 해당 부분의 Html을 넣거나 빼게 되면 그 안의 값은 getElementById 혹은 getElementByName 등의 함수로 찾지 못하는 경우가 발생한다. 가급적 HTML은 미리 인쇄될 수 있도록 구성해야 한다.

ASP.NET에서 Page객체 내에 있는 IsPostBack과 IsCallBack의 차이를 명확히 몰랐다. 어떨때 Postback을 써야 할지, 어느 때 Callback을 써야 할지...

이제는 조금은 명확해져서 조심스럽게 포스트하도록 하겠다.

먼저 이 차이를 알려면, HTML을 이용한 서버 데이터 전송에 대해서 살펴보아야 할 것 같다.

예전 HTML로 작성된 데이터들은  정적 페이지라고 했다. 그 이유인 즉, 그 HTML 페이지에는 오로지 HTML 태그와 텍스트들로 나열되서 글과 그림 그리고 링크로 구성된 오로지 정보 전달만을 위한 페이지를 제공해 왔다. 그래서 당시 대부분의 홈페이지들은 텍스트와 이미지와 링크 만 있었고, 그나마 동적으로 움직이는 것을 움직이는 GIF나, 자바스크립트를 겨우 이용하는 정도 였다.  즐비했고, 사용자들은 서버에서 제공되는 값들을 이용만했지 절대 서버에 데이터를 주거나 하지 못했다.

그러다가, 이 HTML에 Form 이라는 것이 생겼다. 이 Form 내에 input 이라는 형태로 데이터들을 넣으면 form 내에 있는 각종 데이터들을 서버에 전달 할 수 있게 되었다. 아마 이 개념이 정립되면서 가입 양식 같은 형태로 만들 수 있었고, 이 가입양식 내에 데이터를 채우면 서버에 필요한 데이터를 전달할 수 있었다. 이 때 Form 안에 보면 action 이라는 속성 값으로 Html URL을 넘기게 되어있는데, 이 URL에 해당하는 서버로 데이터를 전송하게 된다. 이 때 부터 생긴 개념이 ghost 페이지라는 것이 생겼다. 이 ghost 페이지는 오로지 client에서 데이터를 받아 처리하는 로직만 담기고 실제로 사용자에게는 보여지지 않는 페이지였다.

이 개념을 ASP.NET에서 Postback이라는 것으로 만들었다. 즉 예전에는 총 3단계의 과정 [입력폼 페이지] -> [Ghost 페이지] -> [결과 페이지] 로 가졌던 것을 [입력폼 페이지] 하나만으로 그 Form 기능을 수행하게 하는 것이다.

ASP.NET에서 제공하는 System.Web.UI.WebControls 라는 네임 스페이스 안에 다양한 컨트롤들 Button, TextBox... 마치 Windows 클라이언트의 WinForm과 같은 컨트롤들을 생성해서 그 동작을 살펴보면 바로 저 Postback 개념으로 동작하는 것이다. 즉 예전 Form의 Post 방식으로 서버에 데이터를 전송하게 되는데, 단지 특정 Ghost 페이지가 아닌 자기 자신으로 다시 부르는 것이고, 이에 관련된 처리를 ASP.NET에서 자동으로 처리하는 것이다. 그래서 실제 프로그래밍 할 때는 Form 의 action이나, input 과 같은 태그 없이도 자동으로 클릭, 텍스트 변경 등의 이벤트에 대응되는 것이다.

그러나.... 이 방법은 큰 문제가 있으니, 바로 화면 Refresh이다. 이건 원래 Form의 Post 방식을 사용한 것이다 보니 Post가 발동 되는 순간 Form에 정의된 action의 페이지를 부르는 작업을 수행하는 것이다. 그 페이지가 다른 페이지던, 자기 자신이든 결국 그 페이지를 다시 부르는 것과 동일하기 때문에, 화면이 깜박이게 되는 것이다.

이 문제점에 대한 대안으로 callback이라는 것을 제공한다.
AJAX가 세상의 또하나의 트랜드가 되었을 때, 이번엔 HTTPRequest 라는 객체를 이용해 javascript로 데이터를 직접 읽어오는 로직을 ASP.NET으로 구현한 것이 바로 callback이라는 개념이다. 이 동작은 Form을 통해 데이터를 전달하는 것이 아니고 javascript가 독자적으로 httprequest 라는 모듈을 이용해 직접 페이지를 부르는 방법이기 때문에, 화면이 깜빡대지 않는다.

정리를 하자면, Postback은 옛날 개념, Callback은 근좌 유행한 AJAX 기반의 개념이라는 것. 그래서 일반적인 웹 컨트롤은 바로 Postback으로 체크하시면 되고, Callback은 ICallbackEvent 라는 인터페이스를 상속 받은 Page 객체 혹은 컨트롤에서 체크하면 된다.