주제별 포럼 - 위키
글수 49
http://www.zeroboard.com/proj_wiki/17211981 에서 댓글로 언급하고 있는 부분에 대해서 조금 더 자세하게 기술할 필요가 있어서 작성해둡니다.
1. 위키모듈의 위키문법 지원에 대하여
이전의 기획문서들에서도 많이 언급되었고 다른분들께서도 언급을 하셨지만.. zbXE의 위키문법은 코어에서 지원하지 않는것으로
결정되었습니다. 굳이 위키모듈의 코어에서 위키문법의 파서를 가지고 있을 이유가 없다는 뜻으로 보시면 됩니다.
2. 위키문법 미지원에 대한 대안
그렇다면 위키문법으로 문서를 작성하는 것에 익숙한 사용자들을 무시하는게 아닌가 하는 의견도 나올 수 있습니다만.. zbXE에서 이미 지원하고 있는 방법을 이용하여 우회하는 방식으로 위키문법을 지원할 수 있지 않을까 생각하고 있습니다. "위키문법 지원을 위한 애드온+에디터컴포넌트 세트(가칭)"의 작동 방식은 다음과 같습니다.
2.1. 에디터에서 위키문법으로 일부분, 혹은 전체를 작성합니다
2.2. 해당 부분을 선택영역으로 만들고 에디터 컴포넌트에 추가되어 있는 '위키문법으로 작성되었음을 표시'시킵니다.
2.2.1. 해당 영역의 앞뒤에 <wiki parser=moniwiki>내용(contents)</wiki>와 같은식으로 태그가 추가되며 그상태로(RAW) 저장됩니다.
2.3. 위키문법이 일부분, 혹은 전체에 적용되어 있는 게시물을 불러올때 애드온이 간섭합니다. <wiki>~</wiki>의 부분을 가로채서 위키문법 파서를 돌려주고 되돌아온 내용을 게시물의 내용에 뿌려줍니다.
아직 여러가지 검증을 해봐야겠고.. 개발팀의 의견도 들어야겠지만.. 이런식이라면 굳이 위키모듈의 코어에 위키문법의 파서가 들어갈 이유도 없고 결정적으로 사용자가 위키문법을 선택할수도 있지 않을까 하는 생각이 듭니다. 모인모인위키와 모니위키의 문법은 모니위키가 모인모인의 클론이기 때문에 비슷하지만 모니위키 자체의 위키태그를 가지고 있기 때문에 호환이 어렵고.. wikiX같은 경우엔 좀 생소한(?)정도의 변종이기 때문에 이런 부분들을 코어에서 다룬다는건 비효율적인것 같습니다. 게다가, 에디터컴포넌트 + 애드온의 구조라면 굳이 위키모듈이 아니어도 게시판모듈이나 블로그 모듈 등.. 다른 모듈에서도 위키문법을 사용할 수 있게 된다는 이야기가 되기 때문에 확장성의 부분에서도 나쁘지 않겠다.. 싶습니다. 다만, 이런 형태로 구현하는데 문제점이라면 '누군가 위키문법의 파서와 단어사전을 만들어야 한다'는 점이겠지요. 파서의 경우엔 각 위키 클론에서 뜯어다가 포팅하면 되겠지만서도.. ^^;;
3. 마이그레이션에 대한 문제
위키문법으로 작성된 위키문서를 zbXE의 위키모듈로 마이그레이션 하는 문제가 도출되었습니다. 저도 처음엔 위키문서를 print view로 하나씩 html파일로 익스포트 한 다음 붙여넣을 생각으로 마이그레이션에 대해서는 그다지 고민하지 않았습니다만.. 문제는 기존에 사용하던 위키를 통해 만들어진 문서의 양이 많다면 이게 만만찮은 작업이 된다는 것에 생각이 닿더군요.. 마이그레이션에 대해서 고민을 진행해 봤습니다. 물론 마이그레이션을 위한 익스포터는 각 위키별로 만들어져야 할것으로 보고 있습니다.
3.1. 마이그레이션의 밑준비 : 마이그레이션을 위해서는 기존의 위키클론에서 만들어진 RAW데이터가 필요할 것입니다. 물론 이 안에 위키전용의 태그가 들어있는 상태입니다.
3.2. 위키태그의 변환 : 위키태그를 html 태그로 변환해 줍니다. zbXE의 위키모듈이 이미 위키태그를 공식적으로 지원하지 않는 것으로 결정되었기 때문에 본 문서의 제 2항에서 위키문법을 사용할 수 있는 방법을 제시하고 있지만, 혼란을 피하기 위해 표준형식으로 변환하는것이 좋을듯 합니다. 특히 인터링크를 살리기 위해서도 html로 변환은 필수라고 봅니다. 단, 이 과정에서 문단의 모양이나 큰제목, 작은제목들의 모양이 흐트러지거나 바뀌는걸 피하기 위해 사용자의 선택사항을 만들어주는것도 좋을것으로 봅니다.
3.3. xml 형식으로 변환하여 익스포트
3.4. 만들어진 xml파일을 zbXE의 임포터에 넣으면 마이그레이션 완료.. 이렇게 되는 식이죠.
이 문서를 끝으로 위키문법의 지원여부에 대한 찬반이 종결되었으면 합니다. 사실 앞으로 고민해야 할 부분들이 더 많죠.. 일단은 기본적으로 위키문법을 지원하지 않지만, 우회적으로 위키문법을 지원함으로써 부가적인 이득을 볼 수 있다는 점에서 나쁘지 않은 생각같긴 하지만.. 여러분의 생각은 어떠신지 궁금합니다. 특히, 개발팀의 피드백이 중요하겠죠... ^^;;;
덧: 방금 다시 생각난 건데.. 인터링크는 어차피 깨지겠더군요.. 어차피 마이그레이션 과정 중에 퍼머링크도 깨지고 인터링크도 깨질수밖에 없습니다.. 이부분은 마이그레이션 툴을 통해 해결할 수 있는 문제라기 보다는 다시한번 자기조직화를 거쳐야 하는 부분으로 보고 있습니다. 즉, 마이그레이션 툴이 다 돌아간 후에 위키의 관리권한자가 다시한번 훑어보면서 수작업으로 짜맞춰줘야 하는게 아닐까.. 싶네요.. 차후 zbXE의 위키모듈이 인터링크를 [wiki:문서이름] 과 같이 태그로 처리하게 된다면 모르지만.. 아무튼 현재로써는 별다른 대안이 떠오르지 않고 있습니다.. Orz
1. 위키모듈의 위키문법 지원에 대하여
이전의 기획문서들에서도 많이 언급되었고 다른분들께서도 언급을 하셨지만.. zbXE의 위키문법은 코어에서 지원하지 않는것으로
결정되었습니다. 굳이 위키모듈의 코어에서 위키문법의 파서를 가지고 있을 이유가 없다는 뜻으로 보시면 됩니다.
2. 위키문법 미지원에 대한 대안
그렇다면 위키문법으로 문서를 작성하는 것에 익숙한 사용자들을 무시하는게 아닌가 하는 의견도 나올 수 있습니다만.. zbXE에서 이미 지원하고 있는 방법을 이용하여 우회하는 방식으로 위키문법을 지원할 수 있지 않을까 생각하고 있습니다. "위키문법 지원을 위한 애드온+에디터컴포넌트 세트(가칭)"의 작동 방식은 다음과 같습니다.
2.1. 에디터에서 위키문법으로 일부분, 혹은 전체를 작성합니다
2.2. 해당 부분을 선택영역으로 만들고 에디터 컴포넌트에 추가되어 있는 '위키문법으로 작성되었음을 표시'시킵니다.
2.2.1. 해당 영역의 앞뒤에 <wiki parser=moniwiki>내용(contents)</wiki>와 같은식으로 태그가 추가되며 그상태로(RAW) 저장됩니다.
2.3. 위키문법이 일부분, 혹은 전체에 적용되어 있는 게시물을 불러올때 애드온이 간섭합니다. <wiki>~</wiki>의 부분을 가로채서 위키문법 파서를 돌려주고 되돌아온 내용을 게시물의 내용에 뿌려줍니다.
아직 여러가지 검증을 해봐야겠고.. 개발팀의 의견도 들어야겠지만.. 이런식이라면 굳이 위키모듈의 코어에 위키문법의 파서가 들어갈 이유도 없고 결정적으로 사용자가 위키문법을 선택할수도 있지 않을까 하는 생각이 듭니다. 모인모인위키와 모니위키의 문법은 모니위키가 모인모인의 클론이기 때문에 비슷하지만 모니위키 자체의 위키태그를 가지고 있기 때문에 호환이 어렵고.. wikiX같은 경우엔 좀 생소한(?)정도의 변종이기 때문에 이런 부분들을 코어에서 다룬다는건 비효율적인것 같습니다. 게다가, 에디터컴포넌트 + 애드온의 구조라면 굳이 위키모듈이 아니어도 게시판모듈이나 블로그 모듈 등.. 다른 모듈에서도 위키문법을 사용할 수 있게 된다는 이야기가 되기 때문에 확장성의 부분에서도 나쁘지 않겠다.. 싶습니다. 다만, 이런 형태로 구현하는데 문제점이라면 '누군가 위키문법의 파서와 단어사전을 만들어야 한다'는 점이겠지요. 파서의 경우엔 각 위키 클론에서 뜯어다가 포팅하면 되겠지만서도.. ^^;;
3. 마이그레이션에 대한 문제
위키문법으로 작성된 위키문서를 zbXE의 위키모듈로 마이그레이션 하는 문제가 도출되었습니다. 저도 처음엔 위키문서를 print view로 하나씩 html파일로 익스포트 한 다음 붙여넣을 생각으로 마이그레이션에 대해서는 그다지 고민하지 않았습니다만.. 문제는 기존에 사용하던 위키를 통해 만들어진 문서의 양이 많다면 이게 만만찮은 작업이 된다는 것에 생각이 닿더군요.. 마이그레이션에 대해서 고민을 진행해 봤습니다. 물론 마이그레이션을 위한 익스포터는 각 위키별로 만들어져야 할것으로 보고 있습니다.
3.1. 마이그레이션의 밑준비 : 마이그레이션을 위해서는 기존의 위키클론에서 만들어진 RAW데이터가 필요할 것입니다. 물론 이 안에 위키전용의 태그가 들어있는 상태입니다.
3.2. 위키태그의 변환 : 위키태그를 html 태그로 변환해 줍니다. zbXE의 위키모듈이 이미 위키태그를 공식적으로 지원하지 않는 것으로 결정되었기 때문에 본 문서의 제 2항에서 위키문법을 사용할 수 있는 방법을 제시하고 있지만, 혼란을 피하기 위해 표준형식으로 변환하는것이 좋을듯 합니다. 특히 인터링크를 살리기 위해서도 html로 변환은 필수라고 봅니다. 단, 이 과정에서 문단의 모양이나 큰제목, 작은제목들의 모양이 흐트러지거나 바뀌는걸 피하기 위해 사용자의 선택사항을 만들어주는것도 좋을것으로 봅니다.
3.3. xml 형식으로 변환하여 익스포트
3.4. 만들어진 xml파일을 zbXE의 임포터에 넣으면 마이그레이션 완료.. 이렇게 되는 식이죠.
이 문서를 끝으로 위키문법의 지원여부에 대한 찬반이 종결되었으면 합니다. 사실 앞으로 고민해야 할 부분들이 더 많죠.. 일단은 기본적으로 위키문법을 지원하지 않지만, 우회적으로 위키문법을 지원함으로써 부가적인 이득을 볼 수 있다는 점에서 나쁘지 않은 생각같긴 하지만.. 여러분의 생각은 어떠신지 궁금합니다. 특히, 개발팀의 피드백이 중요하겠죠... ^^;;;
덧: 방금 다시 생각난 건데.. 인터링크는 어차피 깨지겠더군요.. 어차피 마이그레이션 과정 중에 퍼머링크도 깨지고 인터링크도 깨질수밖에 없습니다.. 이부분은 마이그레이션 툴을 통해 해결할 수 있는 문제라기 보다는 다시한번 자기조직화를 거쳐야 하는 부분으로 보고 있습니다. 즉, 마이그레이션 툴이 다 돌아간 후에 위키의 관리권한자가 다시한번 훑어보면서 수작업으로 짜맞춰줘야 하는게 아닐까.. 싶네요.. 차후 zbXE의 위키모듈이 인터링크를 [wiki:문서이름] 과 같이 태그로 처리하게 된다면 모르지만.. 아무튼 현재로써는 별다른 대안이 떠오르지 않고 있습니다.. Orz

