주제별 포럼 - 위키
글수 55
일단.. 상당히 많은 부분 스펙을 줄여서 시작할까 합니다.
여기 포럼 글들을 보고 고민해 보았고 제 나름대로 정리해서 대충 다음과 같이 구상중입니다.
1. 위키 모듈로 만든 mid들은 모두 시작페이지로서 의미를 가진다.
: 물론 각 mid에서 만들어진 페이지들은 해당 mid의 권한과 설정을 승계한다.
2. 각 위키 페이지들은 설치된 XE내의 모든 위키 페이지에 대해서 링크를 걸 수 있도록 지원한다.
: 1번에서 시작페이지로서의 의미라고 한 건 각 mid의 대문외에 그 대문에서 만들어진 위키 페이지들은 모두 서로 연동 가능하다는 것입니다.
3. 스프링노트와 같은 tree구조는 포기한다.
: tree구조가 편하긴 하지만 이 구조를 위해서 버려야 할 것들, 즉 자유로움이나 비교적 덜 부담스런 관리등의 매력이 덜할 수 밖에 없을 것 같습니다.
본연의 위키처럼 링크로 문서가 연결되는 것이 좋지 않을까 싶습니다.
4. 위키문법은 쓰지 않는다
: 이 부분에 대해서 많은 고민을 해보았는데.. 위키 문법은 결국에는 사라질 것이고 사라져야 한다고 생각했습니다.
회사에서도 위키를 사용하는데 대부분 위키 문법때문에 고생하다가 포기하더군요.
위키 문법을 좋아하는 분들이나 위키 매니아분들은 매우 좋은 위키 프로그램들이 있으니 XE 위키 모듈을 이용하지 않을 것이라고 생각해버렸습니다. (응?)
에디터를 이용하기로 하고 일단 에디터의 결과물을 잘 정리하도록 할 예정입니다.
5. 문서들의 고유링크는 제목이나 혹은 별도로 입력된 text를 이용할 수 있도록 하고 이건 XE 기본 코드에 포함시킨다
: http://주소/맛있는-라면-끓이는법 이런 것을 기본 지원하게요..
5. diff나 히스토리 관리는 당연히 있고 최신 글은 documents (문서)를 이용한다
: 이건 여러 최근 게시물이라든지 하는 이미 만들어진 위젯이나 애드온을 그대로 쓰기 위함입니다.
뭐 대충 이 정도로 생각해버렸습니다.
의견 주시면 감솨하겠습니다.
ps. 위의 스펙은 시작을 하기 위한 스펙으로 최소한도로 그리고 확장성/범용성보다는 쉬운 접근을 위해서 작성한 것입니다.
위키 모듈의 프로토타입이 나오고 나면 아무래도 더 활발한 피드백이 이루어질 것이라 그 때 더 세밀한 접근을 하면 될 것 같습니다.
여기 포럼 글들을 보고 고민해 보았고 제 나름대로 정리해서 대충 다음과 같이 구상중입니다.
1. 위키 모듈로 만든 mid들은 모두 시작페이지로서 의미를 가진다.
: 물론 각 mid에서 만들어진 페이지들은 해당 mid의 권한과 설정을 승계한다.
2. 각 위키 페이지들은 설치된 XE내의 모든 위키 페이지에 대해서 링크를 걸 수 있도록 지원한다.
: 1번에서 시작페이지로서의 의미라고 한 건 각 mid의 대문외에 그 대문에서 만들어진 위키 페이지들은 모두 서로 연동 가능하다는 것입니다.
3. 스프링노트와 같은 tree구조는 포기한다.
: tree구조가 편하긴 하지만 이 구조를 위해서 버려야 할 것들, 즉 자유로움이나 비교적 덜 부담스런 관리등의 매력이 덜할 수 밖에 없을 것 같습니다.
본연의 위키처럼 링크로 문서가 연결되는 것이 좋지 않을까 싶습니다.
4. 위키문법은 쓰지 않는다
: 이 부분에 대해서 많은 고민을 해보았는데.. 위키 문법은 결국에는 사라질 것이고 사라져야 한다고 생각했습니다.
회사에서도 위키를 사용하는데 대부분 위키 문법때문에 고생하다가 포기하더군요.
위키 문법을 좋아하는 분들이나 위키 매니아분들은 매우 좋은 위키 프로그램들이 있으니 XE 위키 모듈을 이용하지 않을 것이라고 생각해버렸습니다. (응?)
에디터를 이용하기로 하고 일단 에디터의 결과물을 잘 정리하도록 할 예정입니다.
5. 문서들의 고유링크는 제목이나 혹은 별도로 입력된 text를 이용할 수 있도록 하고 이건 XE 기본 코드에 포함시킨다
: http://주소/맛있는-라면-끓이는법 이런 것을 기본 지원하게요..
5. diff나 히스토리 관리는 당연히 있고 최신 글은 documents (문서)를 이용한다
: 이건 여러 최근 게시물이라든지 하는 이미 만들어진 위젯이나 애드온을 그대로 쓰기 위함입니다.
뭐 대충 이 정도로 생각해버렸습니다.
의견 주시면 감솨하겠습니다.
ps. 위의 스펙은 시작을 하기 위한 스펙으로 최소한도로 그리고 확장성/범용성보다는 쉬운 접근을 위해서 작성한 것입니다.
위키 모듈의 프로토타입이 나오고 나면 아무래도 더 활발한 피드백이 이루어질 것이라 그 때 더 세밀한 접근을 하면 될 것 같습니다.
2008.08.27 11:53:23 (*.117.242.44)
기존게시판에 우선 데이터들을 넣는 작업을 하고 있습니다. 위키모듈이 나오면 위키 모듈에 기존데이터를 이전시키는데에 문제가 없을까요? (없겠죠?^_^;)
그리고 트리구조가 없다는 것이 좀 마음에 걸립니다. 우리나라사람들 문서관리할때 순서잡는거 중요시하져 오픈마루에서도 그점을 중요시해서 스프링노트가 트리구조가 되었다고 생각됩니다. 그러나 트리구조는 애드온이나 위젯으로 대체할수도 있다고도 생각됩니다.
메뉴 위젯도 나왔는데 그것을 조금만 응용하면 가능할거라 생각됩니다..gif)
그리고 트리구조가 없다는 것이 좀 마음에 걸립니다. 우리나라사람들 문서관리할때 순서잡는거 중요시하져 오픈마루에서도 그점을 중요시해서 스프링노트가 트리구조가 되었다고 생각됩니다. 그러나 트리구조는 애드온이나 위젯으로 대체할수도 있다고도 생각됩니다.
메뉴 위젯도 나왔는데 그것을 조금만 응용하면 가능할거라 생각됩니다.
2008.08.29 10:55:01 (*.106.160.17)
위키문법을 사용하지 않기로 한 판단에 지지합니다.
위키 문법 사용하면 위키 사용할 사람들 거의 없습니다.
위키 문법 쓸 사람들은 별도로 위키 문법용 모듈을 만들어도 될 거구요.
제가 만들고 있는 사이트에서 사용할 예정이라 빨리 나오기를 기대하고 있습니다.
테스트 버젼이 나오기까지 얼마나 걸릴까요?
위키 문법 사용하면 위키 사용할 사람들 거의 없습니다.
위키 문법 쓸 사람들은 별도로 위키 문법용 모듈을 만들어도 될 거구요.
제가 만들고 있는 사이트에서 사용할 예정이라 빨리 나오기를 기대하고 있습니다.
테스트 버젼이 나오기까지 얼마나 걸릴까요?
2008.09.03 14:48:32 (*.215.216.254)
너무 뒤늦게 게시물을 발견했군요~ =_=
게시판, 블로그, 위키 비슷비슷하면서도 너무나 다른 형태라고 볼 수 있지요~
처음 게시물부터 모두다 훑어보고 여기까지 달려왔습니다~
개인적인 의견 남깁니다~
3.트리구조
저 역시 위키에서는 트리구조가 필요없다고 보여집니다.
카테고리를 생성하여 그곳에 묶어놓던지
문서 생성시 제목에 슬래쉬를 넣던지
하면 될것같습니다. ( 현재 사용중인 위키에서도 그리 쓰고있구요~)
4. 위키문법
문법에 대해서는 개인적으로 반대 견해가 있습니다.
현재 moniwiki를 사용하고 있는데.. 몇개는 안되지만 이 문서들을 제로위키로 끌어올 생각을 하니 막막하기도합니다.
누군가가 마이그레이션 툴을 제공해주면... 해결은 되겠지만요.. (양방향 마이그레이션 툴이 나왔으면 좋겠습니다.)
제 주변에도 '문법이 어려워서 위키를 포기한다' 는 사용자들이 많긴 한데요
방향을 위키 문법용 위지윅으로 생각해보시는건 어떨까 합니다.
UI만 같다면 쉽게접근할 수 있지 않을까합니다.
쉽고 편하게 사용할만한 위키 문법도많이 있다고 봅니다.
<B>가나다라</B> '''가나다라''' 외에도 링크도 있고~~ 다양한것같습니다~~
이제라도 발견했으니 종종 방문하겠습니다~~~
수고가 많습니다.
감사합니다~~
2008.09.04 11:36:16 (*.46.241.53)
위키 문법 지원문제는 제로님 견해에 저도 동의하는 바입니다.
위키 문법이 난립(?)하고, 기능에 제한이 많은 면이 있습니다.
그러나 위키 문법호환이 되면 마이그레이션등에서 득이 될 것 같긴 합니다.
위키 문법 호환이 안되는 것이 제가 몇년간 써온 예전 구닥다리 위키를 못 버리는 이유이기도 합니다. 양날의 검이죠
문법에 익숙해지고 익스텐션들을 만들어 쓰다보면 그 위키 프로그램에 종속돼서 빼도박도 못합니다.
마이그레이션 - "백업으로 뱉어낸 tar볼을 새 사이트에 그대로 적용하면 복구 완성!"된다면 좋겠습니다. 위키 문법과 안녕.
거기에 추가로 큰 제목 작은 제목등의 소규모 문단 속성등의 지정이 잘 되면 문서 만들기에 아주 좋겠지요.
위키 문법이 난립(?)하고, 기능에 제한이 많은 면이 있습니다.
그러나 위키 문법호환이 되면 마이그레이션등에서 득이 될 것 같긴 합니다.
위키 문법 호환이 안되는 것이 제가 몇년간 써온 예전 구닥다리 위키를 못 버리는 이유이기도 합니다. 양날의 검이죠
문법에 익숙해지고 익스텐션들을 만들어 쓰다보면 그 위키 프로그램에 종속돼서 빼도박도 못합니다.
마이그레이션 - "백업으로 뱉어낸 tar볼을 새 사이트에 그대로 적용하면 복구 완성!"된다면 좋겠습니다. 위키 문법과 안녕.
거기에 추가로 큰 제목 작은 제목등의 소규모 문단 속성등의 지정이 잘 되면 문서 만들기에 아주 좋겠지요.




