'전체 글'에 해당되는 글 1243건

UML로 Use Case나 Class Diagram 조금 깔짝거리던 실력이라,

다음 코드를 참고하세요…

long nQuata = long.Parse("500");   // 용량은 1byte로 계산 1K는 1024, 1M는 1024*1024 nQuata = nQuata * 1024L * 1024L;               SPSite site = new SPSite("http://www.knoie.com/sites/1");     Microsoft.SharePoint.Administration.SPSiteAdministration admin = new Microsoft.SharePoint.Administration.SPSiteAdministration(site.ID);   Microsoft.SharePoint.Administration.SPQuota quota = new Microsoft.SharePoint.Administration.SPQuota();             // 저장 용량(0L은 제한없음) quota.StorageMaximumLevel = nQuata; // 경고 용량(0L은 제한없음) quota.StorageWarningLevel = 0L; // 최대 사용자 수(0은 제한 없음) quota.InvitedUserMaximumLevel = 0;               admin.Quota = quota; admin.Dispose();

 

이 코드의 핵은 SPSiteAdministration 인데 이 안에서 SPSite를 관리자 모드로 설정하여 SPSite 설정을 다양하게

해줄 수 있습니다. 이 때, 내부적으로 다음과 같은 코드로 현재 사용자가 권한이 있는지 체크합니다.

if (this.m_Site.WebApplication.Farm.CurrentUserIsAdministrator()) {             this.m_Site.AdministratorOperationMode = true; }

 

즉 위의 코드는 관리자 권한으로 실행되는 페이지 안에서만 실행됩니다.

 

냉큼 냉큼 보이는 즉시 삭제 중인데,
요즘 이 스패머가 거의 테러식으로 올리는 군요.

( 필명을 유사하게 쓰는 거 보면 분명 동일 인물인듯 싶습니다. asdf 를 차단하니깐,
미묘하게 바꾸더군요 )

블로그의 특징상, 로그인 따위는 하지 않아도 언제든 댓글을 써서 서로의 의견을 나누는 것이 중요하기
때문에, 익명으로 하긴 했는데, 이거야 원, 그 틈을 노려 스팸 댓글을 쏘다니..
일단, 이 스패머가 사용한 IP를 중심으로 차단하기는 하는데, 게임방을 넘나 들면서
올리는 것 같군요.

스패머의 처벌법좀 바꾸죠.... 최진실 법 따위를 만들기 보다, 이런 법이나 정비했으면 좋겠습니다.
스패머 자체의 처벌도 중요하지만, 스패머 보다, 그 광고 글을 발주한 광고 주를 처벌했으면 좋겠습니다.
거 그냥 시늉으로 하지 말고, 광고주에게 벌금 1500만원 이렇게 때리시죠.
스패머도 벌금 800 정도 하시고, 해외에 있다고 하면 할 수 없지만, 분명 광고주도 무슨 선이 있으니
그렇게 광고를 한 것이니, 광고주를 달달 볶아서 그 스패머 연줄을 후두둑 뽑아 버리죠 좀.

경고? 1회면 족합니다... 광고주는 1회는 봐줘도 2회 부터는 얄짤 없이 거두고, 3회 부터는 1500 의 제곱을 받는 거죠. 그러면 거 조용해질 것 같습니다.

그러나... 명박이는 IT 죽이기에 여념이 없으시니 이런 요청은 씨알도 안 먹힐 것 같네요.
삽질로 시작한 인생 삽질로 마무리 지을라고 하는데, 시대의 흐름은 봐가면서 좀 했으면 좋겠네요...
4년.....
탄핵 안하나? 하면 즉시 찍으러 갈텐데....

사실, 나 스스로 대화 하는 스킬 분석 도중, 내 대화 내용도 들리는 사람에 따라서
은근히 빈정상하게 들릴만 하게 말하곤 한다.
은근히 삐딱선을 탄데다, 약간 줏대 없이 말하기도 하고, 지나치게 가볍게 이야기하는 버릇이 있는 것 같다.

그런데 그런 모습을 나 뿐만 아니라, 다른이들에게서 느껴지기도 한다.
내가 쓸데 없이 민감하게 생각하고 멋대로 의미를 부여하는 것 같기도 하다.
실제로 특별한 의도를 가지고 그런 식으로 표현 한 것이 아닌데, 그렇게 되버린 모습.

