위키의블로그화프로젝트

1. 현재 Diary의 문제점

2. 해결책 궁리

3. 블로그 흉내내기

3.1. 기본 아이디어

3.2. 구현 계획

3.2.1. 블로그 목차

3.2.2. 새 포스트 쓰기

3.2.3. 개별 포스트 페이지

3.2.4. 블로그 첫화면

3.2.5. 날짜별 블로그 관리

3.2.6. 블로그 관련 매크로

3.2.7. 블로그 전용 RSS

3.2.8. 부가 기능

3.3. 한계점

4. 실제로 사용하기

4.1. 새로 만들기

4.2. 기존 일기장 방식에 덧붙이기

4.3. 기존 일기장도 블로그 방식으로 변환하기

5. 기타

1. 현재 Diary의 문제점

Diary, 조프일기, NyxityMonologue 등은 조프님의 위키의일기장화프로젝트 아이디어를 사용하여 위키위키에서 블로그와 유사하게 날짜 순으로 내용을 표시하고 있다. (Diary는 2005년 3월부터, NyxityMonologue는 2005년 4월 19일부터 이 페이지의 내용대로 수정되었음)

이렇게 일기장을 구성했을 때의 장점은 다음과 같다. (위키의일기장화프로젝트에서 옮김)

• 쓰기 편하고 수정하기 편하다.
• 답글 다는 사람도 쉽게 수정할 수 있다.
• 위키만으로 된다. 프레임 나눌 필요 없다.
• 위키이니만큼 각종 위키 태그를 사용할 수 있다.
• 날짜로 찾아서 볼 수가 있다.

반대로 이런 위키일기장의 단점은,

• 일기 페이지들의 제목이 "Diary/2005-02-28"처럼 오직 날짜로만 구성된다는 점
  • "URL에 페이지 제목이 나타나기 때문에 URL만 봐도 내용을 짐작할 수 있다"는 위키위키의 장점을 전혀 살리지 못하며, URL에 인덱스번호나 날짜가 나타나는 웹게시판, 블로그와 동일해져 버림
  • 위키 내에서 검색이나 목록을 출력했을 때도 오직 날짜밖에 나오지 않음. 이것은 웹게시판이나 블로그보다 더 나쁜 상황을 만든다.
  • 예를 들어 GyparkWiki 에서 "블로그"를 검색했을 때, Diary에 속한 페이지 중에서 해당되는 페이지 목록은 다음과 같다. 즉, 페이지 제목을 보고서는 그게 무슨 내용을 담고 있는지 짐작조차 할 수 없기 때문에 하나씩 다 클릭해서 들여다봐야 한다.

.... Diary/2004-04-01
.... Diary/2004-04-13
     ....
.... Diary/2004-12-23
.... Diary/2005-01-08

• 하루에 하나의 일기밖에 쓸 수 없다.
  • 물론 하루 일기에 두 가지 이상의 내용을 같이 적을 수도 있지만, 이 경우 트랙백을 받거나 보낼 때, 다른 곳에 일기의 링크를 걸 때 매우 애매해진다.

2. 해결책 궁리

그래서, 제목이 단순한 날짜가 아니라 내용을 나타낼 수 있게 할 방안을 궁리해 보자.

그 중 하나는, 현재의 "페이지제목"과 별개의 "제목"을 도입하는 방안이다.

현재 UseModWiki의 각 페이지는 "페이지제목.db"이라는 이름으로 DataDir에 저장되어 있고, 그 파일 안에는 페이지의 생성 시각, 수정 시각, 리비전 번호, 수정한 사람, 페이지의 내용 등이 들어간다. 여기에 별도로 "제목" 자료구조를 더 추가하여, 페이지리스트 등에서 이 제목을 출력하게 만들 수 있겠다.

그렇지만, 아무리 생각해도 좋은 방법이 아니다.

• 페이지를 편집하고 저장하는 과정, 페이지 목록을 출력하는 과정 등등을 죄다 뜯어고쳐야 한다.
• 현재는 DataDir에 저장된 파일이름만 얻어내면 페이지제목을 뽑아낼 수 있지만, 새로운 "제목"을 뽑아내기 위해서는 모든 *.db파일을 다 읽어야 한다.
• 두 가지의 제목이 혼용되면서 논리적으로도 혼동의 여지가 많다.

