주제별 포럼 - 위키
글수 49
안녕하세요. 위키 프로젝트에 참여하게 된 윤현호라고 합니다.
잘 부탁드리겠습니다. :)
제가 위키 모듈을 만들기 위해 가장 고민을 많이 했던 부분이 위키 모듈에서 document 모듈을 사용할 것인가 하는 것이었습니다.
일반적인 위키 엔진에서는 하나의 페이지를 관리하기 위해 세가지 형태의 데이타가 필요합니다. 하나는 위키 문법으로 작성된 원본 페이지, 파서에 의해 파싱된 HTML 문서, 다른 하나는 원본 페이지의 변경 사항(history)을 가진 데이타입니다.
위키 모듈에서 document 모듈을 사용한다면, document 모듈에 어떤 정보를 저장할 것인가를 생각해봐야 할 것 같습니다. 제 생각에는 지금의 document 모듈을 생각한다면 파싱된 HTML 문서를 저장하는 것이 맞을 것 같습니다.
그렇다면 원본 페이지와 히스토리는 어떻게 저장을 할 것인가도 고민해봐야합니다.
새로운 DB 테이블을 쓸 것인가? 아니면 캐시 파일과 같이 파일 시스템을 사용할 것인가? 제 생각에는 따로 DB 테이블을 사용할 것이라면, 그냥 위키 페이지의 모든 정보를 관리하는 다른 모듈(예를 들어, wikipage 모듈)을 만들고, 이를 테이블을 통해 관리하는 것이 좋지 않을까 생각합니다.
위키 페이지의 경우에는 캐싱된 HTML 문서가 보여주는 순간에 항상 올바르다고 보장할 수 없습니다. 무슨 말인고 하니, 위키에서는 일반적으로 내부 문서를 링크하기 위한 위키 태그가 존재하고 보통 이 문서가 존재하는지 하지 않는지에 상관없이 위키 태그를 써서 내부 문서를 링크시킵니다. 만약 존재하지 않는 페이지라면 존재하지 않는 페이지라는 것을 표시해주고 이를 나중에 생성할 수 있도록 해주지요.
그런데, 캐싱된 HTML 문서에는 이런 정보를 저장할 수 없습니다. 위키 엔진에 따라 다르기는 하겠지만, 보통 위키 엔진들에서는 파싱된 문서는 시스템 성능을 위해 사용하는 것이지 이것이 주가 되는 경우는 없습니다.
물론 각 페이지별로 역링크된 페이지들의 정보를 저장시켜놓고, 만약 역링크된 문서가 생성 혹은 삭제된 경우에 원본 위키 페이지를 다시 파싱해서 HTML 문서로 저장시켜놓는 방법을 사용할 수도 있습니다.
document 모듈의 범용성을 생각한다면 이렇게 역링크된 페이지들의 정보를 document 모듈에 저장할 수도 있을 것입니다. 효율성을 생각한다면, 역시 따로 DB 테이블을 만들어서 관리하는 편이 낫겠지요.
물론 document 모듈의 범용성을 위해 위키 모듈에서도 document 모듈을 사용하기로 하고, document 모듈의 현재 기능을 차차 확장시킨다고 한다면, 이런 부분들을 고려해서 확장하면 될 것입니다.
아무튼, 위키 모듈의 기본 골격을 결정하기 위해서는 우선 위키 페이지를 저장하기 위해 어떤 방법을 사용할 것인가를 먼저 결정해야할 것 같습니다.
잘 부탁드리겠습니다. :)
제가 위키 모듈을 만들기 위해 가장 고민을 많이 했던 부분이 위키 모듈에서 document 모듈을 사용할 것인가 하는 것이었습니다.
일반적인 위키 엔진에서는 하나의 페이지를 관리하기 위해 세가지 형태의 데이타가 필요합니다. 하나는 위키 문법으로 작성된 원본 페이지, 파서에 의해 파싱된 HTML 문서, 다른 하나는 원본 페이지의 변경 사항(history)을 가진 데이타입니다.
위키 모듈에서 document 모듈을 사용한다면, document 모듈에 어떤 정보를 저장할 것인가를 생각해봐야 할 것 같습니다. 제 생각에는 지금의 document 모듈을 생각한다면 파싱된 HTML 문서를 저장하는 것이 맞을 것 같습니다.
그렇다면 원본 페이지와 히스토리는 어떻게 저장을 할 것인가도 고민해봐야합니다.
새로운 DB 테이블을 쓸 것인가? 아니면 캐시 파일과 같이 파일 시스템을 사용할 것인가? 제 생각에는 따로 DB 테이블을 사용할 것이라면, 그냥 위키 페이지의 모든 정보를 관리하는 다른 모듈(예를 들어, wikipage 모듈)을 만들고, 이를 테이블을 통해 관리하는 것이 좋지 않을까 생각합니다.
위키 페이지의 경우에는 캐싱된 HTML 문서가 보여주는 순간에 항상 올바르다고 보장할 수 없습니다. 무슨 말인고 하니, 위키에서는 일반적으로 내부 문서를 링크하기 위한 위키 태그가 존재하고 보통 이 문서가 존재하는지 하지 않는지에 상관없이 위키 태그를 써서 내부 문서를 링크시킵니다. 만약 존재하지 않는 페이지라면 존재하지 않는 페이지라는 것을 표시해주고 이를 나중에 생성할 수 있도록 해주지요.
그런데, 캐싱된 HTML 문서에는 이런 정보를 저장할 수 없습니다. 위키 엔진에 따라 다르기는 하겠지만, 보통 위키 엔진들에서는 파싱된 문서는 시스템 성능을 위해 사용하는 것이지 이것이 주가 되는 경우는 없습니다.
물론 각 페이지별로 역링크된 페이지들의 정보를 저장시켜놓고, 만약 역링크된 문서가 생성 혹은 삭제된 경우에 원본 위키 페이지를 다시 파싱해서 HTML 문서로 저장시켜놓는 방법을 사용할 수도 있습니다.
document 모듈의 범용성을 생각한다면 이렇게 역링크된 페이지들의 정보를 document 모듈에 저장할 수도 있을 것입니다. 효율성을 생각한다면, 역시 따로 DB 테이블을 만들어서 관리하는 편이 낫겠지요.
물론 document 모듈의 범용성을 위해 위키 모듈에서도 document 모듈을 사용하기로 하고, document 모듈의 현재 기능을 차차 확장시킨다고 한다면, 이런 부분들을 고려해서 확장하면 될 것입니다.
아무튼, 위키 모듈의 기본 골격을 결정하기 위해서는 우선 위키 페이지를 저장하기 위해 어떤 방법을 사용할 것인가를 먼저 결정해야할 것 같습니다.