한때, 웹사이트의 모든것을 혼자 다 만들 수 있다고 자만했던 웹사이트 제작자이자 울트라삽질러. -_-
지금, 언제나 사진에 목마른, 부족한 자신에 좌절하며 도전하는 쌈마이.
길스튜디오 실장 (http://gilstudio.co.kr)
핫셀클럽 운영자 (http://hasselclub.net)
지금, 언제나 사진에 목마른, 부족한 자신에 좌절하며 도전하는 쌈마이.
길스튜디오 실장 (http://gilstudio.co.kr)
핫셀클럽 운영자 (http://hasselclub.net)
2008.09.07 19:20:23 (*.146.8.110)
물론 인터링크가 있기 때문에 위키의 최대 특징 중 하나인 '자기조직화'가 이루어지므로 인터링크 없이 위키가 위키로서 동작할 수 있는지에 대해서는 저도 역시 비관적이구요. 하지만, 인터링크역시 에디터컴포넌트+애드온의 구성으로 위키문법 파서와 동일하게 구현할 수 있다고 봅니다. 여기에 zbXE프레임 웍 코어에 포함되는 퍼머링크를 묶으면 굳이 위키모듈에 종속된 문서들 뿐 아니라 zbXE프레임 웍 기반의 모든 문서에서 '자기조직화'가 이루어질 것으로 희망하고 있습니다.
그래서, 위키모듈의 코어는 코어에서 자체적으로 지원하지 않으면 구현할 수 없는 '문서의 버젼컨트롤'이라든지 '공동저작'에 대한 부분만을 남기고 가볍게 하는것도 괜찮다고 생각합니다. 그 다음에 위키모듈에.. 아니 전체의 플러그인으로써 작동하는 에디터컴포넌트+애드온의 세트를 몇개 묶어서 설치하면 zbXE가 가려는 CMS의 방향과 부합되리라고 생각합니다. ^^
덧: 마이그레이션을 하게 되면 문서의 URL과 같은 퍼머링크가 깨지게 될것입니다. 이 때문에 마이그레이션과정중 퍼머링크를 이전과 같이 유지해주는 어떤 '방법론'없이는 퍼머링크가 깨지는건 당연하리라고 예측하고 있습니다. 퍼머링크를 유지하게 할 수 있는 어떤 '방법론'에 대해서 고민해봐야 할 문제가 아닐까 싶네요.
그래서, 위키모듈의 코어는 코어에서 자체적으로 지원하지 않으면 구현할 수 없는 '문서의 버젼컨트롤'이라든지 '공동저작'에 대한 부분만을 남기고 가볍게 하는것도 괜찮다고 생각합니다. 그 다음에 위키모듈에.. 아니 전체의 플러그인으로써 작동하는 에디터컴포넌트+애드온의 세트를 몇개 묶어서 설치하면 zbXE가 가려는 CMS의 방향과 부합되리라고 생각합니다. ^^
덧: 마이그레이션을 하게 되면 문서의 URL과 같은 퍼머링크가 깨지게 될것입니다. 이 때문에 마이그레이션과정중 퍼머링크를 이전과 같이 유지해주는 어떤 '방법론'없이는 퍼머링크가 깨지는건 당연하리라고 예측하고 있습니다. 퍼머링크를 유지하게 할 수 있는 어떤 '방법론'에 대해서 고민해봐야 할 문제가 아닐까 싶네요.
2008.09.08 16:26:32 (*.13.13.67)
일단 이 글에는 여러 이슈가 있네요. ^^
기존의 마이그레이션툴도 이전 이전의 url에 대한 보존을 해주지 않아서 보존 대책을 세워야 하는데 위키 마이그레이션시에 같이 고민해보면 될 것 같습니다.
단 이 기존 url의 보존은 XE만의 설정으로는 안되고 약간의 XE 외부의 작업이 필요할지도 모르겠습니다.
그리고 위키 문법들이 모두 통일되지 않은채 위키 툴마다 상이하기 때문에 과연 위키문법을 어떻게든 쓸 수 있도록 해야 하냐는 점에 대해서는 좀 비관적입니다.
위키문법이 편하고 익숙한 걸 떠나서 문서를 작성할때 위키 문법으로 매우 깔끔하게 만들 수 있다는 것을 생각하면 위키 문법을 쓰지는 않지만 위지윅상에서 위키문법을 쓰듯이 편하게 결과물을 작성할 수 있어야 한다는 필요성이 대두되는데요... ^^
이 문제는 일단 제가 개발 질러보고 진행해보면 좋겠습니다.
쇼핑몰은 기획 - 설계 - 디자인 - 개발을 모두 같이 제대로 진행하여야 할 이슈이지만 위키는 일단 어느정도 프레임이 제공되면 그 프레임을 바탕으로 토론을 통해서 진행하면 될 이슈가 될 수 있을 것 같습니다. ^^
기존의 마이그레이션툴도 이전 이전의 url에 대한 보존을 해주지 않아서 보존 대책을 세워야 하는데 위키 마이그레이션시에 같이 고민해보면 될 것 같습니다.
단 이 기존 url의 보존은 XE만의 설정으로는 안되고 약간의 XE 외부의 작업이 필요할지도 모르겠습니다.
그리고 위키 문법들이 모두 통일되지 않은채 위키 툴마다 상이하기 때문에 과연 위키문법을 어떻게든 쓸 수 있도록 해야 하냐는 점에 대해서는 좀 비관적입니다.
위키문법이 편하고 익숙한 걸 떠나서 문서를 작성할때 위키 문법으로 매우 깔끔하게 만들 수 있다는 것을 생각하면 위키 문법을 쓰지는 않지만 위지윅상에서 위키문법을 쓰듯이 편하게 결과물을 작성할 수 있어야 한다는 필요성이 대두되는데요... ^^
이 문제는 일단 제가 개발 질러보고 진행해보면 좋겠습니다.
쇼핑몰은 기획 - 설계 - 디자인 - 개발을 모두 같이 제대로 진행하여야 할 이슈이지만 위키는 일단 어느정도 프레임이 제공되면 그 프레임을 바탕으로 토론을 통해서 진행하면 될 이슈가 될 수 있을 것 같습니다. ^^
2008.09.16 19:28:24 (*.146.8.15)
1. 마이그레이션에 대해서는 '어떻게 해야 기존의 퍼머링크를 그대로 사용하게 할 수 있을까'하는 고민을 해봐야할것 같습니다. 예전에 마이그레이션 툴에 대해서 제안했었던 '기존의 퍼머링크와 새로운 퍼머링크를 연결해주는 브리지와 같은 개념'이 있는것도 나쁘진 않을것 같지만, 문제는 이것들이 새로이 생성되는 퍼머링크와의 관계라든지.. (여기에서 다시 데이터 무결성이 나오려나요? ^^;;;;) 아무튼 고민해봐야 할 문제로 보입니다.
2. 위키문법을 우회적으로 사용할 수 있게하는 고민을 했던 이유는, 굳이 위키모듈에 위키문법을 사용할 수 있게 하자는 의도가 아니라, 위키문법을 사용하고 싶어하는 사용자들을 위한 가능성 정도로 생각하고 있습니다. 위키모듈의 코어에선 공동저작과 자기조직화에 대한 부분같이 보편타당한 부분만을 구현하고 발전시키는것이 혼란을 피할 수 있을듯 합니다. "굳이 위키모듈에서 위키문법을 지원하지 않더라도 나중에 하고싶은 사람은 스스로 만들어 쓸 수 있다"는 메시지 정도랄까요? 위키모듈의 코어에서 위키문법에 대한 고민을 해방시키자는 의도 또한 들어있습니다. 위지윅 에디터가 좀 더 발전해서 (La)TeX 같은것으로 결과물을 만들어준다면 모든 근심걱정고민이 사라지면서 웹사이트를 벗어난 문서의 교환같은게 되지 않을까나.. 하고 망상(!!!)을 전개해봅니다만.. 지금 단계에서 고민할 필요는 없을듯 합니다. (굳이 HTML로도 표현할 수 있는 컨텐츠를 TeX로 표시하는 무모함+바보같음은 '망상'이라는 이름으로 적절히 얼버무려주시길.. Orz)
3. 지금으로썬 http://www.zeroboard.com/proj_wiki/17211981에서 언급하신바와 같이 mid를 통한 다중 위키생성 + 문서편집(or생성) 권한 그룹에 의한 공동저작 + 관리권한자에 의한 히스토리 및 버젼 컨트롤 + 코어의 퍼머링크 만으로 0.1 버젼을 만든 후 그 안에 하나하나 놓치고 있다고 생각되는 부분들을 추가해 나가는것도 좋을것 같습니다. 이미 0.1에서 포함될 기능만으로도 스프링노트의 기본기능에서 트리구조를 뺀 형태가 되지 않을까.. 싶은데요? 이미 이정도만으로도 하나의 공간에서 공동저작을 실현해 나갈 수 있는 틀이 될 것으로 보고 있습니다.
2. 위키문법을 우회적으로 사용할 수 있게하는 고민을 했던 이유는, 굳이 위키모듈에 위키문법을 사용할 수 있게 하자는 의도가 아니라, 위키문법을 사용하고 싶어하는 사용자들을 위한 가능성 정도로 생각하고 있습니다. 위키모듈의 코어에선 공동저작과 자기조직화에 대한 부분같이 보편타당한 부분만을 구현하고 발전시키는것이 혼란을 피할 수 있을듯 합니다. "굳이 위키모듈에서 위키문법을 지원하지 않더라도 나중에 하고싶은 사람은 스스로 만들어 쓸 수 있다"는 메시지 정도랄까요? 위키모듈의 코어에서 위키문법에 대한 고민을 해방시키자는 의도 또한 들어있습니다. 위지윅 에디터가 좀 더 발전해서 (La)TeX 같은것으로 결과물을 만들어준다면 모든 근심걱정고민이 사라지면서 웹사이트를 벗어난 문서의 교환같은게 되지 않을까나.. 하고 망상(!!!)을 전개해봅니다만.. 지금 단계에서 고민할 필요는 없을듯 합니다. (굳이 HTML로도 표현할 수 있는 컨텐츠를 TeX로 표시하는 무모함+바보같음은 '망상'이라는 이름으로 적절히 얼버무려주시길.. Orz)
3. 지금으로썬 http://www.zeroboard.com/proj_wiki/17211981에서 언급하신바와 같이 mid를 통한 다중 위키생성 + 문서편집(or생성) 권한 그룹에 의한 공동저작 + 관리권한자에 의한 히스토리 및 버젼 컨트롤 + 코어의 퍼머링크 만으로 0.1 버젼을 만든 후 그 안에 하나하나 놓치고 있다고 생각되는 부분들을 추가해 나가는것도 좋을것 같습니다. 이미 0.1에서 포함될 기능만으로도 스프링노트의 기본기능에서 트리구조를 뺀 형태가 되지 않을까.. 싶은데요? 이미 이정도만으로도 하나의 공간에서 공동저작을 실현해 나갈 수 있는 틀이 될 것으로 보고 있습니다.




오해인지 모르지만 위키문법을 코어에 넣지 않는 것을 선택하면 마이그레이션을 해오는 위키문서의 인터링크가 깨져버리는 것을 감수해야 한다는 말씀인가요? 그럼 새로 쓰는 위키문서에는 인터링크가 어떻게 구현되는 거죠? 인터링크가 없을 리는 없을 테고...
위키문법 자체를 다 넣지 않는다고 해도 최소한의 것들은 기본으로 넣어야 하지 않을까 하는 생각을 해봐야 하는 건가요?
어느 위키든지 다 있고, 배우기 쉽고(매우 직관적), 오해의 소지가 없는(일반적인 글쓰기에 자주 등장하지 않을), 그런 위키문법 요소 몇 개 정도는 남겨둬야 한다면 그리해도 크게 복잡해지지 않을 것 같네요.
위키파서 자체를 다 모듈에 넣지 말고 에드온처럼 하자는 의견에는 동의합니다.