따라서 일단 기각.

다른 방안은, 현재 Diary와 유사하게, 온갖 잡다한 매크로를 추가하여 블로그 흉내를 내는 것이다. 이걸 좀 더 궁리해 보자.

3. 블로그 흉내내기

3.1. 기본 아이디어

• 위키블로그의 각 포스트는, 그냥 하나의 위키 페이지이다. 이것은 현재 일기장에서 "Diary/2005-02-28"이 하나의 페이지인 것과 마찬가지.
• 다만 제목은 현재처럼 날짜를 쓰는 게 아니라 다른 페이지들 처럼 내용과 연관된 제목을 사용한다.
• 하루에 두 가지 이상의 내용을 올릴 때는 각각의 페이지로 만들어 올린다.

이렇게 하면 다음의 장점이 있다.

• 각 포스트에 대해 코멘트, 트랙백은 기존의 기능을 그대로 사용할 수 있고, 다른 사이트와 트랙백 교환 등을 할 때도 애매한 점이 없어진다.
• 기존의 일기장처럼 코멘트와 트랙백 등이 다 페이지 내용에 포함되므로 자유롭게 수정하거나 관리할 수 있다.

사실 위의 구현은, 생각해보면 처음부터 가능했던 것들이다. 그냥 "Blog"라는 페이지 하나 만들고, 새로 글을 쓸 때는 Blog에다가 새 페이지의 링크를 추가해주면 된다. 그렇지만 이 경우 아래와 같은 문제점이 있다.

• 일기장과 반대로, 날짜를 가지고 페이지를 관리하기 힘들다. (월별 출력, 최근 5편 출력 등)
• 한 포스트를 본 후 다음 포스트로 이동할 때, "이전 글", "다음 글"로 가는 링크를 만들기 힘들다.

그런데 이제는 위의 두 가지 문제점을 해결하는 것이 수월해졌다.

• UseModWiki소스수정/PrevUpNext매크로를 만들면서 어떤 목록페이지를 보고 이전 글과 다음 글을 찾을 수 있게 되었음.
• UseModWiki소스수정/매크로모듈화와 UseModWiki소스수정/액션모듈화가 되어서, 블로그 전용 매크로를 잔뜩 만들어도 그다지 부담이 없게 되었다. ;-)

3.2. 구현 계획

3.2.1. 블로그 목차

"Blog/목차"페이지의 구성은 다음과 같다.

* [[/세번째포스트]] 2005-03-01   <-- 가장 마지막 글이 제일 위에
* [[/두번째포스트]] 2005-02-20
* [[/첫번째포스트]] 2005-02-10   <-- 가장 첫 글이 제일 아래에

3.2.2. 새 포스트 쓰기

3.2.3. 개별 포스트 페이지

3.2.4. 블로그 첫화면

3.2.5. 날짜별 블로그 관리

3.2.6. 블로그 관련 매크로

• blog_newpost : comment와 유사. 제목 필드와 날짜 필드. 날짜 필드에는 오늘 날짜를 디폴트로 출력. 저장 버튼을 누르면 목록 제일 위에 "* 제목 날짜"의 형식으로 저장
  • "제목"필드에 제목만 적고 저장할 때 대괄호쌍 [[ ]]를 추가할지, 대괄호쌍도 사용자가 직접 넣게 할 지 고민중.
• blog_prevnext(목차페이지) : 목차페이지를 읽어서, 현재 출력한 페이지의 이전 포스트와 다음 포스트의 링크를 출력 (완성)
• blog_includeorder(목차페이지,시작순서,끝순서) : 인자가 하나 뿐일 때는 목록에서 순서 범위에 해당하는 포스트들을 include. (완성)
• blog_includeday, blog_includedays : includeday와 includedays와 동일한 인터페이스, 동일한 동작을 하는 매크로인데, 사용할 일이 없다고 생각됨.
• blog_includeperiod(목차페이지,시작날짜,끝날짜) : 시작날짜와 끝날짜 사이에 해당하는 포스트들을 include. 월별 아카이브를 출력할 때 사용. (완성)
• blog_listorder, blog_listperiod : blog_include, blog_includeperiod와 동일한데, 본문을 include하지 않고 목록만 리스트로 출력하게 함. (완성)
• blog_calendar : calendar와 유사한 달력 매크로 (완성)
• blog_prevnextmonth : "2005-03"과 같이 어떤 달에 해당하는 페이지에서 이전 달과 다음 달로 가는 링크를 만들어 주는 매크로.
• blog_rss : RSS를 출력하는 URL의 링크를 만들어 주는 매크로

