'기술자료'에 해당되는 글 351건

이번 프로젝트에서 최초로 Front End 웹페이지 부분을 프로그래밍 하다 보니, 내 나름대로 CSS에 대한 개념을 다시 쌓게 되었다. 이에 대해서 정리하도록 한다.

예전에는 CSS의 역할에 대해서 크게 생각해본적이 없었다. 대부분은 Front End 웹페이지에 대한 수정이나 편집 보다는 대부분 Back 단 서비스 계열의 구성이 대부분이였기 때문이다. 또한 디자이너가 임의로 수정 또는 구성한 CSS를 그대로 가져다 쓰고, 일부 프로그램으로 구성 중에 변경될 필요가 있는 경우, Internet Explorer Toolbar를 이용하여 특정 CSS를 찾아 해당 되는 값을 변경하는게 전부였다.

그런데, 금번 프로젝트에서 JQuery를 하면서 내 자체적으로 필요한 CSS 들을 정의하고, 구성하다 보니, 디자이너들이 구성했던 내용과는 다른 구성이되어버렸다.

현재 디자이너들이 정의한 CSS들의 유형을 보면 다음과 같다.

1. HTML Element 별로 구성.
   <td> 혹은 <span>, <input> 등 특정 엘리멘트에 대해 디자인적인 적용 작업.

2. 필요한 값에 따라 구성.
   padding-left가 5 가 필요하면 gg_pl_5p 라는 이름으로,
   text가 bold로 표시되는 부분이 있으면, gg_txt_bold 라는 이름으로 정의된 방법.

각 HTML을 보면, 일단 전반적인 구성 내용은 1번의 유형대로 HTML Element에 전반적인 설정을 시도했다. 그래서 모든 페이지 해당 Element들은 기본적으로 동작하게 했다. 그리고 난 뒤, 세세한 변경 작업은 해당 부분의 class=" " 안에 특정한 상태 값에 따라 필요한 값에 해당하는 클래스들을 추가하는 방식이였다.

만일 padding-top 이 10px이고, padding-left와 right가 5px이고, 이텔릭 체라면....

class="gg_pt_10p gg_pl_5p gg_pr_5p txt_italy"

처럼 구현되어 구성되어 있는 것이다.

물론 HTML 코딩된 내역을 요청하면 필요한 사항에 맞게 구성되어 있으므로 디자이너가 원하는 대로 나오게 된다.

그런데, 이렇게 구성되면 특정 구성요소에 대한 수정이 필요한 경우, 해당 구성요소의 class들을 따라 들어가 수정하게 된다. 즉 HTML 코드가 되었든, .NET의 C# cs 코드가 되었든, PHP z코드가 되었던, 해당 코드의 class 부분을 수정하고 다시 배포를 해야 한다.

이것을 만일에 역할별로 Css를 정의하게 되면 어떨까?

현재 필자가 하는 작업이 WSS의 SharePoint이므로, WSS를 기준으로 예를 들어보겠다.

SharePoint도 결국은 WebPage를 표시하는 것이므로 WebPage 가 있을 것이다.
그리고, 그 WebPage 내에 특별한 경우가 아니라면 WebPart와 WebControl들이 있다. 그리고 그 WebPart와 WebControl을 각기 기능에 따라 다르게 구현되곤 한다.

이렇게 프로그램이 구성된 것과 동일한 구조를 가진 CSS를 가지게 되면 어떨까하는 것이다.

먼저 WebPage 라는 class를 구성한다. 그 class에서는 전반적인 페이지 자체의 css를 정의한다. 배경색이나, 기본 폰트라든가....

그리고 WebControl 에서는 WebControl이라는 class를 구성한다. 이 class에서는 기본적으로 WebControl들이 갖는 기본 형태에서 필요한 구성요소들을 정의한다. 모든 WebControl들은 이런 배경색을 가지고, Line-height 등을 결정한다. 그리고 그 WebControl로 만들어지는 특정 WebControl (예를 들면 달력 같은)이라면, 다시 NewCalendar 라는 class를 구성한다. 이 class는 WebControl의 내용을 그대로 상속 받고 단지 그 안에서 다시 overriding 해서 재 구성하게 되는 것이다.

WebPart도 마찬가지다.

즉 css를 스타일을 묶는 단순한 도구로 생각하여 구성하는 것이 아니라, 화면에 대한 전반적인 동선이나, 구성에 따라 class를 묶어 재구성하는 것이다. 이렇게 되면, 나중에 디자인적인 변경이 필요할 때, 특정 구성요소를 html 소스 상에서 편집하는 것이 아니라, css 내의 특정 값만 변경 만으로 디자인 자체를 변경할 수 있는 첫걸음이 될 수 있는 것이다.

