앞의 글을 읽지 않으셨다면 반드시 앞의 글을 먼저 보시길 추천합니다. :)
앞의 글에서 보았던 구조를 한 번 더 복잡하게 뒤집어 봅시다.
굉장히 복잡해 보이지만 시계 방향으로 돌아가는 흐름을 감지하실 수 있을 것입니다. rewrite -> interface -> view -> skin -> browser로 이어지는 흐름을 '지하철 2호선' 에 비유하면 나머지 지하철들도 점차 보이실겁니다. 주 흐름에 대해서는 앞의 글에서 대충 설명했으니 이번에는 이 그림에 추가된 부분들을 보도록 하지요.
컴포넌트의 storage binder는 실제로 데이터를 저장하는 부분입니다. 태터툴즈 1.1부터 차츰 추상화의 길을 걷고 있지만 아직 최종적인 목표까지는 요원합니다. component 디렉토리 안에 텍스트큐브에서 사용되는 데이터 객체들이 지정되어 있고, 그 객체들은 Eolin.PHP.Core 안의 DBQuery 클래스를 사용하여 데이터 베이스 입출력이나 파일 입출력을 시도합니다. 대부분의 데이터 객체들은 Textcube.data 라는 시작 이름을 가지고 있지만, 1.5부터 추가된 캐시 모듈의 경우에는 데이터 객체가 아니라 긴 시간을 갖는 버퍼이기 때문에 Needlworks.Cache.PageCache 에 위치하고 있습니다.
그러면 각 부분의 소스를 어디서 찾을 수 있는지 한 번 볼까요?
각 부분에 해당되는 파일들이 어디에 위치하고 있는지 일목요연하게 볼 수 있는 도표입니다. 이젠 더 복잡하게 그릴 자리도 남아있지가 않기 때문에 이정도로 정리가 되겠습니다. 이 도표가 '실제 기능 순서' 대로 그려져 있기 때문에 이번에는 디렉토리 구조를 중심으로 위의 그림을 다시 그려 보겠습니다.
위의 그림을 다 쪼개 놓은 후에 디렉토리 구조대로 뭘 하는지 적어놓은 도표입니다.
위의 설명까지 읽으면 감이 잡히는 경우와 잡히지 않는 경우가 있을겁니다. 공부라는 것이 으레 그렇듯이, 이론만 열심히 한다고 이해되는 경우는 드물지요. 실제와의 차이가 상당히 있기 때문에 그걸 좁혀 나가려면 역시 연습문제 밖에 방법이 없습니다.
PHP/MySQL을 좀 아는데 그래도 위의 설명들이 전부 외계어 처럼 보이신다고요? 그러한 경우를 위해서 '뜯어보는 순서'를 적어보도록 하겠습니다.
1. 경우에 따라 같은 기능을 하는 함수가 /lib/model에도 구현되어 있고 /components 에도 구현되어 있습니다.
이러한 부분은 텍스트큐브의 역사에서 비롯됩니다. 1.1 마일스톤까지 사용하던 최적화 프로그램 때문에, 최적화 프로그램으로 소스를 처리한 이후에는 lib 디렉토리가 사라집니다. 이러한 경우 플러그인이나 백업/복원 등에서 해당 기능을 하는 함수들을 사용하기 위해서 컴포넌트가 만들어 졌습니다. 현재는 전체적인 기능을 컴포넌트 쪽으로 이전해 나가는 중입니다.
2. 데이터베이스에 날리는 쿼리 형태가 여러가지가 있습니다.
데이터베이스 접근의 추상화가 진행되고 있기 때문입니다. 이를 위하여 최종적으로는 TableQuery class의 확장형을 사용할 예정입니다. 현재는 mysql_ 형태의 php 내장 함수를 바로 사용하는 부분과, DBQuery 클래스를 사용하는 부분이 대다수, TableQuery의 프로토타입을 사용하는 경우가 소수 존재합니다. 쿼리를 날리는 방법이 여러 부분에 걸쳐 다르기 때문에 혼동을 일으킬 수 있으므로, 가급적이면 변화의 중간 형태로 도입된 DBQuery 클래스를 사용하시기 바랍니다.
이상으로 간단하게나마 텍스트큐브 구조를 훑어 보았습니다. 소스 고치기에 도움이 되셨으면 좋겠네요. 다음 코어 드릴러는 Eolin.PHP.Core에 관한 간단한 설명들이 될 예정입니다.
(0) 
(0)
실제 구조
앞의 글에서 보았던 구조를 한 번 더 복잡하게 뒤집어 봅시다.
앞 글의 마지막 그림보다 살짝 복잡해 졌습니다. 이상과 실제 구현의 차이란 이렇게 나는 것이기도 합니다.
컴포넌트의 storage binder는 실제로 데이터를 저장하는 부분입니다. 태터툴즈 1.1부터 차츰 추상화의 길을 걷고 있지만 아직 최종적인 목표까지는 요원합니다. component 디렉토리 안에 텍스트큐브에서 사용되는 데이터 객체들이 지정되어 있고, 그 객체들은 Eolin.PHP.Core 안의 DBQuery 클래스를 사용하여 데이터 베이스 입출력이나 파일 입출력을 시도합니다. 대부분의 데이터 객체들은 Textcube.data 라는 시작 이름을 가지고 있지만, 1.5부터 추가된 캐시 모듈의 경우에는 데이터 객체가 아니라 긴 시간을 갖는 버퍼이기 때문에 Needlworks.Cache.PageCache 에 위치하고 있습니다.
그러면 각 부분의 소스를 어디서 찾을 수 있는지 한 번 볼까요?
구조와 소스의 대응
앞의 글을 잘 읽으셨다면 대충 이제 감이 오실 수도 있을 시점이긴 합니다만...
어느 디렉토리가 어디에 해당되는지 좀 보이시나요?
외계어?
위의 설명까지 읽으면 감이 잡히는 경우와 잡히지 않는 경우가 있을겁니다. 공부라는 것이 으레 그렇듯이, 이론만 열심히 한다고 이해되는 경우는 드물지요. 실제와의 차이가 상당히 있기 때문에 그걸 좁혀 나가려면 역시 연습문제 밖에 방법이 없습니다.
소스 보기 팁
PHP/MySQL을 좀 아는데 그래도 위의 설명들이 전부 외계어 처럼 보이신다고요? 그러한 경우를 위해서 '뜯어보는 순서'를 적어보도록 하겠습니다.
- 인터페이스를 고치고 싶으시면 /blog 디렉토리를 보세요.
- 함수의 기능을 추적하고 싶으면 /lib/model 에서 시작합니다.
- 출력되는 형태를 바꾸고 싶으면 /lib/view를 수정합니다.
- 블로그나 관리자 화면의 아웃라인을 바꾸고 싶으면 /lib/piece를 봅니다.
- 플러그인에 특화된 기능이나 들여오기/내보내기를 수정하고 싶으면 /components를 봅니다.
- EAF의 동작이나 AJAX 구현을 공부하거나 수정하고 싶으면 /scripts를 봅니다.
텍스트큐브 1.5 소스에서 꼭 알아두어야 하는 점!
1. 경우에 따라 같은 기능을 하는 함수가 /lib/model에도 구현되어 있고 /components 에도 구현되어 있습니다.
이러한 부분은 텍스트큐브의 역사에서 비롯됩니다. 1.1 마일스톤까지 사용하던 최적화 프로그램 때문에, 최적화 프로그램으로 소스를 처리한 이후에는 lib 디렉토리가 사라집니다. 이러한 경우 플러그인이나 백업/복원 등에서 해당 기능을 하는 함수들을 사용하기 위해서 컴포넌트가 만들어 졌습니다. 현재는 전체적인 기능을 컴포넌트 쪽으로 이전해 나가는 중입니다.
2. 데이터베이스에 날리는 쿼리 형태가 여러가지가 있습니다.
데이터베이스 접근의 추상화가 진행되고 있기 때문입니다. 이를 위하여 최종적으로는 TableQuery class의 확장형을 사용할 예정입니다. 현재는 mysql_ 형태의 php 내장 함수를 바로 사용하는 부분과, DBQuery 클래스를 사용하는 부분이 대다수, TableQuery의 프로토타입을 사용하는 경우가 소수 존재합니다. 쿼리를 날리는 방법이 여러 부분에 걸쳐 다르기 때문에 혼동을 일으킬 수 있으므로, 가급적이면 변화의 중간 형태로 도입된 DBQuery 클래스를 사용하시기 바랍니다.
이상으로 간단하게나마 텍스트큐브 구조를 훑어 보았습니다. 소스 고치기에 도움이 되셨으면 좋겠네요. 다음 코어 드릴러는 Eolin.PHP.Core에 관한 간단한 설명들이 될 예정입니다.
(0) (0)Trackback URL : http://howto.textcube.org/trackback/11