3.2.7. 블로그 전용 RSS

action=blog_rss 액션을 추가하여 목차페이지를 읽어서 RSS xml을 만들어 출력하도록 한다.

3.2.8. 부가 기능

• 달력
  • calendar와 유사한 blog_calendar(목차페이지,년,월,일) 매크로를 따로 만들어, 목차페이지를 읽어 각 날짜에 해당하는 포스트가 있는지를 검색하고, 포스트가 있는 날짜에는 해당 포스트로 가는 링크를 걸고 다른 날짜는 아예 링크가 뜨지 않게 함.
  • 한 날짜에 해당하는 포스트가 두 개 이상 있을 경우 목록에서 위쪽에 있는 (즉, 보다 나중에 작성된) 페이지로만 링크가 걸리는 것이 한계
• 카테고리
  • 사용자가 수작업으로 분류를 넣고, 분류들의 목록을 적어 줄 수밖에.
• 최근 포스트
  • 이건 목차를 읽어서 최근 몇 개만 출력하게 하면 된다. blog_listorder 매크로를 쓸 수 있겠다.
• 최근 리플, 최근 트랙백
  • 방법1. 리플의 경우는 comments 매크로와 비슷한 블로그 전용 blog_comments 매크로와 blog_comments 액션을 따로 만들어서, blog_comments 를 이용하여 입력한 리플의 경우는 따로 처리를 해 줄 수 있겠다. 근데 트랙백은 정말 대책없다.
    • UseModWiki소스수정/Comments매크로와 UseModWiki소스수정/TrackBack 패치의 소스를 고쳐서, 어떤 페이지(예를 들어 Diary)의 하위페이지에 코멘트나 트랙백이 달릴 경우, Diary/BlogRc 페이지에 그 내용을 자동으로 기록한다. 이 Diary/BlogRc 페이지의 내용을 <blog_listorder(Diary/Rc,1,10)> 등과 같이 읽으면 가장 최근 10개의 코멘트 또는 트랙백의 목록을 얻을 수 있다.
  • 방법2. 최근변경내역을 읽어서 그중 블로그목차에 해당하는 페이지만 걸러내어서, "최근 수정된 포스트" 순으로 출력할 수는 있겠다. 이 경우 수정된 포스트 제목을 보여줄 수는 있는데, 실제로 달린 리플이나 트랙백의 내용을 목차로 보여줄 수가 없다는 것이 한계.
• 월별 아카이브
  • 이건 따로 Blog/2005-02 등의 월별 아카이브 페이지를 만들어 그 페이지 안에서 blog_includeperiod나 blog_linkperiod를 써서 월별 포스트를 출력하도록 하고, 본문 우측에는 이런 아카이브 페이지의 목록을 적어주면 되겠다.

3.3. 한계점

• 블로그 내에서만 적용되는 카테고리 기능을 넣기가 힘들어 보임.
  • 분류분류를 응용해서 넣을 경우 분류를 나눌 수가 있는데, 한 분류의 포스트를 다시 작성시간순으로 배열하는 것이 만만치 않아 보임.
• 위키이다보니, 동일한 제목의 포스트를 두 번 이상 작성할 수 없다.
• 포스트에 해당하는 페이지를 삭제한다던가 목록 중간에 새로운 글을 집어넣을 때, 목차 페이지도 직접 고쳐 주어야 하는 불편이 있다.

4. 실제로 사용하기

4.1. 새로 만들기