이 개념이 나만의 특별한 생각이 아닌 현재 외국계 디자이너들의 CSS 구성하는 방법이라 생각된다.

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 들고 다양한 사이트에 가다보면, 마스터를 심각하게 뜯어버려, "사이트 작업" 이라는 버튼이 없어졌을 때 발생하는 문제가 종종 있다.

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

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

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

javascript:MSOLayout_ChangeLayoutMode(false)

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

아주 간단한 팁.

보통 우리가 SQL 형식으로 데이터를 조회할 때 SELECT를 사용한다. 이 중 특정 조건에 해당하는 값을 가져올때 다양한 방식으로 표현하게 되는데, 만일 아래와 같이 작성했다고 하자.

SELECT * FROM splist WHERE id>10

저렇게 되면 splist 안의 데이터 중 id가 10보다 큰 모든 값을 들고 온다. 아마도 이 바닥(IT, 프로그래머들이 가득찬....)에서 위와 같이 코드를 짜게 되면 별거 아니면 상관 없지만, ERP 같은 대규모 DB 로 구성된 솔루션을 사용 중이라면 욕 진탕 얻어 먹을 것이다.
특별한 경우가 아닌 경우 보통 아래와 같은 스타일로 SELECT를 하라고 할 것이다.

SELECT [id],[name],[address] FROM splist WHERE id>10

그러면 최소한 id는 10 이상인 것 중에 id, name, address 만 해당하는 값만 쭉 가져오게 된다.

자... 그럼 이제 SPList에서 SPQuery를 이용할 때를 살펴보자.

보통 SPQeury라는 객체를 사용하는 것은 SPList 내에 특정 데이터를 가져올 때 사용하기 위한 부분이다. 그래서 그 SPQuery안에 있는 Query라는 속성 값 내에 <WHERE></WHERE>  라는 형식의 검색 조건을 넣어 처리하곤 한다.

만일 아래와 같이 코드를 짰다면... 어떻게 될까?

SPList list = web.GetList("/Lists/PresidenSchedule1");

SPQuery query = new SPQuery();
query.Query = "<Where><DateRangesOverlap><FieldRef Name=\"EventDate\" />
<FieldRef Name=\"EndDate\" /><FieldRef Name=\"RecurrenceID\" />
<Value Type=\"DateTime\"><Now  /></Value>
</DateRangesOverlap>
</Where><OrderBy>
<FieldRef Name=\"EventDate\" /></OrderBy>";
query.CalendarDate = new DateTime(DateTime.Today.Year, DateTime.Today.Month, DateTime.Today.Day);
query.RowLimit = 10;
query.RecurrenceOrderBy = true;
query.ExpandRecurrence = true;

 SPListItemCollection items = list.GetItems(query);


저 코드가 바로 SELECT * FROM ~ WHERE ~ 스타일인 코드이다.
그렇다면 이 SPQuery에서는 어떻게 특정 Field만 가져오게 할까?

방법은 간단하다. SPQuery의 ViewFields를 설정하면 된다.
StringBuilder sbFields = new StringBuilder();
sbFields.Append("<FieldRef Name=\"EventDate\" />");
sbFields.Append("<FieldRef Name=\"EndDate\" />");
sbFields.Append("<FieldRef Name=\"ID\" />");
sbFields.Append("<FieldRef Name=\"Title\" />");
sbFields.Append("<FieldRef Name=\"RecurrenceID\"  />");
sbFields.Append("<FieldRef Name=\"fAllDayEvent\" />");
sbFields.Append("<FieldRef Name=\"fRecurrence\" />");
query.ViewFields = sbFields.ToString();

즉 GetItems 를 실행하기 전에 SPQuery 안에 저렇게 ViewField들을 정의해주면 간단하게 끝난다.

물론 자체적으로  Sharepoint가 Cache로 가지고 있어서, 어느정도는 후후 되지만, 그래도 깔삼하게 필요한 것만 가져오는게 좋지 않을까?

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

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

<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 객체 혹은 컨트롤에서 체크하면 된다.

