UseModWiki소스수정/사용자의견 페이지의 소스 보기
마지막으로 [b]
-- Loading page list... --
내용출력
로그인[l]
Diary
[f]
최근변경내역
[r]
페이지목록[i]
횡설수설[2]
게시판[3]
링크
수정할 수 없습니다: UseModWiki소스수정/사용자의견 는 읽기 전용 페이지입니다.
[[UseModWiki소스수정]]의 [[하위페이지]]입니다. UseModWiki 를 사용하시는 분들 중에 자신이 직접 수정한 부분이 있거나, 여기에서 언급하지 않은 다른 수정 사항에 대해 아는 바가 있다면 이곳에 적어주시면 감사하겠습니다. 또는 이 곳에서 언급한 수정 사항에 대한 의견도 환영합니다. 패치 정보에 대해 적어 주실 때에는 최대한 [[UseModWiki소스수정]]에서처럼 원본코드와 수정한코드, 수정한 이유, 부작용 등의 기타사항 등을 같이 적어주시고, 그 수정사항을 반영한 홈페이지의 주소 등을 언급해 주시면 감사하겠습니다. * [[/반영된사용자의견]] - 여기에 올라온 의견들 중에 [[UseModWiki소스수정]]에 반영된 것들은 따로 옮겨 두겠습니다. 목차:
== # 이모티콘 :| = '''이모티콘 :|''' sub EmoticonSubst 함수를 보시면 :|를 위한 그림경로가 변수로 지정은 되어있는데, 사용을 하지 않고 있습니다. 아마도 | 이거 충돌 때문인거 같은데, 별 문제 없을거라 생각하고 살렸습니다.(그러나 어떤문제가 있어서 이것을 막아논건지 전혀 짐작이 안가 장담은 못합니다.. ^^) {{{ sub EmoticonSubst { .... if ($UseEmoticon) { .... $txt =~ s/\s\:[-]*\|/$e1/g; ##추가 } return $txt; } }}} '''이모티콘 도움말에 :| 추가''' 이모티콘 도움말 루틴을 찾아서 (''';-)'''이걸로 찾으세요) {{{ * :-|
:-| :|
추가. }}} 여기서 끝나는게 아니고, 이모티콘 루틴의 {{{ # $text = q| # .... # |; 윗내용을 아래처럼 바꿉니다. 바꾸는 이유는 q| ... |의 "|" 이것과 :-|의 "|" 이것이 충돌하기 때문. qq()괄호도 오류생김. $text = " .... "; }}} 메신저 이모티콘을 어떻게 하면 쉽게 추가할 수 있으려나... -_-; 수고하세요:)
: MSN 메신저 이모티콘이 되는 수정버전은 http://host9.swidc.com/~ncc1701/msnwiki/wiki.cgi 에서 받으실 수 있습니다.
: 감사합니다. :)
== # macrosubst의 매크로 내용들을 dorequest의 action에 연결 == 소스기능추가가 엄청 많이 됐군요.. 흐미.. 그리고, 지금 추가된 기능들이 페이지 매크로로 끝난다면 너무 아까울것 같아서...;; 수고하세요 ^^
: 같은 생각 하고 있었습니다. 매크로쪽을 그럭저럭 손 본 후에 action 쪽에도 만들어보도록 하죠. 어차피 매크로 함수의 코드를 그대로 쓸 수 있을 것 같으니...
: 아 그리고... [[역링크]] 관련 루틴들은 지금도 미흡하게나마 됩니다. 원래 코드에서 cgi 파라메터를 지원했기 때문에.. action=links 뒤에 인자를 붙여서 효과를 낼 수 있습니다. 물론 수동으로 주소 입릭창에 적어주어야 하지요. 필요하다면 해당 액션에 대한 링크를 화면 어딘가에 배치시킬 수 있겠군요.
GetFullLinkList
함수 소스를 보시면 사용 가능한 옵션들이 있습니다. 주로 값은 0,1,2 등을 할당하게 되어 있고요. 웬만큼 요긴한 것들은 이미 만들어져 있더군요. : {{{ 예: wiki.pl?action=links 이게 상단의 링크 버튼을 눌렀을 때 나오는 화면이고 wiki.pl?action=links&reverse=페이지이름 특정 페이지의 역링크만 찾을 때 wiki.pl?action=links&exists=0 존재하지 않는 링크들만 찾을 때 등등등.. 두 가지 이상 옵션은 & 로 연결해서 적어주면 됩니다. }}}
== # sub매크로 == 지양님의
매크로 패치를 적용해서 쓰는 중인데. 편집된 페이지를 프리뷰 할 때마다 로긴된 아이디 페이지에 있는 서브페이지 목록이 나오는군요.. DoPreview함수랑 DoEdit함수를 들여다 봤는데 뭐가 뭔질 알수가 없네요.. 흑..어떻게 방법이 없을까여 ㅡ.ㅡ;
: 그렇게 뜬금없이 말씀하시면... :-) 구경 가보니 현재 페이지의 하위페이지들의 목록만 뽑아내는군요. [[지양]]님께서 코드를 공개해 주시고, 아울러 preview 에서도 제대로 적용되게 해 주시길 간절히 기원합니다. ^_^ 제가 따로 처음부터 만든다는 것은 괜한 일이겠죠?
:에구 죄송합니다. 지양님 diff찾아보면 있기 ㅤㄸㅒㅤ문에 알고 계신줄 알았거든요..^^; 원래 지양위키의 기능은
가 불리면 해당페이지의 하위목록을 보여주는 건데,
요런식으로 상위페이지를 지정할 수 있게 약간 바꿨습니다. 이유는 오로지 미리보기에서 제대로 안나오는게 걸거치다는 것입니다. ;;; {{{#!vim perl sub GetSubPageLink { my ($id) = @_; my $name = $id; # $name =~ s/.*\//\//; $id =~ s|^/|$MainPage/|; if ($FreeLinks) { $id = &FreeToNormal($id); $name =~ s/_/ /g; } return &ScriptLink($id, $name); } sub MacroGetSubPageList { my ($rootpage) = @_; my (@pagelist); @pagelist = &AllPagesList(); my $subpage; my $result; $DocID = $rootpage if($rootpage ne ""); foreach $subpage (@pagelist) { if ($subpage =~ m|$DocID/|) { $result .= &GetSubPageLink($subpage); $result .= "
" if($rootpage eq ""); } } return $result; } ######## ↑여기까지 추가합니다. ###### ####### ↓별표친 부분을 추가합니다. ###### sub MacroSubst { .... $txt =~ s/\&__LT__;sub\(([^\n]+)\)\&__GT__;/&MacroGetSubPageList($1)/gei; ### ★☆★☆★☆★☆ 별표친부분 .... } sub DoEdit { .... body += '< body>< form method="post" action="$ScriptName">'; # 아래부분 추가 body += '< input type="hidden" name="id" value="$id">'; # ★☆★☆★☆★☆별표별표별표별표별표별표★☆★☆★☆★☆ # DoEdit 함수의 추가부분은 자바스크립이 들어가기때문에 #으로 된 주석을 반드시 삭제. .... } sub DoPreview { .... $ClickEdit = 0; $DocID = &GetParam('id', ''); ## 추가 ★☆별표 .... } ############# 여기까지 }}} 몇 가지 의견: *
GetSubPageList
대신
MacroSubPageList
로 이름을 짓는게 일관성 측면에서 좋겠습니다. * 매크로 안에서 "\n" 을 출력하는 것은, 저번에 언급한 pre 태그가 첫번째 라인에만 걸리는 문제가 생길 수 있기 때문에 빼는 게 좋겠습니다. * 미리보기에서의 문제점은, 제가 preview 의 동작을 이해하지 못한 상태라 어찌할수가 없네요, 그리고 이중 작업을 할 필요는 없겠으니 언젠가 해결될 때까지 기다리렵니다. :-) 건투를 빕니다~
:수정했습니다.
매크로는 세로출력
매크로는 가로출력입니다. 출처는 지양위키입니다. :)
-- Hi Raymundo, I'm JuanmaMP. Here again :-). I hope your day is going well!. I think that on 3. sub매크로 when it says "if ($subpage =~ m|$DocID/|)" maybe, want to say "if ($subpage =~ m|^$DocID/|)". Isn´t it? Thanks. == #
TABLE:
== 말 나온김에... TABLE도 한번 선언되면 IMG와 마찬가지로 모든 테이블이 같은 속성을 갖게 되는데, 그냥 개별속성으로 해야하게끔 해버렸습니다. {{{#!vim perl sub WikiLinesToHtml { .... while (@htmlStack < $depth) { push(@htmlStack, $code); if ($code eq "TABLE") { # added luke $pageHtml .= "
\n"; } else { $pageHtml .= "<$code>\n"; }; # added luke # $pageHtml .= "<$code>\n"; # deleted luke $TableTag = ""; ### 이거 한줄만 추가 } } .... 이하생략 }}} 다른문제는 모르겠고, "align=right"로 설정되면 줄이 약간 희한하게 나오던데 그건 원래 그런 것인거 같으니 별 상관없다고 봅니다. 근데 IMG 이거는 아무리봐도 대책이 안서는데, 어떠케 해야될지...흑.. ㅜㅡa
---- == #
COMIC:만화책출간일자
== 순전히 개인적인 목적입니다. --;; 만화책 전용이며, ISBN코드가 아니라 만화책 출간일자로 찾습니다. -_-a (굳이 COMIC으로 따로 떨군 이유입니다..;;) 조프님 사이트를 돌아다니다가 알게된 http://www.mani.co.kr 라는 사이트를 링크시켰습니다. 정규표현식을 잘 모르는 관계로 역시나 소스는 지저분합니다. :) {{{#!vim perl use vars qw(@RcDays @HtmlPairs @HtmlSingle .... $COMICPattern #### 추가한다. sub InitLinkPatterns { .... $ISBNPattern = "ISBN:?([0-9- xX]{10,})"; $COMICPattern = "COMIC:?([0-9- xX]{10,})"; #### 추가한다. .... } sub WikiToHTML { .... s/$ISBNPattern/&StoreISBN($1)/geo; s/$COMICPattern/&StoreCOMIC($1)/geo; #### 추가한다. s/CD:\s*(\d+)/&StoreHotTrack($1)/geo; .... } sub StoreCOMIC { my ($num) = @_; return &StoreRaw(&COMICLink($num)); } #### 함수전체를 추가한다. sub COMICLink { my ($rawnum) = @_; my ($rawprint, $num, @split_num); $num = $rawnum; @split_num = split //, $rawnum; $rawprint = $rawnum; $rawprint =~ s/ +$//; $num =~ s/[- ]//g; if (length($num) != 10) { return "ISBN $rawnum"; } return "
"; } #### 여기까지. }}} 저도 이번주부터 시험이군요.. 여태껏 모르고 있었다니..쿨럭..==; 수고하세요 :)
== # -_- Link == {{{ sub SplitUrlPunct { ... #### 바꿔준다. ($punct) = ($url =~ /([^a-zA-Z0-9\/\x80-\xff|\-|\_|\^]+)$/); $url =~ s/([^a-zA-Z0-9\/\x80-\xff|\-|\_|\^]+)$//; #### 끝. .... } }}} 설마 - 이거랑 _ 이거 들어간다고 별일 생기는건 아니겠죠 ㅡ.,ㅡ?
== # 최근변경내역 개선 == * 마이너 에딧의 한계를 정해주는 것이 바람직하다. ** 일정 바이트 이상을 고치면 마이너 에딧으로 인정하지 않는다. ** 그냥 세이브를 해도 일정 바이트 이하가 수정되면 자동으로 마이너 에딧을 표시해준다. ** 일정 로열티가 쌓이지 않은 사람에게는 마이너 에딧을 허용하지 않는다. 아 로열티는 어떻게 판단하느냐가 남는군...로그를 쌓나? -_- ** 메이저 에딧을 만들어서 누군가가 대량으로 고쳐 사람들에게 주목도를 높이고 싶을 때 사용할 수 있도록 하는 것도 좋을것이다. * 특정분류의 RC보여주는 방법을 어떻게 할것인가. 디폴트 RC를 설정할 수 있게 한다. ** 페이지 만들 때 반드시 분류가 부여되어있어야 한다. ** 위키의 장점인 저자동 고유연성을 해치는 것이 아닌지 심히 염려된다. * RC에 나타나는 최종 수정자를 중복되지 않게 5명까지 보여주고 풍선도움말로 고친 시각과 IP를 보여주면 좋을듯 하다. 이렇게 하면 간략하게 히스토리를 볼 수 있어 그 페이지에 대한 주목도가 높아질 수 있다. {{{ (변경사항) TalkingDrum 17:04 (133 번 변경됨) . . . . . || SonDon || 거북이 || DarkTown || }}} * 로그인을 한다음 특정 링크를 누르면 본인이 한번이상 작성한 적이 있는 페이지만 RC에 뜨게 해준다. ** 그 횟수는 개인적으로 조절할 수 있으며 여러번 수정한 페이지라면 더욱 눈에 띄는 색으로 나오도록 할 수 있을것이다. 이 경우 사용자가 많아져서 페이지 수정이 많이 이루어질 때 유용할 것이다. ** 역시 로그를 남겨야 하나? -.- * 역시 나만의 커스터마이징 된 RC를 만들 수 있어야 한다. 모든 페이지에 개인페이지에 추가하기/개인페이지에서 제거하기 토글 버튼을 만들면 간단하게 할 수 있다. 로그인만 되어있다면. ** 예를들면 사용자 [[거북이]]가 있다. [[거북이]]로 로그인하여 위키를 돌아다닌다고 생각해보자. ** 모든 페이지에는 '내 페이지에 추가하기' 링크가 달려있다. 이 링크를 누르면 그 페이지는 [[거북이]]의 집중관리대상 페이지로 지정된다. ** [[거북이]]의 [[최근변경내역]]에는 '집중관리대상 페이지보기'(가칭...-_-) 링크가 있다. 그것을 누르면 [[거북이]]가 지정한 페이지들'''만'''의 [[최근변경내역]]이 나온다. ** 즉 오래간만에 오거나 갱신되는 페이지들이 매우 많아졌을때 [[거북이]]는 원하는 페이지들의 최근 변경상태를 확인해서 피드백을 남길 수 있다. ** 집중관리대상에서 빼고싶으면 [[최근변경내역]] 혹은 해당페이지로 가서 '개인페이지에서 제거' 링크를 눌러 뺄 수 있다. * 모인모인처럼 새 페이지와 수정된 페이지를 구분하는 기능. --[[거북이]] == # 관리자가 지정한 페이지는 손님에게도 편집권한 허용 == {{{#!vim perl ## config.pl에 추가 @GuestPage = qw(방명록 오에카키 낙서장 WikiSandBox); # 공개할게 없으면 ""; # 비공개위키의 경우 손님에게 공개할 방명록페이지 지정 ## 끝. ## wiki.pl use vars qw(@RcDays @HtmlPairs @HtmlSingle .... @GuestPage); #### 추가. sub UserCanEdit { .... if (($id ne "") && (-f &GetLockedPageFile($id))) { return 1 if (&UserIsAdmin()); # Requires more privledges # Later option for editor-level to edit these pages? return 0; } #### 추가 if (@GuestPage ne "") { foreach my $grep_temp (@GuestPage) { return 1 if ($grep_temp eq $id); } } #### 끝. if (!$EditAllowed) { return 1 if (&UserIsEditor()); return 0; } .... } }}} 방명록 달기 귀찮아서 저는 이렇게 쓰기로 했습니다. :)~ 여러개 지정 가능합니다.
== # UTF-8 == http://www.sanori.net/wiki/moin.cgi/WikiSandBox 이곳을 보고 재미있을 것 같다는 생각에 이래저래 뻘짓을 해봤는데 난감하군요,
$LinkPattern
관련부분에 하드코딩된 euc-kr 코드 범위를 전부 utf-8의 범위로 바꿔주는건 별 문제가 아닌데, 브라우저 주소창에서 주소를 utf-8로 보내주는 부분이 해결이 안되네요. http://www.sanori.net/wiki/moin.cgi?goto=커크 이런 식입니다. http://www.piwd.net/cgi-bin/utf8_wiki.pl?FrontPage 이렇게 테스트 중입니다. 넷스, 오페라 같은건 말할 것도 없고, 익스플로러 설정에서 주소를 항상 utf-8로 보냄을 켜도 저렇군요. 뭔가 방법이 없을까요 --?
생각나서 다시 한번 적어봅니다. UTF-8의 유즈모드위키가 있으면 좋겠어요. ^^ 근영님 잘 계시죠?
== # 셀 개념의 도입 == 저는 준컴맹이라서 의견밖에 제시를 못하니 이해하시고... ^^ 의외로 사람들이 이런 식으로 사용하곤 합니다. ---- || http://myhome.hanafos.com/down2/86/94/52/01/6/hdyhaha_18.jpg || 대학1학년 때 서울로 올라오면서 본격적으로 WWF에 미치기 시작했었다. 제이크더스네이크와 밀리언달러맨, 브렛히트맨하트, 션마이클스, 오오…그리고…이름도 거룩한 얼티밋워리어여…군대생활의 공백을 넘어 다시금 나의 영웅이 된 인물은 물론 스톤콜드 스티브오스틴…그러나 언더테이커의 카리스마도 무척 좋아했었다. 개인적으로는 부활 이후 와일드씽 폭주족과 같은 설정은 그리 맘에 안든다. 더락…이 한인물하는 놈이야말로 WWF의 쇼맨쉽을 온몸에 달고다니던 훗가시의 왕자!…이젠 영화배우로서 링에는 모습을 안보이고있지만 우리는 다 안다. 조만간 다시 링으로 성큼성큼 걸어올라와서 로프 위에 올라서서는 관중들의 열광을 들이마시는 그 특유의 세러머니와 피플스 엘보우를 보여주리란걸…아! 또한가지, 물론 욕많이먹고있는것이긴 하지만 몇년전부터 수위를 높이고있는 에로틱 테마...하나같이 운동을 한건지 수술만 열심히 한건지 알길이 없는 여성레슬러나 레슬러들의 애인들을 둘러싼 에피소드들도 감칠맛을 더해가는 양념중에 양념^^ 이 나이에도 그 뻔한 쇼를 보면서 흥분하고 재밌어하는게 한심하게 느껴질 때는 내 주위에 나보다 더 광팬들인 선배들을 보면서 위안을 삼고는 한다.^^ WWF…이것이야말로 가장 미국적인 쌩쇼가 아닐는지…비판의 시각을 배제하고 보면 너무나 잘 만들어진 한편의 초대형 스포츠액션 성인시트콤이라고 할 수 있겠다. 케이블을 끊은 이후로 이것 역시 제대로 못보다보니 최근 소식에 뒤쳐졌었는데, 근래에 WCW와 통합하여 WWE로 새롭게 시작을 한듯 보인다. 왼편의 사진은 WWF입장권이라고 한다 쿠오오... \\ 크아앗...1월23일 한국에서 드디어 WWE Far East Tour 가 온단다...꼭 보러가야되는데...ㅠ.ㅠ\\ 한편으론 반미감정에 휩싸여있는 이 나라에 미제자본주의 쇼비즈의 상징물이 하필이면 요 시점에 온다니...|| ---- || http://www.siwan.co.kr/2/image/0000/0030.jpg || 1. GODEVIN LE VILAIN \\ 2. LES LONGUES NUITS D'ISAAC \\ 3. SI J'ETAIS LE MESSIE \\ 4. BALLADE POUR UNE ORGIE \\ 5. EXODE \\ 6. LA BATAILLE DU SUCRE \\ 7. FILS DE LUMIERE \\ 8. AU DELA DU DELIRE || ---- 즉 표 안에 뭔가 덩어리를 만들어서 넣고자 하는 욕구가 있는거죠. 그래서 셀 개념을 도입하는 것이 어떨까 합니다. 그것은 {3 3}(뭔지 아시죠? -_-)과도 비슷한 식으로 사용할 수 있을겁니다. ||{[ ]}|| 이런 식으로 사용하면 되겠죠. 에구 복잡하긴 하네. 그럼 두번째의 예는 이런 식으로 표현이 가능해질 겁니다. {{{ || http://www.siwan.co.kr/2/image/0000/0030.jpg ||{[ # GODEVIN LE VILAIN # LES LONGUES NUITS D'ISAAC # SI J'ETAIS LE MESSIE # BALLADE POUR UNE ORGIE # EXODE # LA BATAILLE DU SUCRE # FILS DE LUMIERE # AU DELA DU DELIRE ]}|| }}} 즉 기존의 텍스트포매팅들이 그대로 먹게하되 앞뒤에 태그를 달아 하나의 셀로 인식하게 하는거죠. 어려울까요? ^^
: 어려울 것 같은데요. (적어도 제게는 ^^;) 라인 단위로 마킹하는 시점에서 저것을 어찌 구분할 수 있을런지 모르겠습니다.
: \\\\ 이거 관련 부분을 약간 수정해주면 #이나 *은 힘들어도 대충 쓸 수 있을거 같은데요.
---- 텍스트 포매팅 룰을 재미있게 쓰고있는 사이트를 하나 찾아서 알려드립니다. 하테나라는 일본 사이트에요. * http://d.hatena.ne.jp/help
뭐가 재미있는 건지 모르겠는데요? 일본어를 모르니 무슨 사이트인지도 모르겠고... ^^a
== # 이미지 자동 저장 == 생각난김에 하나 더 써봅니다. 이건 좀 허황된 것이 아닌가 싶은데... 위키에서는 이미지 링크를 많이 하게 됩니다. 그러다보면 그쪽 서버 사정으로 이미지가 일시적으로 돌아가시거나 아님 아주 날아가버리는 일이 종종 생깁니다. 아주 짜증나는 일이 되죠. 특히 중요한 이미지일지도 모르는 것일 경우에는요. < mysign >처럼 저장할때 돌아가는 태그를 하나 만들면 어떨까 합니다. 예를들어 :
라는 태그가 있다고 해보죠. 그러면 0030.jpg이미지를 자동으로 저장해서 특정 디렉토리 안에 넣고 저 태그는 : simg:0030.jpg 라고 저장되는 겁니다. 물론 인터위키는 걸어두어야겠지요. 특정 디렉토리는 설정단계에서 고칠 수 있는거구요. 이렇게 하면 마음의 평화가 깨지지 않고 이미지들을 잘 모을 수 있을거 같거든요. 대신 하드가 채워지겠죠. ^^
: 나쁘지 않은 생각 같습니다. (바로 위에 적으신 것보다는 이쪽이 덜 허황된 것 같은 느낌인데요 ^^) 별도의 유틸리티 wget 을 호출하게 하면 될 것 같은데, 그것을 쓰지 않고 perl 만으로 하려면 어떻게 해야 될 지 모르겠네요. 그리고, 남이 임의로 페이지 하나에 저런 태그를 마구잡이로 넣어서 하드를 채워버리는 것을 막아야겠군요. * 파일 크기 제한 - wget 의 quota 기능 사용 * 기존에 존재하는 화일과 이름이 겹칠 경우 고려 * 저작권 문제 - 대책없음 * 기타 등등 - 천천히 생각하기로~
::게시판에도 써놨습니다만, 그냥 화일 업로드 기능을 만드는게 더 낫지 않을까 싶습니다.
될만하다니 다행이군요. 파일 업로드 기능은 당연히 필요합니다. 하지만 저건 좀 다르죠, 일종의 백업이니까요. 뭐 임시적으로 사람들에게 의미있는 것들이면 그냥 링크만 해도 되겠지만 가끔 날아가지 말았으면 하는 이미지들이 있답니다. 저같은 경우는 음반 재킷이나 책 표지같은게 그렇구요.\\ 저작권이야 뭐 외면하는거죠. ^^a 파일이름이 겹치면 __따위를 붙여줘야겠네용.
== # RC, 편집창 크기 == 두개군요. ^^; # 변경내역을 매크로화 시켜서 임의의 페이지에 집어넣게 할 수 있을까요? # 편집창의 크기를 환경설정이 아닌 편집창에서 조정 가능하게 액션을 추가할 수 있을까요? : 1번은 시도해 보겠습니다. 사실 작년부터 탐을 내던 기능인데, DoRc 나 GetRcHtml 을 그대로 재사용하려고 했더니만 원체 그런 고려 없이 만들어져 있어서 뜯어고칠 곳이 많다고 관뒀었습니다만.. 저 역시 있었으면 하는 기능인터라... 2번은... 글쎄요, 환경설정에 있는 해당 항목을 편집창에 똑같이 달아두면 안 되려나요? 아니면 입력하는 와중에, 현재 입력한 내용을 보존하면서 크기를 자유롭게 조절하는 것을 바라시는 거라면..그런 게 가능한지조차 저는 모르겠습니다.
:: 2번은 DHTML과 자바 스크립트를... 미친듯이 사용하면 가능하긴 합니다. [http://www.dhtmlcentral.com/script/?m=14 여기]에서 [http://www.dhtmlcentral.com/script/script.asp?id=16 WindowScript]라는 놈의 데모를 보세요. 이건 DIV 태그에 대해서 동작하는 것 같기는 하지만, TEXTAREA에 대해서도 비슷한 방식으로 크기 조절이 가능할 것 같습니다. (TEXTAREA의 크기를 바꾸는 데모도 본 것 같은데 어디서 봤는지 기억이 안나는군요.) 아니면 [http://mozart.chat.net/~jeske/Projects/Javascript/ 이것]처럼 입력창의 크기를 브라우저의 크기에 따라서 자동으로 바뀌도록 하는 것도 괜찮은 방법이 될 지 모르겠네요.
== # 글자에 색깔넣기 == 관심있는 분께서는 [http://www.usemod.org/cgi-bin/wiki.pl?WikiPatches/TextColours 여기]를 참고하세요. 저는 논의된 것들중에서 아래에 제시된 것을 적용시켰습니다. {{{#!vim perl I like the simplicity and look of this -- Tim Nelson The following syntax was lifted from the Webmacro Wiki http://wiki.webmacro.org/WebMacroWiki ^ -- used for color. The next word (or HTML color value) that follows the caret will be the color used: ^blue This text will be blue here^ ^#FF0000 This text will be red here^ Patch: sub CommonMarkup { ... if ($doLines) { ... s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/
$2<\/FONT>/g; }}}
== # 크기별 인덱스 == {{{#!vim perl sub MacroSubst { .... $txt =~ s/(\&__LT__;sizeindex\(([-+]?\d+),([-+]?\d+)\)\&__GT__;)/&MacroSizeIndex($1,$2, $3)/gei; return $txt; } }}} {{{#!vim perl sub MacroSizeIndex { my ($itself, $start, $end) = (@_); my (%pgcount, $page, $pagefile, $count, @pages); my $txt; if (($start == 0) || ($end == 0)) { return $itself; } foreach $page (&AllPagesList()) { $pagefile = $PageDir . "\/" . &GetPageDirectory($page) . "\/$page.db"; $count = (-s $pagefile); $pgcount{$page} = $count; } @pages = sort { $pgcount{$b} <=> $pgcount{$a} || $a cmp $b } keys %pgcount; if ($start > 0) { $start--; } else { $start = $#pages + $start + 1; } if ($end > 0) { $end--; } else { $end = $#pages + $end + 1; } $start = 0 if ($start < 0); $start = $#pages if ($start > $#pages); $end = 0 if ($end < 0); $end = $#pages if ($end > $#pages); if ($start <= $end) { @pages = @pages[$start .. $end]; } else { @pages = reverse(@pages[$end .. $start]); } foreach $page (@pages) { $txt .= ".... " if ($page =~ m|/|); $txt .= &GetPageLink($page) . " (".Ts('%s byte'.(($pgcount{$page}>1)?'s':''), $pgcount{$page}) . ")
"; } return $txt; } }}} 페이지본문의 양이 아니라 '''*.db'''화일의 크기별 정렬입니다. \\ mostpopular 매크로 함수를 재활용했습니다. 당연히 사용법도 똑같습니다. ㅡ.ㅡa
== # 다단계 하위페이지 == UseMod:WikiPatches/PeriPerify 를 한번 봐주세요.
== # 본문 텍스트 바꾸기 == 이런거 함부로 공개해도 되나 모르겠는데...^^\\ 제가 본문의 특정 텍스트를 수정하기 위해 사무실 후배를 갈궈서 만든 소스입니다.\\ 유즈모드에는 페이지 이름 바꾸기는 있어도 풀 텍스트 스와핑(?)은 없지요.
* 사용법 {{{ >perl textswap.pl "koreanrock.com" "고려바위" }}} 요렇게 하면 부다다다 하면서 데이터폴더 안의 모든 하위폴더 페이지들에 있는 텍스트를 치환하더군요. * 부작용 : 모름 -_- * 개선점 : 정규표현식이 가능해야 함 : 울트라에딧처럼 :) {{{ #!/usr/bin/perl my $dir = '.'; my $orig = shift || die; my $change = shift || die; loop: chdir($dir); opendir DIR, "."; @files = readdir(DIR); foreach $file (@files) { next if $file eq '.'; next if $file eq '..'; if (-d $file) { unless(fork()) { closedir(DIR); $dir = $file; goto loop; } } else { print `pwd`."$file\n"; open FILE, $file; @lines =
; close FILE; foreach $line (@lines) { $line =~ s/$orig/$change/g; } open FILE, ">$file"; print FILE @lines; close FILE; } } }}} == # etc == * 지금 페이지 숨기기 기능을 쓰고있습니다만 버그는 잘 못찾겠구요. ^^ 몇가지 부가적 기능이 필요해 보입니다. ** 숨겨진 페이지는 외부 링크일 때 '새창으로 띄우기'와 같은 조그만 아이콘이 달려있거나 마우스 오버시 툴팁으로 알려주어야 할 거 같아 보이구요. 안그러면 사람들이 일일이 눌러봐야지 그 링크가 잠겼는지 안잠겼는지 알 수 있으니까, 많아질경우 거부감을 느끼게 될 듯 하네요. *** 이건 사전기능에서도 마찬가지던가요. ** 페이지 숨김 기능은 조금만 확장하면 폐쇄적으로 사용할 수 있을듯 합니다. 일반 게시판에서처럼 로그인해야 볼 수 있는 그런 형태가 되는건가요. 퍼미션이란 참 복잡한 문제입니다. * 페이지 숨김과 더불어 드는 생각입니다. ** 노스목같은 경우는 누구나 페이지 삭제와 이름 변경이 가능하죠. 제가 보기에도 장기적으로 그렇게 가는 것이 맞다고 봅니다. 여러 사람이 동시에 운영자가 되고 대신 그 내역이 공개된 장소에 나오면 되고, 삭제된 페이지를 복구할 수 있어야겠지요. 페이지 이름 바꾸기는 복구가 가능한데 페이지 이름 돌리기는 복구가 불가능할 수도 있겠네요. 페이지 이름 돌리기는 명령 건 다음 승인하는 식으로 가야하나...허허...-_-a ** 고려바위에서 여러 사람에게 운영자 권한을 주고 페이지 숨김기능을 이용하게 하려하니 이런 문제가 발생하더라구요. 그들이 임의로 페이지를 지우거나 이름을 변경해도 제가 알 수 없다는 문제요. * 아 쓰고나니 문장이 어수선하네요. 하라키리할까요? ^^a
사전은 [[조프]]님이 그런 아이콘이 나오는 게 싫다고 만드신 매크로입니다. :-) 아이콘이 필요하다면 매크로 대신 인터위키를 쓰는 것도 괜찮겠네요. NoSmoke 같은 경우..는 저번에도 [[Bab2]]님과 페이지 삭제 권한 얘기 하면서 제가 했던 말입니다만.. 칼을 쥐어주고 남용을 걱정할 바에는 아예 안 쥐어주는 게 낫다는 생각입니다. 페이지 삭제를 원한다면 내용을 지우고 태그만 붙여넣고, 이름바꾸기가 합의가 된다면 한 페이지는 내용을 지우고 다른 페이지를 만든 후에 관리자에게 부탁을 하면 그것으로 충분하지 않을까요? : 아...네 뭐 저도 주인장님 말씀에 동의해요 :) 지금 운영도 그렇게 가고있구요. : 제가 그런 걱정을 하게 된 이유는 다음과 같습니다. \\ 고려바위 사람들이 내부적으로만 보고싶어하는 내용들이 있다.\\ 그것을 위해선 몇몇 사람들에게 운영자 권한을 주어야 한다.\\ 그들에게 운영자권한을 주는 것까지는 좋은데 페이지 수정/삭제 등의 현황을 관리자인 거북이가 알 길이 없다. : 뭐 이런거거든요. 하지만 이게 필요하다고 해서 쓱 만들자 이런 의견은 아니구요. 좀 더 크게 봐야 할 것 같습니다. DB를 쓰지 않는다는 한계와 RC관련 문제 등 뭐 여러가지 유즈모드위키가 가지고 있던 문제들까지 고려해야겠지요. 나중에요. ^^
숨겨진 페이지로 가는 링크를 특별히 표시한다...는 것은, 매번 페이지 하나를 출력할 때마다 그 페이지 내의 모든 링크에 대해 숨겨졌는지 아닌지를 미리 조사해야 된다는 것을 의미합니다. 뭐 한 페이지에 링크가 수백개씩 되는 것은 아니겠습니다만... index 나 rc 화면하고는 사이트 전체적으로 오버헤드의 차원이 달라지지요. (실제 조사하는 오버헤드가 그렇게 크지 않기 때문에 규모의 차이는 별로 없을지 모르겠습니다만) 한 번 시도는 해 보겠습니다. "숨겨져있음"을 의미하는 작은 아이콘 하나 만들어 주시면 감사히 받겠습니다. (아이콘을 붙일지 아니면 링크를 별도의 class 로 걸지를 먼저 결정해야겠네요)
: 네 오버헤드는 분명 있을거 같았어요. 오버헤드를 줄이려면 또 뭔가 로그를 남기고 복잡해지겠지요. : 제가 아이콘같은거 만들어본적이 한번도 없어서 자신없지만 대신 아는 디자이너를 한번 괴롭혀볼께요. ^^ : 그나저나 페이지 이름 바꾸기나 삭제 등 운영자 기능은 언제 개선된건가요? 어제 혹시나 하고 해보니 너무나 빨리 작동해서 허망하게 기뻤거든요. 하하.
:: ''그나저나 페이지 이름 바꾸기나 삭제 등 운영자 기능은 언제 개선된건가요'' 가 무슨 말씀이신지 잘 모르겠는데요.. 그 기능들은 Luke 님의 K3 버전에 이미 있던 기능들이고 이 곳에서 크게 고쳐진 것은 없습니다만...
::: 흠 페이지가 늘자 한동안 버벅대면서 잘 안되었었는데 갑자기 쓰윽 하고 잘 되더라구요. 무슨 조화일까요...-_-a
:::: 링크참조부분 수정이 주효했을듯 싶네요..==a
숨겨진 페이지를 여러 사용자가 보게끔 하려면 새로운 사용자 그룹을 하나 더 만드는게 제일 편할겁니다. 그리고, \\ 아예 링크자체를 보이게 하지 않으려면 GetAnchoredPageLinkOrEditLink (이게 맞던가..ㅡ.ㅡa)함수를 수정해주시면 될겁니다. \\ (실제로 폐인월드는 그렇게 수정해서 쓰고 있습니다만.. 지금은 숨겨진 페이지가 한개도 없는지라..==a) : 아 페이지 삭제는 RC에 뜨는군요. 페이지 이름 바꾸기나 페이지 경로 돌리기는 막을 방법이 없긴 하지만 그래도 이정도면 몇몇 사람들과는 운영자권한을 공유해도 될 거 같아요. :) : 제가 모르는 기능이 너무나 많아져서 어서 공부를 더 해야겠습니다. : 새 사무실에서 페인트를 칠했는지 완죤히 본드 들이마신 효과가 나는군요...@.@
== # Etc the 2nd == 오늘 몇가지 매크로를 사용해보았습니다. 정말 세세하게 짜여진 프로그램이라는 생각이 들어 감동했습니다 :) 몇가지 버그를 찾은것 같구요. 그러고보니 지난 회사의 한 개발자가 버그라는 말을 정말 싫어했던 기억이 나는군요. 단지 문제가 좀 있다고 표현해달라고 했어요. ^^ 개선했으면 하는 점도 함께 적어봅니다.\\ 그리고 페이지가 나열되는 결과는 가능하면 페이지 목록보기처럼 나오는게 어떨까 하는 생각이 듭니다.\\ 실험은 KRock:위키낙서장 에서 진행했습니다. * myinterest ## mostpopular처럼 몇개만 본다라는 규정이 필요 ## myrecentchanges역할도 필요 * includeday ## 매크로 다음에 표같은 것이 안먹고 페이지 이름을 생략해도 안먹음 {{{ 입력 ||
||
||
|| 출력 ||
||
|| DeleteThisPage || }}} 원했던 출력(들어있는 내용이 DeleteThisPage밖에 없음) || DeleteThisPage || DeleteThisPage || DeleteThisPage || * orphanedpages ## 매크로에서 하위페이지로의 링크가 있는데 미아 페이지로 인식, 거북이/바보라는 링크가 있고 거북이 페이지에 [ [/바보] ] 이런 링크가 있으면 이것은 링크가 아닌 것으로 인식 ## REDIRECT는 미아 페이지에서 빼야함. 당연히 거의 미아 페이지이므로.
: 여러 가지 테스트를 해 주시느라 고생하셨네요. 감사합니다. 그런데 제 입장에서는 할 게 별로 없는 것 같네요 ^_^ * [[/IncludeDay매크로]] 에서 페이지이름이 인자로 없으면 현재 페이지를 기준으로 찾는 게 '''아닙니다''' 그냥 "2003-04-15" 페이지를 찾는 겁니다. 그 페이지가 없으니 안 나오는 겁니다. * 테이블의 경우에는, include* 매크로들은 먼저 페이지 내용을 삽입하고 그 다음에 각종 처리를 하기 때문에, 삽입되는 순간 삽입된 내용에 있는 줄바꿈이 포함되는 바람에 테이블이 깨져 버립니다.. || 를 사용하지 말고 명시적으로 table 태그를 써 보세요. * [[/MyInterest매크로]] 에서 숫자를 인자로 받는다 치면... 무슨 기준으로 숫자만큼의 페이지를 추려내죠? (방금 생각해보니.. 최근변경시각을 가지고 할 수는 있겠습니다만, 관심페이지의 갯수가 많아지면 오버헤드가 너무 큽니다) ** 오버헤드가 크군요. ^^ --[[거북이]] * RC 를 매크로로 만드는 것은 세 번이나 시도해 봤으나 너무 일이 커져서 관뒀습니다. 하물며 개인별로 관심 페이지의 RC 를 보는 것은... -_- 그 기능에 미련이 많으신 것은 압니다만 제게서 해법을 기대하지 마세요. ^^; ** 하하, 이것도 역시 트래픽이 커지지 않을까 싶은 생각이 드네요. --[[거북이]] * [[/OrphanedPages매크로]] 문제는... 그럴리가요. 제가 그런 하위페이지 링크를 링크로 인식시키려고 얼마나 고생했었는데.. ^^; 방금 KRock:위키낙서장/바보 라는 페이지를 만들어 시험해 봤는데 잘 되는데요? (고아로 인식되지 않음) ** KRock:고려바위통계 를 보시면 고아페이지 목록이 있습니다. 여기에 KRock:BrainSalad독서일기/01 이녀석이 고아로 나와있는데요 KRock:BrainSalad독서일기 에 [ [/01] ]이라는 링크가 있습니다. --[[거북이]] *** 소스 업데이트 이후에 maintain 한 번 해 주세요. 이유는 모르겠지만 01 페이지로 향한 링크가 계산되어 있지 않더군요. 독서일기 페이지를 한 번 수정해 주니 이제는 잘 나오네요. :-) --[[Raymundo]] **** 아 알겠습니다. 그런 문제가 있었군요. 어쨌거나 상세한 기능들에 대해 조금씩 알아가는 것이 즐겁습니다. ^^--[[거북이]] * REDIRECT 가 들어 있는 페이지는 당연히 거의 고아 페이지라뇨? 어째서요? ** 아, 제 실수군요. 저는 REDIRECT를 쓰는 것은 SandBox를 위키낙서장이라고 쓴다거나 하는 곳에서 사용합니다. 이 경우 페이지 내에서는 거의 위키낙서장으로 써있고 외부의 사람이 SandBox라고 적었을 때 돌려주기 위한 목적이지요. ** 즉 REDIRECT가 있는 페이지는 고아가 되기 쉽고 고아이더라도 별 의미가 없기때문에 빼는것이 어떨까 합니다. --[[거북이]] *** 그런 경우에만 사용하는 게 아니까 함부로 뺄 수가 없다고 생각합니다. --[[Raymundo]] *** 넵, 저도 굳이 고칠 필요는 없을 듯 해요. --[[거북이]]
내일이나 모레쯤 또 다른 것들을 열심히 돌려볼께요. ^^
== # 테이블에 각각 다른 배경색 지정 == 오랜만입니다. 건강하시죠 ^^? 모인모인에서 {{{ ||
내용.. ||
내용... || }}} 이런식으로 셀마다 다른 배경색의 지정이 가능합니다. \\ 굳이 저렇게 똑같이 따라갈 필요는 없겠죠. \\ 근데, 현재 적용된 정규표현식은 제가 처음에 말씀드렸을 때의 정규표현식과 많이 바뀌어서 손을 못대겠네요..ㅠㅠ
: 안녕하세요, 매일 아침마다 환절기 코막힘으로 고생하는 것 빼고는 건강하다 할 수 있겠죠 ^^; 요즘은 학교 일도 정신 없고 위키소스는 거의 손 놓고 있네요.. (그다지 손댈 필요도 느껴지지 않고) 하루하루 숙제 마감에 쫓기는 삶이로군요..
== # 다른위키사이트 건드리기 == 오랜만에 똑똑...;;; \\ 공부는 잘 되시나요? 결혼은 언제쯤..? ^^a \\\\ 에에.. 그니깐.. ㅡㅡa \\ 현재, [[Bab2]]라는 페이지가 여러 위키사이트에 동일한 이름으로 존재하는데, 이것을 예를 들어 Gypark에 있는 [[Bab2]]페이지만 건드리면 다른 사이트의 [[Bab2]]라는 페이지도 동일하게 수정이 되게끔 할만한 건덕지가 있을려나요..ㅡ.ㅡa 없을려냐냐... ㅡ.ㅡ;;; \\ 수고하세요 ^^
: 다른 곳에서 한쪽을 임포트하지 않는 한 어렵지 않을까요? 라고 개발 문외한이 한번 적어봅니다.
: 여러위키에 같은 내용을 post 해주는 cgi를 만들어 보심은. -_-; usemod wiki 끼리라면 대강 할 수 있을지도요.
::고려바위나 jof4002, redica 같은 곳은 걍 내용을 날려만 주면 되겠다 싶은데, 이곳처럼 회원가입이 필요한 경우에는 쿠키를 어떻게 처리해야하는지 모르겠네요. -.-a
: 서버 자체에 있는 cgi 가 만들어낸 것이 아닌 외부에서 날아온 POST 요청에 대해 응답을 할 수 있는건가요? 오에카키를 넣다가 타인의 계정에 그림을 추가할 수 있는 문제가 생길 것 같아 테스트했더니만 에러가 나더라고요. 그래서 불가능한가보다 하고 있었습니다만, 이 경우와는 다른 상황인지도 모르겠네요.
::게시판 스팸봇과 비슷하게 만들면 될 거 같다는 생각을 했거든요. 우움.. 게시판 스팸봇 관련자료 찾을데 어디 없을까요?
== # 안쓰는 옵션들 제거 == UseMod:OddMuse 를 참고하여... 거의 사용하지 않는 옵션, 또는 반대로 거의 항상 사용하는 옵션들은 옵션에서 제거해 버리고 소스를 간단히 고치는 게 좋을 것 같습니다.. 다만 점점 더 오리지널 UseModWiki 와 멀어지면 나중에 대책이 없어지는 사태가 발생할지도... 일단 UseMod:OddMuse 에서 언급한 것들을 나열해 보면.. * No more email notification * No thin-lines option - 이건 반대로 항상 살리는 게 나을지도 * No user preferences saved on the server - 허억, 쿠키를 쓴 건가? * Username saved directly in the cookie * No more conditional compilation (was disabled anyway) - 뭔 소린지.. *
ScriptTZ
is no longer an option; there is no more timezone handling, all timestamps use GMT - 흐음.. 모르겠음 *
UseCache
is no longer an option; it is never used (was disabled and not 100% functional anyway) - 찬성 *
UseIndex
is no longer an option; it is always used - 모르겠음 *
FastGlob
is no longer an option; it is always used - 무슨 옵션인지도 모르겠지만 찬성 *
UseHeadings
is no longer an option; it is always used - 찬성 *
UseDiffLog
is no longer an option; diffs are never logged - 모르겠음 * No more editlinks action, and no more editlinks file during maintenance. Pages can be deleted using the page deletion patch, and I have never ever had the need to rename pages. Using reverse lookup, and a few quick edits was always faster than figuring out what the password was, figuring out how to use the editlinks action, and praying that it all worked. - 뭐라는 건지 읽어보기 귀찮다 * Removed parameters such as alldiff, norcdiff, etc. - 찬성 * Removed diff-type 4 (4 got replaced by the default). The default is \ 1 (ie. major diffs). - 글쎄 * Removed diff-type 3 (no more author diffs). At the same time, when displaying a diff, \ no links to other cached diff types exist. People can use the page history to produce \ any kind of diffs they want. *
NonEnglish
is no longer an option; non-english characters are always allowed - 찬성 *
SimpleWiki
is no longer an option; numbers are always allowed - 찬성 * No more intermap file, no more banned list editing - 인터맵을 없애면 어떻게 인터위키를? *
UseSubpages
is no longer an option; the / separator is far too common for this to be useful, the shorthand /foo looks ugly, and the difference between
WikiPatches/RawMode and WikiPatchesRawMode
is hard to explain. - 하위페이지 쓰지 말자는 소린감? 반대 *
FreeUpper
is no longer an option; it was a source of confusion in one instance and requires extra explaining for non-US ASCII encodings (since it doesn't work, there). - 뭔 소린지 * Deleting a page no longer removes all corresponding entries from the rclog (and thus the deleted page is still part of RecentChanges if you go back long enough) - 이곳의 패치와 유사한 듯 == # 확장 기능을 붙이기 좋게 하기 위한 제안 == 안녕하세요. [[조프]]입니다. 간만에 이 페이지를 들어오게 됐군요. 오늘 몇몇 테스트를 해보다가 미처 몰랐던 사실을 알게 됐는데, Perl 에서 같은 이름의 함수가 2개 있어도 되더군요! 심지어 아래 있는 함수가 불립니다! 이걸 이용하면 [[Raymundo]]님이 배포하시는 버전을 받아서 확장기능을 붙이고 '''관리하기'''가 꽤 수월해지지 않을까 해서 아이디어를 정리해봅니다. * wiki.pl 의 마지막에서 require "wiki_ext.pl"; 을 호출한다. * MacroSubst 등의 함수 가장 아래에서 ExtensionMacroSubst 함수를 호출한다. ExtensionMacroSubst 같은 함수는 wiki.pl 마지막에 참고할 수 있게 기본적인 구현을 제공해도 되겠죠. 그러면 자기 위키에 필요한 매크로를 확장하고 싶을 때는 wiki_ext.pl 에 있는 ExtensionMacroSubst 함수에서 구현하면 되고요. 뭔가 원래 함수의 동작을 엎어쓰고 싶을 때는 통째로 wiki_ext.pl 으로 복사해서 원하는 기능을 제공하도록 고쳐주면 됩니다. 이모티콘을 원래 제공하시는 것 대신에 MSN 이모티콘으로 바꾼다거나 하는걸 한번 고쳐두면 새 버전이 올라왔을 때도 wiki.pl을 덮어쓰기만 하면 되겠죠. (사실 지금 HashKey, DataDir, ConfigFile 세 변수는 매번 수정해줘야 하는 것 같은데... 다른 분들은 새 버전 나왔을 때 업데이트를 어떻게 하시는지 모르겠군요) ps. 사실 제가 펄 책을 보고 확인하거나 한건 아니기 때문에 저 함수 덮어쓰기가 항상 일관되게 동작하는 원칙인지는 모르겠네요. 누구 책 있으신 분 좀 확인해주세요.
: 흥미로운 내용이네요. wiki_ext.pl 은 그러면 배포본(?)에서는 전혀 업그레이드되지 않을 화일이란 말이군요. 배포본에서 업그레이드해버리면 wiki.pl 과 똑같은 불편함이 생길테니까. (하지만 틀림없이 언젠가는 wiki_ext.pl 도 다시 손을 보는 날이 올 것 같군요, 처음부터 완벽하게 만들 리는 없으니..) 그리고 wiki_ext.pl 에다가 HashKey, DataDir, ConfigFile 세 변수를 초기화하는 함수를 두고 wiki.pl 쪽에서는 그 함수를 부르면 만사형통...이려나요? 일단 테스트 해 보겠습니다. 함수 덮어쓰기 얘기는 저도 책이 없어서.. 된다는 보장이 생기면 그 때 새 버전을 내어넣도록 하죠. (제 홈은 [[CVS]]를 사용해서 업데이트하기 때문에 전혀 문제가 되지 않았네요 ^^;)
완전히 갈아엎지 않는 이상 별 문제는 없을 것 같습니다. wiki_ext.pl에서 기본적으로 구현해야 하는 함수는 wiki.pl에 최소 사양으로 구현해두면 되고요. {{{#!vim perl ### wiki.pl 소스 # 이 이하의 함수는 wiki_ext.pl 에서 구현할 수 있는 함수의 원형입니다. sub InitVariables { $HashKey = "salt"; $DataDir = "data"; $ConfigFile = "config.pl"; } sub ExtMacroSubst { $txt = @_; return $txt; } require "wiki_ext.pl"; &DoWiki~~~; ### wiki.pl 끝. ### wiki_ext.pl 소스 return 1; }}} 뭐 이런 식이랄까요? ps. 추측이긴 하지만 perl 이 파일을 실행하면서 소스를 전부 읽어서 함수 맵을 만들어두고 실행하는 것 같습니다. 소스를 분석하다가 아래쪽에 같은 이름의 함수가 나오면 함수 맵에서 덮어쓰는 거겠죠. 그러면 기본 함수를 제공한다고 해도 몇 줄 읽기만 하고 실행은 안될테니 큰 부하가 걸리지도 않을 것 같네요.
: InitVariable 의 경우 말입니다만... config 화일 따로 있고, config 화일의 이름을 말해주는 화일 따로 있고..란 것도 좀 우습다 싶네요. config 화일의 이름을 따로 지정할 수 있게 했던 이유가, 웹서버 환경에 따라서 브라우저로 config 화일을 그대로 볼 수 있어서였는데, wiki_ext.pl 에 그 이름을 보관하면 다시 같은 문제가... : 차라리 예전의 상태로 회귀하여, config 화일의 이름은 그냥 config.pl 로 고정하고, 그러면 DataDir 과 HashKey 는 config.pl 안에서 정해 주면 어떨까 싶은데요. (예전에는 분명 config.pl 을 들여다 볼 수 있다고 생각했는데 지금 해 보면 forbidden 이 나는군요. 제가 착각했던 것인지 아니면 웹서버 설정에 의존한 것인지 모르겠습니다) : 그리고 예전에 소스크기를 줄인다고 wiki.pl 과 config.pl 에 중복해서 정의되어 있는 전역변수 설정들을 wiki.pl 에서 제거했던게 크나큰 실수였습니다. 디폴트값을 wiki.pl 쪽에 만들어놔야 사용자는 자기의 config.pl 을 그대로 보존하면서 버전업을 할 수 있는데, 디폴트값이 사라져버렸으니 새로운 전역 환경변수가 등장할 때마다 config.pl 을 비교하며 신경써줘야 하는군요. : 고로 요약하면, ** wiki_ext.pl 은 잠시 미루고 (이쪽에는 매크로만 들어갈 테니 이왕이면 매크로 말고도 집어넣으면 좋을 게 있는지 생각해 보도록 하죠) ** config 화일 이름을 붙박이로 두고 (config.pl) ** HashKey, DataDir 은 config 화일 쪽에서 지정하도록 하고 ** 예전처럼 config 화일의 내용을 wiki.pl 에도 그대로 넣어서, 사용자가 버전업을 할 때는 자신이 사용하던 이전 버전의 config.pl 만 보존하면 되도록 함. (새로 생긴 환경변수를 디폴트 이외의 값으로 주고 싶을 때만 config.pl 을 수정하면 되도록) : 정도가 되겠습니다. 어떻게 생각하시는지 다른 분들의 의견을 부탁드릴께요.
: 흐미.. 위 글을 쓴 후에 오리지널은 어찌하나 봤더니만 1.0 에서 ConfigFile 변수를 추가했군요. UseMod:WikiPatches/MoveConfigFile 등을 보면 이유도 동일하고, 구성도 거의 동일하네요.. Adams 씨가 우리 ext 버전을 베낀 게 아닐까 합니다 ^^;;;
:지금 wiki.pl을 여러개로 쪼개서 사용중인데, 좋은지 어떤지 알 수가 없네요. 부하는 약간 줄은거 같은데..ㅡ.,ㅡ; \\ 여기저기 중복으로 사용하는 함수가 많아서 전체적으로 일관성있게 쪼개는게 쉽지 않을거 같던데요.. \\ 쪼갠 놈들은 전부 하부폴더로 몰아놨는데, 신기한게 요놈들이 디렉토리 경로를 본체의 경로를 따랐던거 같네요. 원래그런건가.. -.-a;;
:: 어떻게 쪼개냐에 따라 다르겠지만, 예를 들어 매크로 치환은 쪼개봐도 어차피 매번 불려야 할 거고, diff 나 history 역시 기본 출력과 연결되어 있고, 그럼 남은 것은 편집 모드 정도인데, 뭐 어쨌거나 제가 아쉽지 않은 부분은 관심 밖이라서요. :-)
http://www.oddmuse.org/cgi-bin/oddmuse-en?Modules UseMod 를 받아서 수정해서 만든 OddMuse 라는 위키가 있더군요. 이 위키에서 모듈을 구현한 방법입니다. 펄에서 이렇게 간단하고 깔끔하게 함수 바꾸기가 되는줄 미처 몰랐습니다. OddMuse 에서 모듈을 호출하는 방법만 따와서 넣어주면 UseMod 에서도 모듈을 지원할 수 있을 것 같습니다.
어제 저녁에 갑자기 떠오른 생각에, 새벽에 일어나 저 OddMuse 의 소스를 받아 잠깐 확인하고 간단한 테스트 프로그램으로 시험해본게 있는데... 다음과 같은 방법으로 매크로들을 죄다 모듈로 분리해낼까 합니다. * 위키설치 디렉토리 아래 macro 라는 이름의 디렉토리를 두고, * macro 디렉토리 아래 각 매크로를 하나씩 pl 또는 pm (확장자는 어느쪽이든 상관없을 듯) 파일로 둔다. * 각 매크로는 다음과 같은 식으로 작성한다. mysign 매크로의 경우 {{{#!vim perl # mysign.pl 파일 - 파일 이름과 매크로 이름이 동일하도록 작성 push(@MyMacros, "mysign"); # OddMuse 의 경우 \&mysign 과 같이 함수의 주소를 줬는데, 덮어쓰기를 위해서 이름을 줘야 할 듯. sub mysign { ($txt) = @_; $txt =~ s/\&__LT__;mysign\(([^,]+),(\d+-\d+-\d+ \d+:\d+.*)\)\&__GT__;/&MacroMySign($1, $2)/gei; # sub MacroSubst 에 있는 치환부 return $txt; } sub MacroMySign { # 구체적인 치환 루틴 ... } }}} * 다음, wiki.pl 쪽에서은 일단 각 파일을 한번씩 주욱 읽는다. (하나 읽고 실행하고 다음 거 읽고...라는 식으로 하면 안 됨. 덮어씌우기를 위해서) {{{#!vim perl foreach $file (glob("./macro/*.pm")) { # 이렇게 하면 간단히 디렉토리 스캔이 되더군요. readdir 같은 거 필요없이 do "$file"; } # 이러면 @MyMacros 배열이 완성 # 이것을 해쉬의 키로 넣고, keys 로 다시 키를 뽑아내어서 중복된 값을 하나만 남게 만든 후 # 하나씩 실행한다. foreach $mymacro (@MyMacros) { $txt = &$mymacro($txt); # 함수 이름을 이렇게 쉽게 동적으로 줄 수 있다니.. -_-; } }}} * 만일 사용자가 mysign 매크로의 출력을 자신만의 방식으로 바꾸고 싶다면 ** 다른 파일을 만들어 macro 디렉토리에 넣고 ** 위의 mysign 또는 MacroMySign 을 그 파일 안에서 다시 작성하되 ** 파일 이름은 위와 다르게 (뭐든 상관없으나, 저 mysign.pm 보다 '''나중에''' 읽히면 됨. mysign_ext.pm 등) 하면 됨. ** 아예 mysign.pm 을 삭제해 버려도 될 것임. 이렇게 하면 장점은 * 새로운 매크로를 만들어 배포하거나, 남이 만든 매크로를 자신의 홈에 추가하는 게 쉽다. 매크로 파일 하나만 받아서 넣어주면 된다. * usemod ext 버전을 새로 받아올 때도 내가 따로 만든 매크로를 다시 작성해 줄 필요가 없다. 별개의 이름으로 매크로 파일을 만들어 넣어두면 된다. * 안 쓰는 매크로들을 삭제해 버리면 읽어들이는 코드의 양이 적어진다. 근데 반대로 전부 읽을 경우 하나의 파일을 읽을 때보다 더 오버헤드가 있을 것 같은데... 일반적으로는 모든 매크로를 다 넣어 두고 쓸 것 같으니 오히려 단점일 수도 있겠네요. 가장 좋은 것은 "페이지 안에 매크로가 있을 때 그 매크로 함수만 읽고 부른다"인데, 위처럼 wiki.pl 에 매크로 이름을 명시하지 않게 하면서 이게 가능할지 모르겠습니다. 단점 또는 문제점은 * 다른 매크로의 함수를 재사용하는 매크로(만들 때는 앗싸 하면서 만들었는데 -_-;)는 어찌하나... 함수를 중복 작성해서 매크로끼리의 독립성을 주는 게 좋을지 그냥 "이 매크로는 무슨 매크로가 있어야 함"처럼 하는 게 좋은지 * 더 큰 문제는 wiki.pl 의 다른 부분에서 매크로의 함수를 쓰는 경우 (있었던 것 같은데) ... 이런 매크로는 그냥 wiki.pl 에 놔 둘랍니다. * 편집 도움말의 매크로 항목이 실제와 전혀 맞지 않게 될 수 있다. (매크로 파일에 도움말도 같이 넣어서 도움말을 동적으로 생성할 수 있을런지 테스트해볼 생각) * 말은 이렇게 했지만 진짜로 잘 될지 자신할 수 없음 -_-;;; :자주사용하는 매크로는 그냥 본체에 놔두면 되지 않을까요? ==a
:: 누가 무엇을 자주 사용하는지 어떻게 알죠? 매크로 사용빈도 설문조사를 할 수도 없고...
:::아... 사용빈도가 아니라. 중복사용 안하는거만 골라서 떼는 거죠.. 제가 잘못썼네요.
:::: 일단 되든 안 되는 해보자는 생각으로 매크로들을 죄다 분리해내고 있는 중입니다. 막노동이군요. -3-;;
::::: 헤헤헤~ 화이팅~! :D
== # HTML::Template == [http://html-template.sourceforge.net/ HTML::Template] 이라는 것이 있더군요. 소스에서 HTML 코드를 분리해낼 수 있다는 것은 마음에 드는데... 혹시 관심을 가지실까 싶어 링크만 올려둡니다.
== # 잦은 변경 == 예전에도 말씀 드렸던 문제인 것 같기는 한데. Jof:음악과저작권법 페이지가 생긴건 아실겁니다. 문제는 이 페이지가 생긴지 이틀만에 70번의 변경이 이루어지면서; keep 파일이 2메가에 가까워지는 바람에 서버가 새 변경을 하던 중 뻗어버렸습니다. 그런 이유로 lock 이 남아서 위키 전체가 맛이 가는 현상이. -_-;;; 사실 이런 일이 처음이 아니라 Jof:주절주절 같은 경우는 옛날 버전 보존 기간을 2일로 줄여놓고, 양이 많아지면 별도의 페이지로 분리를 하고 있습니다. lock과 keep 파일을 지워주는 cgi를 만들고 문제가 생기면 직접 실행을 하기도 하고요. 하지만 2일도 못 버티면 어떻게 해야 할지... OTL 저장된 keep 파일의 사이즈나 그 안의 버전 수에 따라서 같이 날리던가 해야 할 것 같은데... 뭔가 좋은 방법이 없을까요? ---- 에... 간만에 이 페이지가 수정된걸 보니 생각이 나서... \\ 조프위키는 고쳤습니다. * keep 파일의 구조는 그대로 둔다. * 단, 페이지 내용은 분리를 한다. 형식은 'keep 파일이름.revision 번호' 덕분에 주절주절이라거나 뭔가 이슈가 되는 페이지에서 페이지 변경이 마구 일어나도 버텨주고 있습니다. 다만 구현을 끝내기 위해서는 페이지 이름 변경이라거나 삭제를 할 때 저 내용물 파일도 같이 처리를 해줘야 하는데, 제대로 못하고 있어서 공개를 못하고 있습니다.
== # 한글 페이지 파일들을 첫글자에 따라 분류해서 저장 == 현재 영문 페이지 파일(*.db)들은 첫글자에 따라서 A, B, C, .. 등의 디렉토리에 나뉘어서 저장이 되는데, 한글 페이지들은 죄다 other 디렉토리에 저장이 됩니다. 페이지 수가 수백 이상의 단위가 되면 읽을 때 오버헤드가 떨어지는 것 같은데, 한글 페이지들도 첫글자에 따라 가, 나, 다, ... 등으로 디렉토리를 나눠서 저장하는 게 좋을까요? 잠깐 테스트해 봤는데 구현하는 것은 손쉽게 될 것 같습니다. 그런데 이 경우 문제는, 이렇게 고쳐진 직후에 기존에 있는 other 밑에 있는 한글 페이지들을 일괄적으로 새로운 분류에 맞춰 옮겨 주어야 하고, 상위페이지들은 이렇게 나눌 수 있지만 [[하위페이지]]는 어쨌거나 상위페이지 이름의 디렉토리 안에 저장되어 있으므로 적용이 되지 않는다는 겁니다. 당장 GyparkWiki만 해도, 가장 페이지 파일이 많은 디렉토리는 other가 아니라 D/Diary 네요.
|| 디렉토리 || 전체 파일 수 || 상위 페이지 파일 수 || 하위 페이지 파일 수 || || A || 3 || 3 || 0 || || B || 4 || 4 || 0 || || C || 13 || 11 || 2 || || D || 403 || 10 || '''393''' || || E || 4 || 4 || 0 || || F || 1 || 1 || 0 || || G || 12 || 7 || 5 || || H || 3 || 3 || 0 || || I || 5 || 5 || 0 || || J || 3 || 3 || 0 || || K || 4 || 4 || 0 || || L || 3 || 3 || 0 || || M || 15 || 11 || 4 || || N || 7 || 6 || 1 || || O || 2 || 2 || 0 || || P || 30 || 12 || 18 || || Q || 0 || 0 || 0 || || R || 14 || 10 || 4 || || S || 200 || 14 || '''186''' || || T || 6 || 6 || 0 || || U || 191 || 18 || '''173''' || || V || 6 || 6 || 0 || || W || 14 || 13 || 1 || || X || 1 || 1 || 0 || || Y || 0 || 0 || 0 || || Z || 4 || 4 || 0 || || OTHER || 336 || '''218''' || 118 || || Total || 1284 || 379 || 905 ||
== # utf-8 트랙백 받기 == action_trackback에서. {{{#!vim perl # 일단 GetParam 해준 다음에 넘어온게 utf-8인듯 하면 변환 if ($ENV{'CONTENT_TYPE'} and ($ENV{'CONTENT_TYPE'} =~ m/utf-8/)) { # url은 안 해도 될 것 같음. $title = encode_korean($title, 'utf-8', 'euc-kr'); $blog_name = encode_korean($blog_name, 'utf-8', 'euc-kr'); $excerpt = encode_korean($excerpt, 'utf-8', 'euc-kr'); } }}} 저기 뒤에 i가 붙어야 할지도요. UTF-8로 올 수도 있으니. \\ 사실은 charset까지 검사해서 어쩌구 저쩌구 해줘야겠지만 구찮아서... encode_korean이 gyparkwiki에 있는지 모르겠네요. 제 소스에 있는 인코딩 함수는 이렇습니다. {{{#!vim perl sub encode_korean { my ($str, $from, $to) = @_; eval { require Encode; }; unless($@) { $str = Encode::encode($to, Encode::decode($from, $str)); } else { eval { require Text::Iconv; }; unless($@) { my $converter = Text::Iconv->new($from, $to); $str = $converter->convert($str); } } return $str; } }}} 어디서 난건지 모르겠네요. 테스트는 egloos에서 조프위키로만 했습니다.
== # WikiPatches/RawMode == * http://www.usemod.org/cgi-bin/wiki.pl?WikiPatches/RawMode 주로 외부 프로그램과의 연동을 위해, Wiki 내용을 raw mode로 export하는 patch입니다. 협업시스템의 일종인 trac은 XML-RPC를 구현해서 Emacs에서 썩 훌륭하게 wiki 내용을 편집할 수 있는 기능을 제공합니다.(꼭 Emacs뿐만 아니라 프로그램을 통해 wiki 내용을 편집할 수 있도록 해 줍니다. Authorization과 결합되지 않으면 Spam의 좋은 표적이 될 수도 있겠죠). WikiPatches/RawMode를 사용하는 예를 http://www.emacswiki.org/cgi-bin/wiki/SimpleWikiEditMode 에서 볼 수 있습니다. Emacs내에서 web browsing이 필요없이 페이지를 갱신할 수 있습니다. 편집기를 벗어나기 싫어하는 사람에게는 유용하게 사용할 수 있습니다.
---- [[위키위키분류]]
UseModWiki소스수정/사용자의견
페이지로 돌아가기 |
다른 수정본 보기