그저 죽여주사이다... (넙죽)
제 생각을 정리하자면 이렇습니다..
1. 위키모듈을 통해 생성된 mid가 FrontPage로 작동하는것에 대해서는, 지금까지의 위키클론들은 대부분 단일 위키만으로 작동하는데 ZBXE를 통해서는 복수의 위키를 운영할 수 있게 될 것으로 보여서 매우 좋은 아이디어라고 생각됩니다.
2. 예를들어, mid A에서 만들어진 위키문서들이 굳이 mid A 안에서만 사용되는것이 아니라 mid B에서도 가져다 쓸 수 있다면 좀 더 확장성이 늘어날 것 같습니다.
3. 트리구조는 굳이 지금 만들지 않아도 나중에 어떤 형태로든 구현이 가능할 것으로 생각됩니다. 이런 경우에는 별도의 테이블에서 문서간 관계를 가지고 있는식으로 구조화할 수도 있겠지만. 어쨌든 위키의 장점인 '자기조직화'를 최대한 살리는 방향으로 나아가면 좋겠습니다.
4. 위키문법에 대해서는 아직 오픈이슈지만.. 위키문법 자체에 사투리(?)가 너무 많기 때문에 굳이 위키문법을 도입해야하는가에 대해서는 저도 약간 부정적이었습니다. 나중에 에디터 컴포넌트를 통해 위키문법을 RAW형태로 저장할 수 있게 하고(즉, 문서 내용의 앞부분에 위키문법으로 작성되었음을 표시시키는 태그를 붙이고) 애드온을 통해 위키문법으로 작성되었음을 확인하여 (called position 이 before_display_content 일때 문서의 내용을 가로챈 후) 파싱해서 표시해준다든지 하는 식으로 충분한 구현이 가능할것 같습니다. 이 형태라면, 차후에 위키문법별로 에디터 컴포넌트 + 애드온의 확장세트들을 위한 가능성을 열어줄 수 있지 않을까 합니다.
5. ZBXE의 모든 게시물/위키문서가 개별적인 퍼머링크를 가질 수 있는것은 이미 팁을 통해 비슷한 내용이 공개된 것으로 알고 있지만, 이것이 코어에 편입되는것은 대환영입니다. 이것을 통해 비단 위키문서 뿐 아니라 게시물, 블로그포스트끼리 자기조직화가 된다면 아마 이상적인 형태가 아닐까 싶네요.
6. 이번에 이슈트래커 모듈을 제작하시면서 ZBXE용의 diff 함수를 만드신것으로 알고 있는데.. 대략 이쯤에서 '이제 위키에서 쓰이겠구나' 싶었는데.. 진짜로 그렇게 되었네요.. *^^* 히스토리 및 버젼컨트롤에 대해서는 이미 도출된 내용이 있기 때문에 큰 문제는 없을것으로 보고 있습니다. 기획문서중에서도 언급했듯.. history purge와 같은 부분에 대해서는 프로토타입에서 가능성만이라도 감안할 필요가 있을것으로 보고 있습니다. (해당 기획문서를 작성할 때엔 쓸모없는 리소스를 tar.z로 묶는 방법도 생각했지만, ZBXE가 리눅스뿐 아니라 윈도우서버에서도 작동하는것을 감안하면 문제가 있을듯 싶습니다.)
아직은 '위키' 자체가 생소한 도구이기 때문에 프로토타입이 나온 후에도 긴 시간동안 피드백이 있어야 할것으로 보고 있습니다만, 일단 제로보드XE의 공식 메뉴얼을 프로토타입의 위키모듈으로 대체하면서 라도 하나하나 고쳐나가면 충분히 좋아질 것으로 생각됩니다.
갑자기 예전에 제로님의 별명 중 하나였던 '제로머신'이 생각나버렸습니다.. ㅎㅎㅎ