관리도구 패널을 만들어야되는 시점. 우연히 켜 놓은 메신저를 통해 대구 동생(민수)이 넌즈시 건네준 말. "형 JQuery 알아요?".  예전에 문득 자바스크립트를 이용해서 XHTML에서 객체 Query 하는 기술인 줄 알고 답했더니, 피식 웃으며(물론 소리도, 모습도 보이지 않았지만, 그런 느낌?) JQuery 기술 관련 각종 URL과 문서를 건네주더군요.
자신이 만든 사이트와 함께 JQuery를 소개 시켜준 뒤 유유히 사라졌고(1년이나 지났는데 여전히 깨 쏟아져서 깨 볶아 먹는지 원....) 전 이 새로운 도구를 바라 보며, 먼 산 바라기를 했죠. 뭘 제대로 알아야지....

다행히 API 설명된 사이트를 알려줘서, 그 사이트에 적힌 내용을 하나씩 하나씩 보기 시작했습니다.(아.. 일어로 되어 있습니다 -_-;;) 그러나 역시 똥 한바가지 찬 제 머리로는 단빡에 이해되지 않았고, 다시 삽질 모드를 발동 했죠. 일단 지금 하던 작업과 연관 지어 Javascript 도배가 예상되는 그 페이지에 하나씩 하나씩 적용해 보기 시작했습니다..

왠걸.... 그 예전 Javascript 코드가 1/3 수준으로 줄고, 그 조작도 무척이나 편해져 버리더군요. 게다가 기능은 더욱더 풍부해진.....

이제 지금까제 제가 이해한 부분을 기반으로 이 JQuery를 소개하도록 하겠습니다.  단 Javascript로 자신이 직접 무언가를 짜기 보다는 네이년이나 다움을 통해 단순 Copy & Paste 수준에 머물고 있다면, 굳이 이 JQuery 세계를 이해하려 하는 만용은 조금 자제해 주세요.. 지금 부터 할 내용은 getElementById 라는 함수를 남발하고, AJAX를 좀 하면서, HTML 엘리멘트들을 이리 저리 옮기고 있는 분에게 새로운 도구를 GET 하시는 계기 정도의 글이 될 것 같군요. ( 물론 Javascript 전혀 몰라도, 그냥 읽어보는 것도 뭐 상관은 없지만 시간 낭비지 않을까 싶네요 (笑))

먼저 JQuery를 소개하기 앞서, JQuery가 가진 몇가지 장점들 중.... 제가 감동 먹은 베스트 2를 먼저 말씀드리겠습니다. 뭐 API나 각종 기능들의 소개는 다른 블로그들을 통해서 얻으실 수 있으니깐요. ㅋ

첫번째. null 걱정이 없다!

뭐 걍 직관적으로 javascript 짜시는 분들이야... 원래 신경 안썼다고 하시겠지만, 저 같이 결벽증이 있고, 뭐든 의심하고 보는 사람에게는 엄청난 스트레스 입니다.

예를 한번 들어보죠...

var linkbutton = doucment.getElementById("forNextPage");
linkbutton.style.display = "none";

라는 코드가 있을때... 과연 저 linkbutton 가 null 일까요? 아닐까요? 당연히 있으면 null은 아니겠지만, 만일에 저 "forNextPage" 부분이 변수로 처리되서 값을 만들어서 넣는다면? 과연 항상 null 이 아니라고 장담할 수 있을까요? 만일 null 이기만 하면, 바로 자바스크립트 오류 팍 뿜죠... 그게 걱정 된다고 밑에 if (linkbutton != null )을 넣기 시작하면 점점 코드가 점점 가관의 길을 걷게 됩니다.

자... 이걸 JQuery로 한다면....

$("#forNextPage").css("display", "none");

네.. 이 한줄입니다.  $("#forNextPage")가 null인지 아닌지 어떻게 아냐구요? 절대 null일리 없습니다. 단지, $("#forNextPage") 안에 객체가 있을까 없을까 정도이지, $("#forNextPage") 자체는 null 이 아닙니다. 만일 $("#forNextPage")로 JQuery 객체가 없다고 하면, 그냥 안이 비어 있는 JQuery 객체일 뿐입니다.  그래서 .css(.....) 부분은 실행되지 않고 끝나게 되겠죠. 믿어지지 않는다구요? 뭐 일단 제가 말씀드린 3가지 장점 설명 후에 JQuery 객체에 대해 제가 이해한 내용을 언급드리죠.

두번째, 다중 선택을 한줄로!!!

만일 <div> 라는 객체를 남발한다고 하죠. 그런데 그 div를 일괄적으로 색을 변경해야 된다고 할때... 어떻게 하시나요? 물론 다양한 방법이 있지만, 저 같은 경우에는 각 div 에 id를 할당 한뒤, 그 id를 기반으로 작업을 수행합니다.