• 블로그로 사용할 페이지의 이름을 결정한다. 예를 들어 "Blog"라고 하자.
• Diary 페이지의 소스를 Blog 페이지에 옮긴다. 이 때 소스 내에 "Diary/"란 문자열은 "Blog/"로 고친다.
• Diary/Header 페이지의 소스를 Blog/Header 페이지에 옮긴다. 역시 Diary는 Blog로 고친다.
• Diary/Footer 페이지의 소스를 Blog/Footer 페이지에 옮긴다. 역시 Diary는 Blog로 고친다.
• Diary/TemplatePage페이지의 소스를 Blog/TemplatePage 페이지에 옮긴다. 역시 Diary는 Blog로 고친다.
• Blog/List 페이지를 만든다. Diary/List페이지의 소스 중에서 다른 것은 필요없고 다음의 줄만 적어주면 된다. 나머지는 장식이거나, 이 GyparkWiki에서만 적용되는 것들이다.

<blog_newpost(Blog/List)>

• Diary/Archive 페이지와, Diary/2005-02등의 월별 페이지를 비슷하게 Blog의 하위페이지로 만들어준다.
• 새 글을 쓰고 싶으면 Blog/List 페이지에 가서 텍스트필드에 글제목과 날짜를 넣고 저장버튼을 누르면 해당 글로 가는 링크가 생긴다. 그 링크를 들어가서 "내용"을 지우고 그 자리에 내용을 작성하면 된다.
  • 날짜 필드는 기본적으로 현재 날짜가 들어간다. 만일 작성일을 어제나 그 이전 날로 하고 싶으면 고쳐 준다.
  • 주의점: Blog/List 에 있는 글목록 리스트는 항상 글제목 우측에 있는 날짜가 내림차순으로 (최근 날짜가 위로) 소팅이 되어 있어야 한다. 가장 최근 포스트보다 이전 날짜의 포스트를 작성해주고 싶다면 List페이지를 수작업으로 고쳐서 순서를 맞춰줄 것.
• Blog/BlogRc 페이지를 만든다. 이 페이지는 아무런 내용이 없어도 된다.
  • Blog의 하위페이지에 코멘트나 트랙백이 달리면 이 Blog/BlogRc 페이지에 자동으로 기록되며, Blog/Footer 페이지에서는 blog_listorder매크로를 사용해서 그 기록을 출력한다.

4.2. 기존 일기장 방식에 덧붙이기

• 미친 척 기존의 Header, Footer 등의 원 페이지를 수정해 버린다. Footer에는 기존 날짜에는 calendar 매크로를 그대로 써서 예전 글을 달력에 표시할 수 있도록 한다.

• 새로운 헤더와 풋터 페이지를 만든다. (BlogHeader, BlogFooter 등) 새로 작성하는 글들은 이 새로운 헤더를 include 하게 한다.

4.3. 기존 일기장도 블로그 방식으로 변환하기

• 일기로 쓰던 메인 페이지(역시 Blog라 하자)와 그 하위의 /Header, /Footer 페이지 등을 위에서 얘기한 데로 고쳐준다.
• /List 페이지에 기존의 글들의 목록을 추가해 줘야 한다. 다음과 같은 식이 될 것이다.

<blog_newpost(Diary/List)>        <-- 이 매크로 바로 아래 덧붙임
* [[/2005-02-26]] 2005-02-26      <-- 기존에 썼던 가장 마지막 일기
* [[/2005-02-18]] 2005-02-18      <-- 이런 식으로, 글의 제목과 작성날짜가 동일하므로 같은 날짜를 두 번 써주는 형식이 된다.
...
* [[/2003-09-14]] 2003-09-14
* [[/2003-09-13]] 2003-09-13      <-- 가장 처음 쓴 일기

• 근데 위와 같이 목록을 쓰는 게 좀 귀찮다. 주인장의 경우는 페이지목록에 가서 Diary의 하위페이지 목록을 긁어 온 다음, 월별 페이지 줄은 지우고, 남은 줄을 ViEditor를 써서 각 라인을 위와 같은 형태로 치환한 후, 리눅스에서 sort 명령을 써서 순서를 역순으로 바꿨다. 이렇게 하면 매우 간단한데, 그 외 다른 에디터로는 어떻게 해야 할지 모르겠다. :-)
• Diary/2005-02등과 같은 월별 페이지는, 수정해도 좋고 말아도 좋다. 수정하지 않고 그냥 쓸 경우 기존의 include 를 쓴 경우는 이전 글이 먼저 오고, blog_includeperiod 를 쓴 경우는 최근 글이 먼저 오기 때문에 일관성이 없다는 단점이 있다.

5. 기타