주제별 포럼 - 위키
![[레벨:7]](./modules/point/icons/default/7.gif "포인트:4415point (76%), 레벨:7/30"){kind=icon}
Adios이번 문서에서는 위키모듈에 들어갈 기능을 정의해 보도록 하겠습니다. 일단은 어떤 기능이 들어갈지 부터 주욱 정리해 놓고서 이들에 대한 구체적인 기능과 작동방식을 정의해 나가도록 하겠습니다.
이 문서는 위키모듈에 대한 제안이 담겨 있는 문서에서 도출된 이슈를 포함하고 있습니다. 추가되어야 할 기능이 있다면 기탄없이 리플 달아주시길.. ^^
위키모듈의 기본 기능 도출
1. 공동저작
1.1. 하나의 문서를 여러사람이 편집 - 복수의 사용자에게 편집권한을 준다. 단, 모든 사용자에게 편집권한을 줄 경우 혼란이 예상된다. (1.2 항으로 연결) 모든 위키 페이지에 '수정'버튼이 따라다닌다.
1.2. 편집권한의 제한 - 여러 위키엔진에서 ACL(Access Control List)를 도입하고 있다. 위키모듈에서는 ZBXE의 기반으로 사용하고 있는 회원 권한을 그대로 이용한다.
1.3. 공동저작에서 발생하는 충돌(Access Violation)의 문제 - 제안문서에서 언급된 Lock 기능으로 해결.
1.4. 손쉬운 문서생성 - 위키모듈의 모든 페이지에 '새로운 페이지를 생성'하는 기능을 포함.
2. 버젼 컨트롤
2.1. 버젼 히스토리 - 문서의 수정이력을 별도로 보관하고 문서의 내용을 이전의 버젼으로 Rollback(돌아가기)할 수 있는 기능.
2.2. 버전별 비교 - 문서의 각 버젼별 변경된 내용을 비교할 수 있는 기능.
2.3. History Purge - 버젼 히스토리를 비우는 기능. 버젼히스토리에 큰 의미가 없는 경우 이것을 Purge하여 리소스를 절약할 수 있다. (2007. 9. 12. 추가 - History의 전체를 Purge 하거나 선택한 버젼, 혹은 개별로 Purge할 수 있다면 어떨지?)
3. 링크
3.1. 내부문서간 링크 - 각 문서간의 링크를 손쉽게 만드는 기능.
3.2. 키워드 링크 - 문서의 이름을 기준으로 다른문서에서 이 이름이 표시되는 경우 자동으로 링크를 걸어주는 기능. 꼭 문서이름 뿐 아니라 키워드 (혹은 문서의 태그)를 기준으로 링크를 걸어주는것도 좋을듯
(2007. 9. 12. 추가 - http://www.zeroboard.com/849471 에서 구현된 키워드 링크는 str_replace 함수를 이용해서 화면에 뿌려주기 전에 동시 치환하는 방식으로 보이는데.. 이 경우 html태그 안에 들어있는 키워드까지 치환에 말려드는-_- 현상이 발생한다. 정규표현식을 통해 치환할 대상을 선택적으로 치환하게 하는 방식이 필요할 것으로 보인다. 혹은, 수동으로 [wiki:wikiwiki]와 같은 식으로 문서 안에 정의해 놓으면 화면에 뿌려주기 전 이것을 parsing하여 키워드로 링크걸어주는것도 방법이 될듯)
4. 기타기능 (도출중)
4.1. 페이지 인덱스 - 위키모듈을 통해 작성된 페이지의 링크를 모아서 보여주는 페이지. 자동으로 링크를 만들어 주거나 혹은 수동으로 구성할 수 있도록. (=WIKISEED중 FrontPage가 이 기능을 하며, 스프링노트의 경우 hierarchical한 구조를 위해 페이지의 종속관계를 가지고 있어서 이것을 리스트로 보여줄 수 있다.) -> 이 부분은 고민할 필요가 있다.
4.2. wikiseed - 위키엔진들은 위키의 이용을 도와주는 여러 페이지들을 WIKISEED로써 지원한다. 이들 SEED문서를 어디까지 지원할지에 대해서는 추가적인 고민이 필요하다.
4.2.1. FrontPage - ZBXE에 위키모듈을 연결한 후 처음 실행하면서 생성되는 페이지. 위키모듈의 대문역활을 한다.
4.2.2. RecentChanges - 최근 수정된 모든 문서를 표시.
4.2.3. Table Index (WordIndex) - 페이지의 제목을 기준으로 정렬하여 보여준다.
4.2.4. FindPage - 페이지의 제목을 기준으로 검색하거나 FullTextSearch. ZBXE의 내부 검색기능으로 대체.
4.2. table of index - 위키문서 내부에서 숫자목록이 있을 경우 자동으로 인덱스를 만들어주는 기능.
4.3. ISBN연동 - 이런 기능은 ZBXE의 애드온으로 어울릴지도?
일단 필요한 기능으로 생각되는 것들을 주욱 도출해 보았습니다. 추가되어야 할 기능이라든지 위키 특유의 기능 중 수용하면 재미있을것 같은 기능이 있다면 기탄없이 제시해 주세요. ^_^
2007. 9. 14 변경 - '동시편집'이라는 단어가 적절하지 않아서 '공동저작'으로 변경하였습니다.
지금, 언제나 사진에 목마른, 부족한 자신에 좌절하며 도전하는 쌈마이.
길스튜디오 실장 (http://gilstudio.co.kr)
핫셀클럽 운영자 (http://hasselclub.net)
![[레벨:3]](./modules/point/icons/default/3.gif "포인트:1200point (83%), 레벨:3/30"){kind=icon}
가장아름다운사랑
-> 이 경우 '공백문자'를 어떻게 인식하느냐가 문제되더군요.
즉 '손해배상액 산정'의 키워드와 '손해배상액'의 키워드가 있을 경에
두개가 별개로 인식이 되도록 하는 방안이 있을까요???
(보통은 전자에 후자가 포함되므로 후자의 키워드만 인식이 되는 것 같습니다.
제가 도움을 드리려고 읽어봤다가,
이미 많은 고민과 정리를 다 해 놓으셔서,
'동감' 만 드릴 수 있겠네요 ^^
cstonemediawiki 기준으로 다음 기능이 있으면 좋겠습니다.
1. Category : 만드는 page들 간의 연결성을 유연하게 할 수 있습니다.
2. Print view tweak : 직접 위키로 작성된 부분만(즉, 제목과 내용만) 골라서 프린트시켜줍니다.
3. Watchlist : scrab 기능과 연동시키면 좋겠네요.. 한참 작업 중인 문서를 다음날 다시 찾기가 편해집니다..
4. Interwiki 편집 : 외부 위키 뿐만 아니라 특별히 자주 사용되는 사이트(도서관, 잡지 등)의 컨텐츠를 직접 연결하기 편해집니다.
5. 이건 mediawiki엔 없지만.. depth를 가진 page를 볼 때, 제목과 달리 상위 페이지로 바로가기가 있으면 좋겠습니다.
즉, '제로보드' 페이지를 만들고, 이것의 하위인 '프로젝트' 페이지와 'member' 페이지, 또 '프로젝트'의 하위인 '위키모듈개발' 페이지와 '마이그레이션' 페이지,..... 이런식으로 하위에 해당하는 페이지를 만들었다고 하죠..
이제 '위키모듈개발'페이지로 가면 mediawiki는 "제로보드/프로젝트/위키모듈개발"이란 제목만 보여줍니다. 이 때, 위의 '제로보드'와 '프로젝트'란 페이지로의 링크도 바로 생성되어 보여주면 좋겠다는 의미입니다. 모니위키같은 경우 클릭한 페이지의 히스토리를 몇개정도 보여주던데 이것도 좋은 기능이지만, 현재 보는 페이지의 부모 페이지들을 보여주면서 바로 넘어가게 하는 위키는 여지껏 1개밖에 못봤습니다.. -.-;;
생각난 것만 적어봤습니다...
Adios
1. 제가 아직 Wiki에서 Category를 어떻게 활용하는지 적응을 못해서 기능명세를 못하고 있기도 합니다.. 후딱 경험을 해봐야겠습니다.. ^^;;
2 상단과, 하단을 떼어네고 프린트하는 기능이라면 상당히 활용도가 높을듯 싶네요.. 비단 위키모듈 뿐 아니라 ZBXE의 모든 부분에서 활용가능할것 같습니다.
3. 이 기능 역시 위키모듈 뿐 아니라 ZBXE 전체에 적용가능한 기능으로 보입니다. 예전에 '내 글 모니터'라는 이름으로 공식 사이트에 건의해 두긴 했는데.. 별도의 애드온, 혹은 모듈로 기획이 가능할 듯 싶습니다.
4. interwiki에 대한 기획을 계속 진행하고 있긴 한데 역시 작동방식을 이해하지 못한탓도 있습니다. 일단 ISBN과의 연동에 대해서는 생각중입니다.
5. 네비게이션을 도와주는 애드온역시 ZBXE의 전체기능에 포함되면 좋을 기능으로 생각됩니다. 위키모듈에서는 위키모듈로 작성된 모든 페이지의 상하관계를 파악하여 계층적인 리스팅을 해주면 좋을듯 싶은데.. 좀 더 구체적인 고민을 해둬야 할것 같습니다.
의견 감사드립니다. 적극 참고하도록 하겠습니다. ^^
cstone찾고싶은 검색어가 "AI"이고, "AI"를 정의하고 있는 위키가 http://www.cliki.net/ 이며,
이 위키가 "AI"를 보여주는 방식이 http://www.cliki.net/AI 인 경우를 예로 보면..
먼저 이 위키를 cliki 라고 정의하고, cliki에서 AI를 보고싶은 경우 [cliki:AI]라고 링크를 만들어줍니다.
그렇게하면 내부에선 http://www.cliki.net/$1 이란 링크 자동연결 매크로를 가지고 [cliki:xxxx]의 xxxx부분을 $1에 넣어주는 작업을 합니다. 즉, tex의 매크로와 같은 기능을 합니다. 이 부분을 사용자가 얼마든지 추가할 수 있도록 만드는 것입니다..
음.. 이걸 굳이 주저리주저리 말씀드린 것은...
a. 혹 wiki 프로젝트를 진행하실때, (La)TeX 기능도 지원해 주시면 좋겠습니다..
mediawiki에서도 <math>OOO</math> 형태로 지원해주는데 매우 유용하거든요..
b. 이것 말고도 extensions로 굉장히 많은 사용자 정의 매크로 혹은 멀티미디어 입력, 에디터 기능 등등이 지원되는데..
이런 많은 기능들을 zbxe에서 다시 만들기보단.. 이미 만들어져 있는 extension들을 zbxe에서 쓸 수 있도록 만드는 converter 같은 기능이 있거나.. 혹은 직접 쓸 수 있도록 호환성을 가지도록 만들면 어떨까 싶은 생각도 있습니다.. (무지막지한 의견이라면 죄송합니다.. ^^)
아무튼..
수고 많으시구요.. 위에것.. 적극 참고해 주시겠다고 하시니 감사드립니다..
Adios
인터위키의 경우 에디터 컴포넌트에서 처리할 수 있을것으로 생각하고 있습니다. 위키의 원형, 혹은 클론에서는 위지윅 에디터를 사용하지 않고 거의 모든 부분을 별도로 정의한 태그를 커멘드 삼아 처리하도록 만들어져 있기 때문에 ZBXE에 곧바로 통합시키기엔 약간 무리가 있을것 같습니다. 에디터 컴포넌트에서 [site:page]형태의 태그를 해석하는 방법과 별도로 유사한 형태의 "링크 도우미(?)"를 만들어주는 것에 대해서 생각하고 있습니다.
(La)Tex에 대해서는 저도 기존의 위키를 분석하면서 고민했습니다만.. ZBXE의 위키모듈이 단독의 위키모듈이라기 보다는 ZBXE의 구조 위에 올라서 있는 형태를 가지기 때문에 별도의 플러그인을 만드는 부분에 대해서는 부정적입니다. 위키모듈을 위한 플러그인이 별도로 필요하다기 보다는 ZBXE의 전체를 아우르는 에디터 컴포넌트로 LaTex지원 기능이 나온다면 이 프로젝트의 지향점인 ZBXE와 위키의 통합(Integration)에 부합되지 않을까 하고 생각합니다.
의견 감사드립니다. ^_^
키워드 링크 - 문서의 이름을 기준으로 다른문서에서 이 이름이 표시되는 경우 자동으로 링크를 걸어주는 기능. 꼭 문서이름 뿐 아니라 키워드 (혹은 문서의 태그)를 기준으로 링크를 걸어주는것도 좋을듯
->키워드에 '웹문서 경로'가 표시되어 있을 때는 해당 주소로 바로 이동하고, 경로가 없을 경우에는 해당 키워드를 설명하는 문서로 링크되도록 했으면 합니다.
예컨대, '청와대는 깜이 안되는 것으로 의혹을 제기한다고 비판했다'라는 문장에서
'청와대'는 청와대 사이트로 링크가 되고
'깜'은 '깜'을 설명해 놓은 문서로 링크가 되는 것입니다.
청와대를 청와대 사이트로 링크시키는 것은
'청와대'를 키워드로 등록하면서 '주소'를 같이 등록하면 바로 그 주소로 링크가 되도록 하면 될 듯 합니다.