예를 들어보죠....

<div id="parent001">
    <div id="display1"> 보여줍니다.</div>
    <div id="Rdisplay1" >이건 빨간색입니다.</div>
    <div id="display2"> 보여줍니다.</div>
    <div id="Rdisplay2" > 이건 빨간색입니다.</</div>
    <div id="display3"> 보여줍니다.</div>
    <div id="Rdisplay3" > 이건 빨간색입니다.</div>
    <div id="display4"> 보여줍니다.</div>
    <div id="Rdisplay4" >이건 빨간색입니다.</div>
    <div id="display5"> 보여줍니다.</div>
    <div id="Rdisplay5" > 이건 빨간색입니다.</div>
</div>

자 위와 같은 html이 있다고 하죠. 자 XHTML의 특징이 바로 저 id라는 항목인데, id는 전체 XHTML 내에서 고유하게 할당해 주어야 합니다. 뭐 저렇게 규칙적인 것은 Server-side-script 인, PHP나 ASP 또는 ASP.NET 으로 만들면 뭐 껌입니다. (껌이 쉬운지는 잘 모르겠지만요..)

자 위의 내용을 자바스크립트를 통해 "보여줍니다" 항목에 style을 모두 파란색으로 변경한다고 하죠.

예전 제가 했던 방식에 의거하면.. 이렇게 만들어지겠죠?

for(i=1; i<6;i++)  {
      document.getElementByIdl("display" + i).style.background-color = "Blue";
}

네 위와 같이 짰을 겁니다. 그러나.. 이 결벽증 어디로 갈까요? 다시 저 eval의 결과가 null 인지 아닌지 검사해야 합니다.

for(i=1; i<6;i++) {
      var target = document.getElementById("display" + i);
      if(target != null)
          target.style.background-color = "Blue";
}

3줄 짜리가 벌써 5줄로 거의 2배가 되버렸네요. 그래도 안전하면 뭐든지.. ㄷㄷㄷ

자.. 저것을.. JQuery로 승화시키면?

$("div[id^='display']").css("background-color","Blue");

조금더 다듬는다면,

$("#parent001']").children("div[id^='display']").css("background-color","Blue");

윗 줄은 전체 document에서 div를 모두 검색하되 단, id가 display로 시작하는 것을 검색하는 것이고, 두번째 줄은 parent001을 먼저 찾고, 그 하위에 있는 구성요소 중 div에서 id가 display로 시작하는 것을 찾는 것이죠.

for에 getElementById에 그것이 null인지 아닌지 ... 전혀 없고, 그냥 한줄로 끝납니다.

결론

정말 엄청난 녀석을 낚았다고나 할까요. 동생 덕에 근좌 자바스크립트 점점 간단해 지고 있습니다. ( 물론 동료들에게는 아직 알리지 않은 내용이니, 그 분들이 제 자바스크립트 소스를 보면 암호문 같아 당혹스러워 할 지는 모르겠습니다. -_-;;;;)

일단, 간단하게 제가 느낀 감상문을 먼저 적어보았고, 그 동안 제가 해보면서 느꼈던 각종 테크닉들을 정리해서 올려보도록 하겠습니다.

A 태그(<A>) 라든가, DIV 태그(<DIV>), 또는 SPAN 태그(<SPAN>)을 이용하여 안에 각종 Text를 넣을 수 있다. 그런데, 이 Text에 대한 설명이나 말을 줄여 놓으면 그 원래 크기의 문자열을 표시하고 싶을 때가 있다.

이 때 괜찮은 방법이 바로 툴팁이라는 조그만한 노란 창이 좋다. 이것을 사용하려면, 태그 안에 title 이라는 속성 내에 값을 넣어주면 된다.

다양한 Tag 내에서 속성 값으로 title 이라는 속성 값 내에 툴팁으로 표시하는 방법이다. 현재까지 테스트된 태그로는 <A> <DIV> <SPAN> 이며 이외에도 다양한 태그들 안에서 동작가능할 것 같다.

만일 특정 테이블 안에 Text에서 툴팁이 나오게 하기 위해서는 <span title="툴팁내용">test</span>  또는 <div title="툴팁내용">test</div> 라는 형태로 넣어주면 나오게 된다.

테스트 결과 FF 3.0과 IE 7.0 에서 정상적으로 표시된다.
(FF 2.X에는 어떤지는 잘 모르겠다.)