일 예로, 상인 스킬과 같은 대화술이 적용된 예다.
특히 물건을 팔려고 하는데, 은근히 대화 중에 그 물건의 가치가 없고, 문제 있으며,자신에게는
필요 없다는 사실을 은근히 어필한다. 그래서 가격을 하락 시킨다.
사실 이런 형태가 되는 경우 나는 보통 GG 하고 물건 팔기를 포기한다.
(모 아니면 도의 행각이기 때문에, 네고시에이션 이라는게 있을 수 없다. )

예전에도 한번 이런 비슷한 상황에 있어, 물건을 주거나 팔기보다 전부 버린 적이 있다.
버리는 순간 조금 후회하기는 했지만, 지금은 말끔하다. 도리어 그 따위 물건에 얽매여
내가 기는 것 같은 순간을 가진 것이 더 많으 후회를 가져올 수 있을 법도 하기 때문이다.

난 최소한 나와 시점을 같이 하는 사람에게는 No Take, All Give에 가까운 지원을 한다.
그런데, 상대가 나의 마음은 무신한재, 상인들 처럼
그 안에서 골라내고 가격 협상을 하려는 모습은 나의 마음을 무척 아프게 한다.

내가 그들에게 팔아서 이익볼 바에는 그냥 다른데서 일해서 돈벌고, 팔려는 물건 다 버린다.
그게 내 생활 방식이다.

- 물론 나와 최소한 시점을 같이하는 사람이나 그런 혜택이 있지, 그렇지 않으면 일절 없다.
   Give & Take 뿐이다.

내가 가지고 있는 인맥 네트워크가 무척 넓은 편은 아니기 때문에, 사실 정확도가 있지는 않다.
(즉 논문이나 특정 갤럽의 분석 보다 신뢰도는 낮다.)
오로지 내 눈으로 보고, 피부로 느낀 그대로를 내 생각대로 말하는 것이다.


현재 내가 70년대 생(76년)이기 때문에 먼 과거의 분들 (40, 50년대 생) 나 아직 고등학생들인 어린 친구들(90년대 생 이후)까지는 명확히 알 수 없다. 가끔 후배의 동생이나 후배의 후배를 통해 보긴 하지만, 솔직히 그 친구들과 자세한 이야기를 나눌수 없는게 사실이기에 정확도는 당연히 떨어진다. 게다가 어르신들은 세상의 변화가 단 20년 동안 순식간에 바뀌어 완전히 18세기사람과 20세기 사람 차이처럼 그 골이 조금 깊다.(전후 세대 분들이다 보니, 생각 자체의 시점이 틀리다.)

그래서 내 앞세대 뒷세대인 60년대 생과 80년대 생을 기준으로 말하고 싶다.


1. 버르장머리.
예절(禮節)에 대한 문제라고 볼 수 있다.
점점 시간이 흐르면서 이 예절적인 문제는 많이 대두 되었다. 사실 60년대 생 분들이 70년대 생을 바라 보는 눈이 그렇게 곱지만은 않다. 무언가 탐탁잖은 그런 모습. 분명 무언가 챙겨주는 것 같은데, 약간 버르장 머리 없는 모습. 과거 자신은 전후 세대들에게 깍득히 선/후배의 모습을 갖추었고, 상사가 이러라 하면 이러고 저러라 하면 저랬는데, 70년대생들은 무언가 삐닥허니 잘 안한다. 그렇다고 완전히 안하는 건 아니고 미묘하게 안한다는 것이다. 이제 70년대 생을 바라보자. 70년대 생이 바라보는 80년대 생은 60년대 생이 70년대 생을 바라보는 것과 별반 차이 없다. 최소한 지킬 선은 지켜줬으면 하지만, 80년대 생이 다 그렇지는 않지만 대개 이 선을 뭉개는 경우가 많다. 물론 첫대면은 깍듯하다. 사실 이 깍듯함은 경계의 의미가 강한 것일 뿐이고, 60년대생 대부분, 70년대생 일부분이 갖춘 선/후배 챙기기의 모습이 아니다. 서서히 이 경계점이 무너지기 시작하면, 어느새 서서히 말이 짧아 지며, 인사도 대충한다. 양키 식으로 손을 드는 친구도 있다.

60년대 생이 70년대 생을 바라보며 참 버리장 머리 없네...라는 말 그대로 70년대 생이 80년대 생을 바라보며 참 버르장 머리 없네... 라고 말하는 것과  별반 차이 없다.  세상이 변해 가면서 그 허용 경계가 점점 낮아지면서 바로 윗세대는 바로 아랫 세대에게 한소리를 하는 것과 별반 차이 없는 것 같다.