먼저 커미터가 되신것 축하드리고 감사드립니다. ^^
음.. document 모듈의 경우 zbXE의 코어 모듈이라고 할 수 있습니다.
대부분의 모듈이나 위젯들이 document 모듈을 기반으로 하고 있고 url 생성시에도 document_srl이 key가 되어서 통일된 접근을 할 수 있거든요.
먼저 몇가지 제가 생각하고 있는 것을 말씀드리자면 현 document 모듈은 차후 구조적인 개편이 필요한 상황입니다.
예를 들어 하나의 컨텐츠에 다국어 지원을 위한 멀티 컨텐츠라든지 하나의 document(문서)에 다양한 형태의 확장 정보를 attach하기 위해서 현재의 document 모듈은 그 사용법과 확장성이 떨어지는 것이 사실이거든요.
이를 위해서는 먼저 DB가 중심이냐 혹은 object 중심이냐라는 것을 먼저 정해야 할 것 같습니다.
현재 document 모듈은 db중심이고 최대한 db 쿼리라든지 사용을 줄이기 위한 데이터 중심으로 만들어져 있습니다.
그래서 그 확장성과 활용성은 제한적이지만 퍼포먼스등에서 보다 좋은 구조입니다.
이를 확장 개편해서 document module의 object중심으로 구조를 변경하게 되면 DB의 정규화를 포기하는대신 다양하고 강력한 확장성을 가지게 될 수 있습니다.
말씀하신 범용성 역시 document를 object로 관리할 수 있게 되면 손쉽게 다양한 정보를 넣고 빼고 할 수 있을 것 같습니다.
다만 이렇게 될 경우 코드가 복잡해지고 퍼포먼스 측면에서 다소 포기해야 할 부분이 생길 수 있습니다.
그리고 object중심으로 완전 개편하게 될 경우 설계가 무척 중요하기에 개발 시간이 많이 필요하게 되고 또 이를 활용하기가 더 어려워질 수도 있습니다.
그래서 제가 생각하는 중재안은 현 document 모듈을 활용하되 wiki 자체적으로 확장정보를 가지는 것이 좋지 않을까 싶다는 것입니다.
위키문서 역시 기본적으로 제목과 내용이라는 기본틀을 벗어나지 못하기 때문에 이런 정보는 document 모듈을 활용하고 그 외의 document모듈에서 지원하지 않는 것은 자체적으로 table을 만들어서 활용하는 것이지요.
물론 wiki 모듈의 코드내에서 document + 확장정보를 사용하기 위해서 document 클래스를 wrapping하여 사용할 수도 있겠고 필요한 method내에서 구현만 해도 될 것 같기도 하구요.
현재 zbXE의 위제싱나 에디터 컴포넌트, 애드온등도 위키 모듈의 컨텐츠에서 바로 사용할 수 있도록 하는것이 중요하다고 생각하고 있고 이를 별도의 개발 비용 부담없이 하려면 document모듈을 이용해야 하기에 document 모듈을 기반으로 한 위키 모듈이 만들어지는게 좋다고 생각합니다. ^^;;;