UseModWiki소스수정의 하위페이지입니다.
UseModWiki 를 사용하시는 분들 중에 자신이 직접 수정한 부분이 있거나, 여기에서 언급하지 않은 다른 수정 사항에 대해 아는 바가 있다면 이곳에 적어주시면 감사하겠습니다. 또는 이 곳에서 언급한 수정 사항에 대한 의견도 환영합니다.
패치 정보에 대해 적어 주실 때에는 최대한 UseModWiki소스수정에서처럼 원본코드와 수정한코드, 수정한 이유, 부작용 등의 기타사항 등을 같이 적어주시고, 그 수정사항을 반영한 홈페이지의 주소 등을 언급해 주시면 감사하겠습니다.
이모티콘 :|
sub EmoticonSubst 함수를 보시면 :|를 위한 그림경로가 변수로 지정은 되어있는데, 사용을 하지 않고 있습니다. 아마도 | 이거 충돌 때문인거 같은데, 별 문제 없을거라 생각하고 살렸습니다.(그러나 어떤문제가 있어서 이것을 막아논건지 전혀 짐작이 안가 장담은 못합니다.. ^^)
sub EmoticonSubst {
....
if ($UseEmoticon) {
....
$txt =~ s/\s\:[-]*\|/$e1/g; ##추가
}
return $txt;
}
이모티콘 도움말에 :| 추가
이모티콘 도움말 루틴을 찾아서 (;-)이걸로 찾으세요)
* :-| <nowiki>:-| :|</nowiki> 추가.
여기서 끝나는게 아니고, 이모티콘 루틴의
# $text = q|
# ....
# |;
윗내용을 아래처럼 바꿉니다.
바꾸는 이유는 q| ... |의 "|" 이것과 :-|의 "|" 이것이 충돌하기 때문. qq()괄호도 오류생김.
$text = "
....
";
아 그리고... 역링크 관련 루틴들은 지금도 미흡하게나마 됩니다. 원래 코드에서 cgi 파라메터를 지원했기 때문에.. action=links 뒤에 인자를 붙여서 효과를 낼 수 있습니다. 물론 수동으로 주소 입릭창에 적어주어야 하지요. 필요하다면 해당 액션에 대한 링크를 화면 어딘가에 배치시킬 수 있겠군요. GetFullLinkList 함수 소스를 보시면 사용 가능한 옵션들이 있습니다. 주로 값은 0,1,2 등을 할당하게 되어 있고요. 웬만큼 요긴한 것들은 이미 만들어져 있더군요.
예:
wiki.pl?action=links 이게 상단의 링크 버튼을 눌렀을 때 나오는 화면이고
wiki.pl?action=links&reverse=페이지이름 특정 페이지의 역링크만 찾을 때
wiki.pl?action=links&exists=0 존재하지 않는 링크들만 찾을 때
등등등.. 두 가지 이상 옵션은 & 로 연결해서 적어주면 됩니다.
에구 죄송합니다. 지양님 diff찾아보면 있기 ㅤㄸㅒㅤ문에 알고 계신줄 알았거든요..^^; 원래 지양위키의 기능은 <sub>가 불리면 해당페이지의 하위목록을 보여주는 건데, <sub(페이지이름)> 요런식으로 상위페이지를 지정할 수 있게 약간 바꿨습니다. 이유는 오로지 미리보기에서 제대로 안나오는게 걸거치다는 것입니다. ;;;
subGetSubPageLink{
my ($id) = @_;
my$name = $id;
# $name =~ s/.*\//\//;$id =~ s|^/|$MainPage/|;
if ($FreeLinks) {
$id = &FreeToNormal($id);
$name =~ s/_//g;
}
return&ScriptLink($id, $name);
}
subMacroGetSubPageList{
my ($rootpage) = @_;
my (@pagelist);
@pagelist = &AllPagesList();
my$subpage;
my$result;
$DocID = $rootpageif($rootpagene"");
foreach$subpage (@pagelist) {
if ($subpage =~ m|$DocID/|) {
$result .= &GetSubPageLink($subpage);
$result .= "<br>"if($rootpageeq"");
}
}
return$result;
}
######## ↑여기까지 추가합니다. ############# ↓별표친 부분을 추가합니다. ######subMacroSubst{
....
$txt =~ s/\&__LT__;sub\(([^\n]+)\)\&__GT__;/&MacroGetSubPageList($1)/gei; ### ★☆★☆★☆★☆ 별표친부분
....
}
subDoEdit{
....
body += '< body>< form method="post" action="$ScriptName">';
# 아래부분 추가
body += '< input type="hidden" name="id" value="$id">';
# ★☆★☆★☆★☆별표별표별표별표별표별표★☆★☆★☆★☆# DoEdit 함수의 추가부분은 자바스크립이 들어가기때문에 #으로 된 주석을 반드시 삭제.
....
}
subDoPreview{
....
$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.
순전히 개인적인 목적입니다. --;;
만화책 전용이며, ISBN코드가 아니라 만화책 출간일자로 찾습니다. -_-a (굳이 COMIC으로 따로 떨군 이유입니다..;;)
조프님 사이트를 돌아다니다가 알게된 http://www.mani.co.kr 라는 사이트를 링크시켰습니다.
정규표현식을 잘 모르는 관계로 역시나 소스는 지저분합니다. :)
저는 준컴맹이라서 의견밖에 제시를 못하니 이해하시고... ^^
의외로 사람들이 이런 식으로 사용하곤 합니다.
대학1학년 때 서울로 올라오면서 본격적으로 WWF에 미치기 시작했었다. 제이크더스네이크와 밀리언달러맨, 브렛히트맨하트, 션마이클스, 오오…그리고…이름도 거룩한 얼티밋워리어여…군대생활의 공백을 넘어 다시금 나의 영웅이 된 인물은 물론 스톤콜드 스티브오스틴…그러나 언더테이커의 카리스마도 무척 좋아했었다. 개인적으로는 부활 이후 와일드씽 폭주족과 같은 설정은 그리 맘에 안든다. 더락…이 한인물하는 놈이야말로 WWF의 쇼맨쉽을 온몸에 달고다니던 훗가시의 왕자!…이젠 영화배우로서 링에는 모습을 안보이고있지만 우리는 다 안다. 조만간 다시 링으로 성큼성큼 걸어올라와서 로프 위에 올라서서는 관중들의 열광을 들이마시는 그 특유의 세러머니와 피플스 엘보우를 보여주리란걸…아! 또한가지, 물론 욕많이먹고있는것이긴 하지만 몇년전부터 수위를 높이고있는 에로틱 테마...하나같이 운동을 한건지 수술만 열심히 한건지 알길이 없는 여성레슬러나 레슬러들의 애인들을 둘러싼 에피소드들도 감칠맛을 더해가는 양념중에 양념^^ 이 나이에도 그 뻔한 쇼를 보면서 흥분하고 재밌어하는게 한심하게 느껴질 때는 내 주위에 나보다 더 광팬들인 선배들을 보면서 위안을 삼고는 한다.^^ WWF…이것이야말로 가장 미국적인 쌩쇼가 아닐는지…비판의 시각을 배제하고 보면 너무나 잘 만들어진 한편의 초대형 스포츠액션 성인시트콤이라고 할 수 있겠다. 케이블을 끊은 이후로 이것 역시 제대로 못보다보니 최근 소식에 뒤쳐졌었는데, 근래에 WCW와 통합하여 WWE로 새롭게 시작을 한듯 보인다. 왼편의 사진은 WWF입장권이라고 한다 쿠오오...
크아앗...1월23일 한국에서 드디어 WWE Far East Tour 가 온단다...꼭 보러가야되는데...ㅠ.ㅠ
한편으론 반미감정에 휩싸여있는 이 나라에 미제자본주의 쇼비즈의 상징물이 하필이면 요 시점에 온다니...
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
]}||
즉 기존의 텍스트포매팅들이 그대로 먹게하되 앞뒤에 태그를 달아 하나의 셀로 인식하게 하는거죠. 어려울까요? ^^
생각난김에 하나 더 써봅니다. 이건 좀 허황된 것이 아닌가 싶은데...
위키에서는 이미지 링크를 많이 하게 됩니다. 그러다보면 그쪽 서버 사정으로 이미지가 일시적으로 돌아가시거나 아님 아주 날아가버리는 일이 종종 생깁니다. 아주 짜증나는 일이 되죠. 특히 중요한 이미지일지도 모르는 것일 경우에는요. < mysign >처럼 저장할때 돌아가는 태그를 하나 만들면 어떨까 합니다. 예를들어
나쁘지 않은 생각 같습니다. (바로 위에 적으신 것보다는 이쪽이 덜 허황된 것 같은 느낌인데요 ^^) 별도의 유틸리티 wget 을 호출하게 하면 될 것 같은데, 그것을 쓰지 않고 perl 만으로 하려면 어떻게 해야 될 지 모르겠네요. 그리고, 남이 임의로 페이지 하나에 저런 태그를 마구잡이로 넣어서 하드를 채워버리는 것을 막아야겠군요.
될만하다니 다행이군요. 파일 업로드 기능은 당연히 필요합니다. 하지만 저건 좀 다르죠, 일종의 백업이니까요. 뭐 임시적으로 사람들에게 의미있는 것들이면 그냥 링크만 해도 되겠지만 가끔 날아가지 말았으면 하는 이미지들이 있답니다. 저같은 경우는 음반 재킷이나 책 표지같은게 그렇구요.
저작권이야 뭐 외면하는거죠. ^^a 파일이름이 겹치면 __따위를 붙여줘야겠네용.
1번은 시도해 보겠습니다. 사실 작년부터 탐을 내던 기능인데, DoRc 나 GetRcHtml 을 그대로 재사용하려고 했더니만 원체 그런 고려 없이 만들어져 있어서 뜯어고칠 곳이 많다고 관뒀었습니다만.. 저 역시 있었으면 하는 기능인터라... 2번은... 글쎄요, 환경설정에 있는 해당 항목을 편집창에 똑같이 달아두면 안 되려나요? 아니면 입력하는 와중에, 현재 입력한 내용을 보존하면서 크기를 자유롭게 조절하는 것을 바라시는 거라면..그런 게 가능한지조차 저는 모르겠습니다.
2번은 DHTML과 자바 스크립트를... 미친듯이 사용하면 가능하긴 합니다. [여기]에서 [WindowScript]라는 놈의 데모를 보세요. 이건 DIV 태그에 대해서 동작하는 것 같기는 하지만, TEXTAREA에 대해서도 비슷한 방식으로 크기 조절이 가능할 것 같습니다. (TEXTAREA의 크기를 바꾸는 데모도 본 것 같은데 어디서 봤는지 기억이 안나는군요.) 아니면 [이것]처럼 입력창의 크기를 브라우저의 크기에 따라서 자동으로 바뀌도록 하는 것도 괜찮은 방법이 될 지 모르겠네요.
관심있는 분께서는 [여기]를 참고하세요. 저는 논의된 것들중에서 아래에 제시된 것을 적용시켰습니다.
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:
subCommonMarkup{
...
if ($doLines) {
...
s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6})(.*?)\^/<FONT COLOR="$1">$2<\/FONT>/g;
지금 페이지 숨기기 기능을 쓰고있습니다만 버그는 잘 못찾겠구요. ^^ 몇가지 부가적 기능이 필요해 보입니다.
숨겨진 페이지는 외부 링크일 때 '새창으로 띄우기'와 같은 조그만 아이콘이 달려있거나 마우스 오버시 툴팁으로 알려주어야 할 거 같아 보이구요. 안그러면 사람들이 일일이 눌러봐야지 그 링크가 잠겼는지 안잠겼는지 알 수 있으니까, 많아질경우 거부감을 느끼게 될 듯 하네요.
이건 사전기능에서도 마찬가지던가요.
페이지 숨김 기능은 조금만 확장하면 폐쇄적으로 사용할 수 있을듯 합니다. 일반 게시판에서처럼 로그인해야 볼 수 있는 그런 형태가 되는건가요. 퍼미션이란 참 복잡한 문제입니다.
페이지 숨김과 더불어 드는 생각입니다.
노스목같은 경우는 누구나 페이지 삭제와 이름 변경이 가능하죠. 제가 보기에도 장기적으로 그렇게 가는 것이 맞다고 봅니다. 여러 사람이 동시에 운영자가 되고 대신 그 내역이 공개된 장소에 나오면 되고, 삭제된 페이지를 복구할 수 있어야겠지요. 페이지 이름 바꾸기는 복구가 가능한데 페이지 이름 돌리기는 복구가 불가능할 수도 있겠네요. 페이지 이름 돌리기는 명령 건 다음 승인하는 식으로 가야하나...허허...-_-a
고려바위에서 여러 사람에게 운영자 권한을 주고 페이지 숨김기능을 이용하게 하려하니 이런 문제가 발생하더라구요. 그들이 임의로 페이지를 지우거나 이름을 변경해도 제가 알 수 없다는 문제요.
사전은 조프님이 그런 아이콘이 나오는 게 싫다고 만드신 매크로입니다. :-) 아이콘이 필요하다면 매크로 대신 인터위키를 쓰는 것도 괜찮겠네요.
NoSmoke 같은 경우..는 저번에도 Bab2님과 페이지 삭제 권한 얘기 하면서 제가 했던 말입니다만.. 칼을 쥐어주고 남용을 걱정할 바에는 아예 안 쥐어주는 게 낫다는 생각입니다. 페이지 삭제를 원한다면 내용을 지우고 태그만 붙여넣고, 이름바꾸기가 합의가 된다면 한 페이지는 내용을 지우고 다른 페이지를 만든 후에 관리자에게 부탁을 하면 그것으로 충분하지 않을까요?
아...네 뭐 저도 주인장님 말씀에 동의해요 :) 지금 운영도 그렇게 가고있구요.
제가 그런 걱정을 하게 된 이유는 다음과 같습니다.
고려바위 사람들이 내부적으로만 보고싶어하는 내용들이 있다.
그것을 위해선 몇몇 사람들에게 운영자 권한을 주어야 한다.
그들에게 운영자권한을 주는 것까지는 좋은데 페이지 수정/삭제 등의 현황을 관리자인 거북이가 알 길이 없다.
뭐 이런거거든요. 하지만 이게 필요하다고 해서 쓱 만들자 이런 의견은 아니구요. 좀 더 크게 봐야 할 것 같습니다. DB를 쓰지 않는다는 한계와 RC관련 문제 등 뭐 여러가지 유즈모드위키가 가지고 있던 문제들까지 고려해야겠지요. 나중에요. ^^
숨겨진 페이지로 가는 링크를 특별히 표시한다...는 것은, 매번 페이지 하나를 출력할 때마다 그 페이지 내의 모든 링크에 대해 숨겨졌는지 아닌지를 미리 조사해야 된다는 것을 의미합니다. 뭐 한 페이지에 링크가 수백개씩 되는 것은 아니겠습니다만... index 나 rc 화면하고는 사이트 전체적으로 오버헤드의 차원이 달라지지요. (실제 조사하는 오버헤드가 그렇게 크지 않기 때문에 규모의 차이는 별로 없을지 모르겠습니다만) 한 번 시도는 해 보겠습니다. "숨겨져있음"을 의미하는 작은 아이콘 하나 만들어 주시면 감사히 받겠습니다. (아이콘을 붙일지 아니면 링크를 별도의 class 로 걸지를 먼저 결정해야겠네요)
숨겨진 페이지를 여러 사용자가 보게끔 하려면 새로운 사용자 그룹을 하나 더 만드는게 제일 편할겁니다. 그리고,
아예 링크자체를 보이게 하지 않으려면 GetAnchoredPageLinkOrEditLink (이게 맞던가..ㅡ.ㅡa)함수를 수정해주시면 될겁니다.
(실제로 폐인월드는 그렇게 수정해서 쓰고 있습니다만.. 지금은 숨겨진 페이지가 한개도 없는지라..==a)
아 페이지 삭제는 RC에 뜨는군요. 페이지 이름 바꾸기나 페이지 경로 돌리기는 막을 방법이 없긴 하지만 그래도 이정도면 몇몇 사람들과는 운영자권한을 공유해도 될 거 같아요. :)
오늘 몇가지 매크로를 사용해보았습니다. 정말 세세하게 짜여진 프로그램이라는 생각이 들어 감동했습니다 :) 몇가지 버그를 찾은것 같구요. 그러고보니 지난 회사의 한 개발자가 버그라는 말을 정말 싫어했던 기억이 나는군요. 단지 문제가 좀 있다고 표현해달라고 했어요. ^^ 개선했으면 하는 점도 함께 적어봅니다.
그리고 페이지가 나열되는 결과는 가능하면 페이지 목록보기처럼 나오는게 어떨까 하는 생각이 듭니다.
실험은 위키낙서장 에서 진행했습니다.
myinterest
mostpopular처럼 몇개만 본다라는 규정이 필요
myrecentchanges역할도 필요
includeday
매크로 다음에 표같은 것이 안먹고 페이지 이름을 생략해도 안먹음
입력
|| <includeday(-1)> || <includeday(위키낙서장,0)> || <includeday(위키낙서장,+1)> ||
출력
|| <includeday(-1)> || <includeday(위키낙서장,0)> || DeleteThisPage ||
오랜만에 똑똑...;;;
공부는 잘 되시나요? 결혼은 언제쯤..? ^^a \\
에에.. 그니깐.. ㅡㅡa
현재, Bab2라는 페이지가 여러 위키사이트에 동일한 이름으로 존재하는데, 이것을 예를 들어 Gypark에 있는 Bab2페이지만 건드리면 다른 사이트의 Bab2라는 페이지도 동일하게 수정이 되게끔 할만한 건덕지가 있을려나요..ㅡ.ㅡa 없을려냐냐... ㅡ.ㅡ;;;
수고하세요 ^^
서버 자체에 있는 cgi 가 만들어낸 것이 아닌 외부에서 날아온 POST 요청에 대해 응답을 할 수 있는건가요? 오에카키를 넣다가 타인의 계정에 그림을 추가할 수 있는 문제가 생길 것 같아 테스트했더니만 에러가 나더라고요. 그래서 불가능한가보다 하고 있었습니다만, 이 경우와는 다른 상황인지도 모르겠네요.
OddMuse 를 참고하여... 거의 사용하지 않는 옵션, 또는 반대로 거의 항상 사용하는 옵션들은 옵션에서 제거해 버리고 소스를 간단히 고치는 게 좋을 것 같습니다.. 다만 점점 더 오리지널 UseModWiki 와 멀어지면 나중에 대책이 없어지는 사태가 발생할지도...
일단 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에 최소 사양으로 구현해두면 되고요.
### wiki.pl 소스# 이 이하의 함수는 wiki_ext.pl 에서 구현할 수 있는 함수의 원형입니다.subInitVariables
{
$HashKey = "salt";
$DataDir = "data";
$ConfigFile = "config.pl";
}
subExtMacroSubst
{
$txt = @_;
return$txt;
}
require"wiki_ext.pl";
&DoWiki~~~;
### wiki.pl 끝.### wiki_ext.pl 소스return1;
뭐 이런 식이랄까요?
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 은 잠시 미루고 (이쪽에는 매크로만 들어갈 테니 이왕이면 매크로 말고도 집어넣으면 좋을 게 있는지 생각해 보도록 하죠)
흐미.. 위 글을 쓴 후에 오리지널은 어찌하나 봤더니만 1.0 에서 ConfigFile 변수를 추가했군요. WikiPatches/MoveConfigFile 등을 보면 이유도 동일하고, 구성도 거의 동일하네요.. Adams 씨가 우리 ext 버전을 베낀 게 아닐까 합니다 ^^;;;
지금 wiki.pl을 여러개로 쪼개서 사용중인데, 좋은지 어떤지 알 수가 없네요. 부하는 약간 줄은거 같은데..ㅡ.,ㅡ;
여기저기 중복으로 사용하는 함수가 많아서 전체적으로 일관성있게 쪼개는게 쉽지 않을거 같던데요..
쪼갠 놈들은 전부 하부폴더로 몰아놨는데, 신기한게 요놈들이 디렉토리 경로를 본체의 경로를 따랐던거 같네요. 원래그런건가.. -.-a;;
http://www.oddmuse.org/cgi-bin/oddmuse-en?ModulesUseMod 를 받아서 수정해서 만든 OddMuse 라는 위키가 있더군요. 이 위키에서 모듈을 구현한 방법입니다. 펄에서 이렇게 간단하고 깔끔하게 함수 바꾸기가 되는줄 미처 몰랐습니다. OddMuse 에서 모듈을 호출하는 방법만 따와서 넣어주면 UseMod 에서도 모듈을 지원할 수 있을 것 같습니다.
어제 저녁에 갑자기 떠오른 생각에, 새벽에 일어나 저 OddMuse 의 소스를 받아 잠깐 확인하고 간단한 테스트 프로그램으로 시험해본게 있는데... 다음과 같은 방법으로 매크로들을 죄다 모듈로 분리해낼까 합니다.
위키설치 디렉토리 아래 macro 라는 이름의 디렉토리를 두고,
macro 디렉토리 아래 각 매크로를 하나씩 pl 또는 pm (확장자는 어느쪽이든 상관없을 듯) 파일로 둔다.
각 매크로는 다음과 같은 식으로 작성한다. mysign 매크로의 경우
# mysign.pl 파일 - 파일 이름과 매크로 이름이 동일하도록 작성push(@MyMacros, "mysign"); # OddMuse 의 경우 \&mysign 과 같이 함수의 주소를 줬는데, 덮어쓰기를 위해서 이름을 줘야 할 듯. submysign{
($txt) = @_;
$txt =~ s/\&__LT__;mysign\(([^,]+),(\d+-\d+-\d+\d+:\d+.*)\)\&__GT__;/&MacroMySign($1, $2)/gei; # sub MacroSubst 에 있는 치환부return$txt;
}
subMacroMySign{ # 구체적인 치환 루틴
...
}
다음, wiki.pl 쪽에서은 일단 각 파일을 한번씩 주욱 읽는다. (하나 읽고 실행하고 다음 거 읽고...라는 식으로 하면 안 됨. 덮어씌우기를 위해서)
foreach$file (glob("./macro/*.pm")) { # 이렇게 하면 간단히 디렉토리 스캔이 되더군요. readdir 같은 거 필요없이do"$file";
}
# 이러면 @MyMacros 배열이 완성# 이것을 해쉬의 키로 넣고, keys 로 다시 키를 뽑아내어서 중복된 값을 하나만 남게 만든 후# 하나씩 실행한다.foreach$mymacro (@MyMacros) {
$txt = &$mymacro($txt); # 함수 이름을 이렇게 쉽게 동적으로 줄 수 있다니.. -_-;
}
파일 이름은 위와 다르게 (뭐든 상관없으나, 저 mysign.pm 보다 나중에 읽히면 됨. mysign_ext.pm 등) 하면 됨.
아예 mysign.pm 을 삭제해 버려도 될 것임.
이렇게 하면 장점은
새로운 매크로를 만들어 배포하거나, 남이 만든 매크로를 자신의 홈에 추가하는 게 쉽다. 매크로 파일 하나만 받아서 넣어주면 된다.
usemod ext 버전을 새로 받아올 때도 내가 따로 만든 매크로를 다시 작성해 줄 필요가 없다. 별개의 이름으로 매크로 파일을 만들어 넣어두면 된다.
안 쓰는 매크로들을 삭제해 버리면 읽어들이는 코드의 양이 적어진다. 근데 반대로 전부 읽을 경우 하나의 파일을 읽을 때보다 더 오버헤드가 있을 것 같은데... 일반적으로는 모든 매크로를 다 넣어 두고 쓸 것 같으니 오히려 단점일 수도 있겠네요. 가장 좋은 것은 "페이지 안에 매크로가 있을 때 그 매크로 함수만 읽고 부른다"인데, 위처럼 wiki.pl 에 매크로 이름을 명시하지 않게 하면서 이게 가능할지 모르겠습니다.
단점 또는 문제점은
다른 매크로의 함수를 재사용하는 매크로(만들 때는 앗싸 하면서 만들었는데 -_-;)는 어찌하나... 함수를 중복 작성해서 매크로끼리의 독립성을 주는 게 좋을지 그냥 "이 매크로는 무슨 매크로가 있어야 함"처럼 하는 게 좋은지
더 큰 문제는 wiki.pl 의 다른 부분에서 매크로의 함수를 쓰는 경우 (있었던 것 같은데) ... 이런 매크로는 그냥 wiki.pl 에 놔 둘랍니다.
편집 도움말의 매크로 항목이 실제와 전혀 맞지 않게 될 수 있다. (매크로 파일에 도움말도 같이 넣어서 도움말을 동적으로 생성할 수 있을런지 테스트해볼 생각)
예전에도 말씀 드렸던 문제인 것 같기는 한데.
음악과저작권법 페이지가 생긴건 아실겁니다. 문제는 이 페이지가 생긴지 이틀만에 70번의 변경이 이루어지면서; keep 파일이 2메가에 가까워지는 바람에 서버가 새 변경을 하던 중 뻗어버렸습니다. 그런 이유로 lock 이 남아서 위키 전체가 맛이 가는 현상이. -_-;;;
사실 이런 일이 처음이 아니라 주절주절 같은 경우는 옛날 버전 보존 기간을 2일로 줄여놓고, 양이 많아지면 별도의 페이지로 분리를 하고 있습니다. lock과 keep 파일을 지워주는 cgi를 만들고 문제가 생기면 직접 실행을 하기도 하고요. 하지만 2일도 못 버티면 어떻게 해야 할지... OTL
저장된 keep 파일의 사이즈나 그 안의 버전 수에 따라서 같이 날리던가 해야 할 것 같은데... 뭔가 좋은 방법이 없을까요?
에... 간만에 이 페이지가 수정된걸 보니 생각이 나서...
조프위키는 고쳤습니다.
keep 파일의 구조는 그대로 둔다.
단, 페이지 내용은 분리를 한다. 형식은 'keep 파일이름.revision 번호'
덕분에 주절주절이라거나 뭔가 이슈가 되는 페이지에서 페이지 변경이 마구 일어나도 버텨주고 있습니다.
다만 구현을 끝내기 위해서는 페이지 이름 변경이라거나 삭제를 할 때 저 내용물 파일도 같이 처리를 해줘야 하는데, 제대로 못하고 있어서 공개를 못하고 있습니다.
현재 영문 페이지 파일(*.db)들은 첫글자에 따라서 A, B, C, .. 등의 디렉토리에 나뉘어서 저장이 되는데, 한글 페이지들은 죄다 other 디렉토리에 저장이 됩니다. 페이지 수가 수백 이상의 단위가 되면 읽을 때 오버헤드가 떨어지는 것 같은데, 한글 페이지들도 첫글자에 따라 가, 나, 다, ... 등으로 디렉토리를 나눠서 저장하는 게 좋을까요?
잠깐 테스트해 봤는데 구현하는 것은 손쉽게 될 것 같습니다. 그런데 이 경우 문제는, 이렇게 고쳐진 직후에 기존에 있는 other 밑에 있는 한글 페이지들을 일괄적으로 새로운 분류에 맞춰 옮겨 주어야 하고, 상위페이지들은 이렇게 나눌 수 있지만 하위페이지는 어쨌거나 상위페이지 이름의 디렉토리 안에 저장되어 있으므로 적용이 되지 않는다는 겁니다. 당장 GyparkWiki만 해도, 가장 페이지 파일이 많은 디렉토리는 other가 아니라 D/Diary 네요.
# 일단 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에 있는지 모르겠네요. 제 소스에 있는 인코딩 함수는 이렇습니다.
주로 외부 프로그램과의 연동을 위해, 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이 필요없이 페이지를 갱신할 수 있습니다. 편집기를 벗어나기 싫어하는 사람에게는 유용하게 사용할 수 있습니다.