2. 일에 대한 자세.
일을 어떻게 생각하는지 한번 나름대로 나누어 생각해보았다.
먼저 60년대 생들.
대부분 60년대 생들은 일 = 삶 이였다. 사실 전(戰)후 세대 분들은 일 = 생존 이였다. 그에 반해 업그레이드 된 모습이지 않을까 생각된다. 하지만, 60년대 생 분들 중에 인텔리는 그리 많지 않은 것으로 알고 있다. 당장 먹고 살기 힘들기에 학교를 다니기 보다 돈을 벌 수 있는 일자리를 찾기가 바쁘셨기에 어쩔 수 없는 선택이였으리라 상상한다.
그러기에 그 분들은 생존이면서도 인생을 살아가는 터전과 같은게 바로 일이라 할 수 있을 것이다.
이에 반해 70년대 생들은 어느정도 경제적인 안정을 갖추고 일 = 삶이라고 살아오신 분들과는 다른 생각을 갖게 된 것 같다. 즉 즐기며 일을 한다는 것이 어떻게 보면 최고의 일자리라는 생각을 대부분 갖고 있었던 것 같다. (최소한 제 주변에는 이런 분들 많죠 ) 대기업에 들어가거나 공무원이 되거나 라기 보다는 자신이 좋아하는 일을 선택하여 그 일에 최선을 다하는 모습. 이것이 미덕이라고 생각하는 것 같다. 그러기에 더욱더 자신이 하는 일에 대한 후회를 하는 경우도 많다. ( 임금, 근로환경 등등 ) 그래도 대부분은 자신이 택한 길이라는 생각, 이나 최소한 제대로 일은 해야지 욕은 안먹는다는 생각? 등등 여러가지 원인들로 책임감을 가지고 자신의 일을 수행한다. 물론 말로는 일이라 함은 적당히 하고 가정생활을 중시해야 한다고는 늘 말한다. (마치 운동해야 되는데..... 와 비슷하게, 은근히 야근들을 하고 잔업들을 하곤 한다..)
이에 반해 80년대 생은 일과 삶은 명백하게 분리되어 있다. 즉 70년대 생이 말로만 하는 일과 생활의 분리는 몸소 실천하는 모습이다. 즉 정해진 일을 똑부러지게 한 뒤, 그 일에 대한 수당으로 잘 사는 것이 최고의 미덕이라고 생각한다. 절대 일을 야근을 통해서 해결하거나, 잔업으로 하는 것을 최악의 상황으로 생각한다. 그래서 면접을 하다 보면 80년대 생은 근로 환경이나 임금에 대해서 많이 묻는다. 열악이라고 판단되면, 그 일이 어떤일이든 일단 회피하고 본다. ( 물론 떡밥이 좋으면 - 20세기 말에서 21세기 초에 유행한 스톡옵션 등등 - 잘 물리긴 한다. )

그래서 잔업이나 야근 횟수등을 보면 60년대 생 > 70년대 생 > 80년대 생 순으로 보이곤 한다.
( 만나자 할때 만나기 힘든 순서이기도 하다. )

3. 지식을 향한 모습
아마도 삶이자 생존이라고 생각을 해오던 60년대 생에게는 지식이란 훌륭한 무기이며 동경 그 자체라고 생각된다. 환경이 열악하니 공부를 하고 싶어도 하기 힘들기 때문에, 더욱더 그 생각에 불타 올라 심지어 자신의 자식만이라도 공부 열심히 할 수 있는 환경을 만들기 위해 희생 그 자체를 보여주었다. 엄청난 학구열이라 생각된다.
그에 반해 70년대 생은 지나친 경쟁 속에서 지식에 대한 열망이 한풀 꺾인 모습이다. 너무 많은 지식들을 쏟아 붇고 그를 테스트 하기 위한 시험들을 보다 보니, 지식은 지식이고 삶은 삶이지.. 라는 생각을 갖는 경우가 많다. 학부모 경쟁열이 붙은 경우에는 자식에 대한 학구열 불태우기에 여념없긴 하지만, 대개는 학습에 대한 방만 주의가 조금씩 흐른다. 너무 지나치게 키우고 싶지 않다는 생각이 팽배하다 ( 하지만 자신의 자식에 대한 애정이 학구열로 불타는 경우가 많다 ). 80년대 생은 아예 지식은 도구 및 발판에 불과하다고 생각한다. 즉 특정 조건을 갖추기 위한 자격 요건 이나 돈 벌기 위한 단순한 수단에 불과하다고 생각한다. 그래서 사실 지식 자체에 대하여 열망은 없다. 단지 일하는데 지장이 있는 경우 일시적인 열혈모드로 들어가곤 하지만 아주 일시적인 현상이다. 게다가 자신과 전혀 관계 없거나, 조금이라도 지루하다고 판단 되면 가차없다. 그냥 졸아 버린다. 상대방에 대한 예의나 배려는 없이 자기 중심적으로 생각하는 경우가 많다. 아마도 정보 홍수속에서 살아 남는 방법을 몸소 체득하여 본능적으로 나오는 현상이라 생각된다. ( 최소한 70년대 생까지는 정보란 하나라도 쥐어야 살아남는 다는 생각이 강했다 )

