You have an ability to sense and know higher truth.
SpringNote › Release/FindPage › MacOS › MoniWiki/BenchMark › HelpOnPageDeletion › MoniWikiIdeas
Separating Content from Support Files ¶
I like the way that MoinMoin now separates those pages specific to the particular wiki from the standard files that provide support and instruction for the wiki user, plus, the easy way that help files are now just a click away. JonathanSmith 2005-01-29
두 단어 이상 검색 ¶
통상 1단어 검색은 자유로운데 2단어 이상 검색할때 google등에서 사용하는 것과 같이
여러단어를 나열하면 and 검색을 하여 보여주는 매크로등이 있었으면 합니다.
좋은방법이 없을까요. --04년 3월 25일 김기상
MoniWikiBlog
BloggerAPI지원 ¶
MoniWikiBlog에
BloggerAPI지원을 추가해보았습니다. 아직 문제가 많이 있고 구현안된것도 많지만, 일단 현재까지 된것은 http://hellocity.net/~iolo/files/xmlrpc_blog.php.txt 에 있습니다. GnomeBlog나 ChronicleLite라는
BloggerAPI클라이언트에서 테스트했는데 대충 굴러가는군요. editPost와 인증부분은 잘 몰라서 비워두었습니다.
와~~ 감사합니다~ 테스트해보고 넣어두겠습니다~ --WkPark
좀 더 제대로된 지원을 위해서는
MetaWebLogAPI와
MovableTypeAPI도지원해야할듯.. 그러려면 MoniWikiBlog를 대폭 고쳐야할듯 합니다. hey님께서 만들고 계신 MoniWiki용 ABlog를 고려하고 있습니다. --iolo
MoniWiki GnomeBlog 전용(?) 플러그인 ¶
GnomeBlog라는 그놈 애플릿이 있습니다. Blogger 클라이언트인데, 포스팅만 할수 있는 간단한 프로그램이죠. 이 녀석이 글꼴 속성이나 링크를 WYSIWYG으로 편집할수 있게 되어 있는데, 이 태그들을 MoniWiki에 맞게 바꾸고 간단한 XmlRpc›1를 붙여서 플러그인을 만들었습니다.
http://hellocity.net/~iolo/files/GnomeBlog.php.txt
이건 블로그와 무관합니다. GnomeBlog를 그냥 모니위키 페이지 만들기 및 내용 추가에 사용하는 거죠
--iolo
--iolo
이걸 만드는 과정에서 알게된 현상인데... XmlRpc›1 서버 URL에 쿼리스트링이 있는 경우 문제가 있습니다. 즉 플러그인으로 만들어서 .../wiki.phpaction=GnomeBlog 처럼 하면 XmlRpc›1 Client 들이 문제를 일으킵니다. 그래서 플러그인이 아닌 단독으로 .../GnomeBlogRPC.php 처럼 만들려고 하는데, wiki.php의 클래스들을 쓰려고 include("wiki.php") 하면, wiki.php가 먼저 html출력을 뿌려버리는군요. 그러니까, wiki.php에서 class들을 별도의 파일 또는 wikilib.php로 빼고, 그것만 include해야하더라는거죠.
더 자세한 얘기는 irc에서 뵙게되면... --iolo
더 자세한 얘기는 irc에서 뵙게되면... --iolo
RCS 방식 ¶
한 사용자가 여러번 고칠 경우, session을 체크하는 방식으로 하여 사용자가 원하면 고친 것을 merge할 수 있게 한다 ? (마지막으로 co한 revision을 지우고 다시 co 한다든지 하는 방식으로..)
좋은 생각이네요
config.custom.php ¶
config.custom.php 같은 걸 두고 config.php에서 include() 하면 어떨까요? (중요도: -1)
초기 config.php를 만들때만 MoniSetup을 쓸 수 있고, 그 이후로는 config.php는 어떤 설정을 넣어도 PhpLanguage의 모든 문법을 따릅니다. 즉, config.custom.php 혹은 local.php같은 것은 사용자가 그렇게 하고 싶으면 얼마든지 그렇게 할 수 있지요.
Diary ¶
RSS Description ¶
rss파일을 제공할때 description에 해당파일의 diff을 넣어주면(text겠죠?) 좋겠습니다.
요즘 rss viewer들이 많이 있는데... diff만 보여주어도 관리하기가 참 편해질것 같습니다. --iolo
일단, 위키에서 description은 그다지 큰 의미가 없습니다. diff를 넣으면 위키답겠지만, diff정보를 제대로 표현해 주려면 컬러링을 해줘야 할까요 ? 그리고, 현재 MoniWiki에서 사용하는 방법은 매번 ?action=rss_rc에 의해서 로그파일을 적절히 파싱해서 실시간으로 뿌려주기 때문에, 각 페이지를 diff하면 로드가 커지겠고요.
description이 나오게 하려면, 현재의 실시간 갱신 방법을 쓰지 않고, 새로 고친 파일이 있을 경우(editlog가 갱신되었을 경우)에 한해서 rss를 만들어 캐쉬에 저장하고, 저장된 캐쉬를 뿌려주는 식으로 하면, 로드도 줄고 description를 집어 넣을 때 생기는 오버해드도 거의 없을 것입니다. (일단 캐쉬를 쓰는 방식으로 고쳐야겠군요 =3=3=3) --WkPark
목차 생성 이상 ¶
지금 문득 보니 KLDP위키토론의 목차가 이상하게 생성되는군요. TODO와 논의가 같은 레벨인데(= 두개로 둘러쌈) 목차에서는 논의가 TODO보다 한단계 높은 절로 구분되네요. -- 권순선
일단, TableOfContentsMacro에 이상이 있네요. (버그) 제목줄은 글자 크기 뿐만이 아니라, 레벨 깊이까지 정하므로, == 다음은 ===를 쓰는 것이 정상적 방법입니다. 글자 크기는 CSS를 조절하는 식으로 하니까요. --WkPark
이것을 모인모인과 똑같은 방식으로 적용할 것인지, 아니면 좀 더 제대로 작동하게 할 것인지...
이것을 모인모인과 똑같은 방식으로 적용할 것인지, 아니면 좀 더 제대로 작동하게 할 것인지...
Enhanced ? FullSearch TitleSearch ¶
see also http://kz.mpecc.com/moniwiki/wiki.php?MultiSearch, http://kz.mpecc.com/moniwiki/wiki.php?ڵũ
=== MoniWikiBlog ==
blog액션을 막아버리니 anonymous사용자는 코멘트까지 달 수 없네요. 어떻게 해결하는게 좋을까요?
blog액션은 플로그인이며, 코멘트액션과 코드를 공유합니다. 두 액션을 구분지으려면, 두 액션을 떼어서 따로 플러그인으로 만드는 방법이 있겠지요.
일반 페이지에 대해서도 코멘트를 다는 기능이 필요한 경우가 있으므로 고려해 봐야 겠군요.
일반 페이지에 대해서도 코멘트를 다는 기능이 필요한 경우가 있으므로 고려해 봐야 겠군요.
security 플러그인 액션 부분을 수정하면 가능합니다.
function may_blog($action,&$options) { # blog 액션일 때
if ($options['value']) { # 만약 코멘트라면 허용
return 1;
}
if (!$options['page']) return 0;
if ($options['id']!=='hyacinth') { # hyacinth 아이디가 아니면 action=blog 불가
$options['err']=sprintf(_(" "),$action);
return 0;
}
return 1;
}
- hyacinth
방금 있었던 일을 말씀드리겠습니다.
오늘 제
모니위키에 "관심사"라는 제목으로 페이지를 만들었다가, 별로 좋은 이름이 아니라고 생각되서 바로 지웠습니다. 지우고 나서 블로그로 기록하려고, Calendar 매크로의 링크를 누르고 AddBlog를 하려고 했습니다. 아니, 그런데 이 어찌된 일입니까? 페이지가 지워졌다는 메시지가 나오는 페이지에서 Calendar 매크로의 링크를 클릭하니 "관심사/2003-08"이라는 이름의 페이지가 바로 생성되더군요. 위 페이지는 원래 제 위키에 없었던 페이지인데 Blog 액션으로 바로 생성되더란 말입니다. 정말 이상한 일 아닙니까?
모니위키에 "관심사"라는 제목으로 페이지를 만들었다가, 별로 좋은 이름이 아니라고 생각되서 바로 지웠습니다. 지우고 나서 블로그로 기록하려고, Calendar 매크로의 링크를 누르고 AddBlog를 하려고 했습니다. 아니, 그런데 이 어찌된 일입니까? 페이지가 지워졌다는 메시지가 나오는 페이지에서 Calendar 매크로의 링크를 클릭하니 "관심사/2003-08"이라는 이름의 페이지가 바로 생성되더군요. 위 페이지는 원래 제 위키에 없었던 페이지인데 Blog 액션으로 바로 생성되더란 말입니다. 정말 이상한 일 아닙니까?
ㅎㅎ 그런 버그가 있었군요
그런데 한편으로 생각해보니 이 방식이 전 아주 마음에 듭니다. 예를 들어 MyBlog라는 이름의 페이지에서 달력 매크로의 링크(또는 다른 AddBlog 링크)를 클릭했을 때, 자동으로 "MyBlog/YYYY-MM" 형식의 블로그 페이지를 만들어주면 편할 것 같다는 생각이 듭니다.
''그것은 테마를 고치면 됩니다. 현재 blog테마에서는, 로그인 했을 경우, 자신의 필명 하위에 블로그 페이지를 만듭니다.
로그인 하지 않았을 때는 무조건 Blog라는 페이지 하위로 블로그 페이지를 만들지요.''
블로그를 크게 Subject에 따른 블로그와 Chronology에 따른 블로그로 구분할 수 있다면, 대부분의 블로그들이 대개 월을 기준으로 아카이브를 생성하므로 "MyBlog/YYYY-MM" 형식의 PageName은 그 두가지를 모두 충족시킬 수 있지 않나 하는 생각이 듭니다. "/"은 URL 인코딩에 영향을 미치므로 "~"도 괜찮구요. 이렇게 해두고 MyBlog라는 페이지에는 PageList 매크로와 BlogChanges 플러그인을 써서.png)
이 역시 테마를 고쳐서 하면 됩니다. wiki.php나 wikilib.php에 이런 기능이 있는 것은 아닙니다.
블로그는 페이지 이름과 전혀 무관하게 작동됩니다. 아무 페이지나 그 이름에 상관 없이 만드시면 됩니다.
PageName 끝이 "/YYYY-MM", 정규식 버전으로는 "@/1-90-9{3}-010-9$@" 정도를 블로그 페이지로 기본 인식하게 하고, MyBlog 페이지에서 AddBlog를 하면 MyBlog/YYYY-MM 형식의 페이지가 없을 경우에는 새로 만들면서 블로그를 추가할 수 있는 편집 폼이 나오도록 하면 어떨까요? MoinMoin의 AttachFile 매크로가 아마 해당 페이지명으로 디렉토리를 만들면서 거기에 파일을 올릴 수 있도록 하는 걸로 아는데, 이와 비슷하다고 보면 됩니다. 아, 이건 MoniWiki의 페이지 이름으로 그 페이지 형식을 결정하는 방식은 MoniWiki가 지원합니다만 이와 같은 식의 정규식까지 지원할 필요가 있는지는 의문입니다. 위키에 기능이 너무 많이 들어간다고 우려를 표하는 분도 계십니다. 맨 뒤의 ?action=edit 대신에 ?action=blog라고 고쳐 쓰기만 하면 어느 페이지나 블로그 페이지가 될 수 있고, 간단히 맨 위에 #action Blog를 지우므로써, 일반 위키페이지로 돌아갑니다. 페이지 이름을 판별해서 블로그 페이지인지 아닌지, 그것도 맨 처음 페이지를 열 때만 필요한 기능이므로 불필요 한 것으로 생각됩니다.
장혜식님의 홈을 보면 pyblosxom과 MoinMoin이 멋지게 결합되어 있는데, MoniWiki도 블로그 기능이 좀더 강화되는 쪽으로 파워업되었으면 하는 바램입니다. --nohmad
그게 편리한 것 처럼 보이겠지만 퍼키님의 위키 페이지를 보면 일일히 날짜별로 지정해 줘야 blog페이지가 그와 같은 모양으로 나온답니다. 그리고 일반 blog와 같은 고 자동 처리가 아닙니다. cron으로 몇십분 간격으로 돌아간다고 합니다.
Calendar매크로도 특별히 하는 일은 없습니다. 제가 예제로 만들어 놓은 blog테마에서 calendar매크로를 그러한 방식으로 부르게 할 뿐입니다. Calendar매크로에 blog옵션을 주면 달별로 페이지 이름을 짓게 할 뿐이지요. --WkPark
accesskey를 더 많이 지원하면 좋겠습니다. 타이틀에 걸리는 FullSearch나 페이지가 없을 경우 페이지 만들기, 그 외에도 accesskey를 적용하면 편리할 기능이 많다고 생각합니다. --
kz
See also AccesskeyStandards
카테고리 선택하는부분을 ^Category[A-Z] 에서 Category$로 바꿔서 사용하고 있습니다(한글사용을위해서).
그렇게 하다보니 자동적으로 링크가 걸리지 않더라구요, Category를 글 밑에 쓸때 [ ]도 같이 써지게 하고, 한글이 들어가있어도 카테고리메뉴에 나오게 수정이 되면 좋겠습니다(이미 저는 그렇게 바꿔서 사용하고 있습니다;;).--ErMaker
Sunnmary of Change를 출력해 주는 Macro가 있으면 좋겠습니다. [[SummaryHistory]]정도의 매크로가 있으면 문서의 변경사항을 매번 적어줄 필요가 없지 않을까요? http://docbook.or.kr/wiki/index.php/WikiToDocBook 에서처럼 고친목록을 안 적어도 말이죠.. -- behumble
[[Info]]가 비슷한 기능을 할 수 있습니다.
위에서 보는 것과 같은 include 매크로가 있으면 좋겠습니다. 제 실력으로 짤 형편은 못되고... 나름대로 쓰임새가 많을 것 같은데 말입니다. -- lordmiss
Include매크로는 이미 포함되어 있습니다.