4. 세대별 차이를 통한 내 나름 대로의 결론.
사실 세대별 차이는 시대 트랜드에 의해 변화되는 것을 막을 수 없다. 게다가, 자신이 무리에서 왕따, 혹은 아웃 사이드가 아니라면 이 변화에 꼭 휩쓸리게 된다. 그래서 80년대 생인데, 야근을 하는 경우 주위 친구들이 그 사람을 동정하거나 바보, 병신 취급한다. 그러기에 더더욱 세대 차이를 명확하게 보여준다.
그런데 만족스러운 삶은 사는 사람들의 형태는 무리에 대해 크게 개이치 않고 My way를 밟으며 나아가는 사람들이라는 점이다. 그리고 전 세대의 모습과 현재 자신의 또래의 트랜드의 줄타기를 잘하는 것이라 할 수 있다.(최소한 2세대 이상을 뛰어넘게 되면, 완전 막나가는 사람이 되거나, 고지식한 사람으로 치부되기 싶다.)


PS.
마지막으로 지금 80년대생 분들에게 두가지 말씀을 전해 드리고 싶군요.

이 글에 대해서 전혀 동의할 수 없으며, 그에 대한 반박문을 A4 100페이지라도 쓸 수 있습니다.... 라고 말씀하실 분들도 있겠지만 이 글은 오로지 저의 지인들과 제 나름대로의 인맥 네트워크를 통해 이러저런 이야기를 한 결론입니다. 게다가, 제가 아는 60년대생, 70년대 생, 80년 대 생 분들 중 저 세대별 차이를 뛰어넘는 분들도 여럿 알고 있습니다. 하지만, 그런 다양한 예외들을 모두 품고 설명하기에는 복잡하기 때문에, 어느정도 걷어내고 말씀을 드린거죠. 하지만, 세대 트랜드는 저 모습이라고 생각됩니다.  지금의 모습을 잠시 기억에만 담으시고, 한번 딱 10년 후에,  당신이 관리직에 올라 90년대생 00년대생 분들과 함께 일을 해보시기 바랍니다.아마 저와는 다른 트랜드의 모습을 90년대생 00년생 분들을 통해 자신의 모습을 바라볼 수 있을 것입니다.
(물론 그전에 이 글에 대해서는 완전히 잊혀지겠지만요.)


그리고, 옛날 말 중에 이런 말이 있습니다.
  
    知之者不如好之者 好之者不如樂之者
    아는 자는 좋아하는 자보다 못하고, 좋아하는 자는 즐기는 자보다 못하다.

당신이 학습을 하는 중이든, 일을 하는 중이든,
그저 열심히 하기 보다, 그저 좋아하기 보다, 그를 즐기는 마음을 갖고 임해주시면 좋겠습니다.
분명 즐기는 자와 함께 일을 하면 같이 즐겁게 모든 것을 할 수 있다고 생각됩니다.
(분명 그냥 하는 사람보다, 좋아하는 사람보다 즐기는 사람이 심리적으로 안정되고 여유가 있기도 합니다.)
어느새 즐겁게 모든 것을 하고 있는 자신을 볼 수 있을 것 같습니다.
( 전 아직도 "좋아하는"  레렐인 것 같군요 )

MOSS 2007에서 아래와 같은 형태로 구성 시 위의 이벤트 로그가 계속 쌓이게 된다.

1. Root 사이트가 게시 사이트 형태인 경우 ( 공동 작업 포탈이든, 게시 사이트 든..)
2. Root 사이트에 하위 Application으로 사이트를 추가하여 구성한 경우.
   ( 보통 가상 디렉터리 만들 때, 기능 옵션에 실행을 체크하여 넣으면 "기어" 표시가 생기면서
     하위 응용 프로그램으로 구성되는 경우 )

보낸 사람 ForBlog2

위와 같은 형태에 있을 때 가상 디렉터리 이하의 특정 리소스(JS 파일이든, ASPX 파일이든)에 접근하다가, 아래와 같은 이벤트로그를 뿜어댄다.

Event Type:    Error
Event Source:    Office SharePoint Server
Event Category:    게시 캐시
Event ID:    5785
Date:        2009-02-25
Time:        오전 10:57:07
User:        N/A
Computer:    KYOKO
Description:
출력 캐싱에 대한 게시 사용자 지정 문자열 처리기에 연결할 수 없습니다. IIS 인스턴스 ID는 '1986061912'이고 URL은 'http://www.knoie.com/virtualdir1/Images/presence/presence_off.gif'입니다.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

위의 내용을 이곳 저곳을 기웃 거리다가 한 Technet 의 토론 내용 중 하나의 쓰레드에 눈이 가서 훝어 본 결과 단 한줄로 해결 되었다.

해당 가상 디렉터리는 자체적인 응용 프로그램 쓰레드를 갖기 때문에, 보통 web.config를 별도로 구성하는 경우가 많다. 만일 없다면 기본 web.config를 만들어서 구성하신 뒤, module 부분에 추가하면 된다.

<httpModules>
      <remove name="PublishingHttpModule" />
       <add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
            <!--<remove name="ApplicationMasterPage" />-->
</httpModules>

web.config 에서 httpModules로 찾아서 해당하는 섹션이 보이면 굵게 보이는 저 한 줄을 넣어주면 된다.
나머지는 그대로 두면 된다. 만일 httpModules라는 섹션이 없다면, System.web 섹션을 찾아서 그 안에 다음과 같이 추가하면 된다.

<system.web>
     <httpModules>
          <remove name="PublishingHttpModule" />     
     </httpModules>
 .......
<system.web>

요는  PublishingHttpModule 이라는 Module을 없애면 된다.

프로그램 개발이 주업종이다 보니, 매일 컴퓨터를 다루며 다양한 정보들을 수집하고, 정리하며,
개발하고, 테스트팅 하는 일련의 작업을 하고 있다.
IE, FireFox 등을 띄워 개발된 화면을 체크하고, Word와 Excel을 띄워
작업 내용을 정리하고 보고 하며, Outlook으로 메일을 확인하고,
각종 참고 사이트들을 이리저리 뒤지다가 보면, 작업 줄에는 빽빽하게 윈도우들로 가득차 있다.
어느새 ALT-TAB을 하염없이 누르고 있는 자신을 바라보게 된다.

지금 가지고 있는 노트북은 후지쯔의 T2010이다.
이 노트북은 콤포터블 타블렛 노트북이다 보니, 휴대성을 강조해서, 화면도 그다지 크지 않다.
12인치 와이드 형으로 최대 해상도는 1280 * 800. 한개의 화면 꽉채워 보다 보면 슬슬 화가 나기 시작한다.
마우스 조금 움직이고 ALT-TAB 또 조금 입력하고 ALT-TAB. 같이 띄워놓고 보면 얼마나 좋으련만...

그래서 듀얼모니터를 상당히 선호 한다.
쉽게 마련되지는 않지만, 간혹 여유 모니터가 생기면 잽사게 하나 챙겨 틀어보곤 한다.
그럴때 마다 얼마나 행복했는지......

그러나, 그것도 잠깐.... 사실 노트북의 화면은 DVI 형태로 한개의 도트에 한개의 Pixel씩 출력되기 때문에,
무척 깔끔한 글자의 모양을 보여준다. 그런데, 노트북과 연결된 모니터는 RGB. 아날로그 방식이다 보니,
어딘가 모르게 노트북의 화면과는 다르게 조금 뿌옇게 보인다. 약간 번졌다고 할까....
모니터 제작업체라도 좋은데서 만들었으면 그나마 잘 나오지만, 이상한 업체에서 만든 모니터인 경우에는
CRT 보다 못한 화질을 보여주곤 한다.

애석하게도 노트북에서 출력되는 I/F는 RGB 뿐..... 조금더 늦게 구매를 했더라면,
HDMI 포트라도 있을텐데.. 애석하게도 장비되어 있지 않다. 어설프게 틀릭 두개의 화면을 번갈아 보거나
혹은 좁은 화면에 만족하며 작업을 해야 했다.

그러다, 우연찬게 Lapfit이라는 광고를 보게 되었고, I/F가 USB라는 점에 은근히 끌리기 시작했다.
과연.... 나에게 어떤 새로운 모습을 보여줄지.... 기대된다.

이번 프로젝트에서 최초로 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 구성하는 방법이라 생각된다.