아직 로그인하지 않았습니다. 로그인 또는 회원 등록을 해 주시기 바랍니다.
TNF : Tatter Network Foundation forum » daybreaker가 작성한 글
전에 inureyes 님이 punbb 좋다고 하시길래(?) 저도 깔아봤습니다.
벌써 phpbb에 비해 파일 개수며 용량 자체가 적더군요.
확실히 가볍고 정말 빠릅니다. 
http://metabbs.daybreaker.info/forum (포럼 - punbb)
http://dev.daybreaker.info/metabbs (개발센터 - 디자인 좀 바꿔봤습니다)
완전 태터툴즈 따라하기 시리즈로 가고 있습니다.;
그리고... inureyes 님의 스타급 센스를 모방하여..... 우주 시리즈로...쿨럭;;;; =3==3
흠.. <?php 부분은 우리가 따라 주는 게 좋습니다. 대신 코드에서 <?=$xxx?>와 같은 축약형 대신 <?php echo $xxx; ?>와 같이 써야 한다는 불편이 있지요.
그리고 mysql 부분도 표준대로 잘 따르면 좋겠습니다.
지금 당장은 못하지만 나중에 db backend 분리가 잘 되면, mysql ~3.x/4.0.x/4.1.x~ 정도로 버전을 나누어서 만드는 게 안정성 측면에서 도움이 될 것 같네요.
어딘가에 버전을 저장해서 자동으로 체크업을 할 수 있도록 하면 될 것 같군요.
공지사항이나 새 기능 소개도 간단히 해주고.. 그렇게 하는 게 좋겠습니다.
오오오, 좋습니다!!
저는 이번 7회 코드페스트에 MetaBBS로 참가할 예정입니다. 그때 같이 뵐 수 있었으면 좋겠군요.
ps. 보통 CodeFest에서는 IRC로 많이 대화를 나눕니다. (심지어 행사장 내에 있는 사람들끼리도...) 행사 기간 동안 HanIRC의 #codefest 공식 채널이 열리니 그쪽으로 오시면 됩니다. (IRC는 Internet Relay Chat의 약자로 일종의 채팅 프로토콜입니다. 서버에 들어가서 채널을 만들어 대화방처럼 운영할 수 있지요. 서버 접속은 사실상 익명입니다. nick만 적으면 됩니다. HanIRC의 경우 사용자 등록을 하면 채널 유지용 봇 등 약간의 부가서비스를 더 받을 수 있습니다.)
우선 티켓 #67 자체에 한하여 진행되었으면 합니다. 모률화나 객체화로 확장하게 되면 버그 레벨이 너무 높아집니다.
네. 당장 하기는 무립니다. -_-;
글을 수정하는 사이에 답글들이 또 달렸군요;)
태터툴즈도 Data Component들이 model을 구현하고 있기 때문에 그쪽으로 맞춰서 개발하는 것이 좋겠지요.
model이 여러 종류가 존재하는 현재의 태터툴즈 형태더라도, db query 부분을 각 모델별로 따로 모아둔다면 여러모로 편리할 거라 생각합닙다.
(각 model 별로 db query 넣는 부분들이 있는데, 이러한 model들 자체를 dbms 별로 각기 구현할 수 있을 정도로―실제 그렇게 하진 않더라도―해둔다면 db 관련 문제에 보다 쉽게 대처할 수 있지 않을까요?)
저 무식해서 죄송한데.. DB모듈화가 무엇입니까 ?? 흑 ~
현재는 MySQL query 문들이 코드 중간중간에 직접 들어가 있지요. mysql 입출력 함수만을 따로 모아서 클래스로 만든 다음, 현재의 query 문들을 모두 이걸로 대체하는 겁니다.
예를 들면
class MySQL extends DB {
...
}
$mysqlDB = new MySQL();
$mysqlDB->connect("server", "id", "password");
$mysqlDB->select_db("dbname");
$mysqlDB->select_table("tablename");
$mysqlDB->count_rows("condition");
$mysqlDB->find_all("condition", "orderby", offset, limit);
$mysqlDB->insert("valuearray");
...
과 같은 겁니다. 잘 응용하면 mysql을 쓰지 않는 file db 형태로 할 수도 있습니다. (MetaBBS가 이런 방식입니다. dbname.php마다 MySQLAdapter와 같은 클래스가 있고, 이 클래스를 이용하는 model_* 이름의 함수들이 있어서 통일된 인터페이스를 제공하고 있지요.)
그러면 mysql 관련한 문제가 발생했을 때 그 클래스 하나만 수정하면 되니까 전체 코드를 다 건드려야 하는 일이 없어지고, 또한 mysql 뿐만이 아니라 postgresql, sqlite 등 다른 종류의 DBMS를 사용할 수 있도록 컨버팅하는 것도 매우 쉬워집니다.
하지만 거기까지 이르기 위해서는 정말 엄청나게 많이 뜯어고쳐야 할 겁니다. (특히 다중 backend를 지원한다면 설치 UI 쪽도 변경이 될 필요가 있지요)
여기서 trac 쓰는 거 보고 이런 시스템이 있어야겠다는 생각이 들어서 설치해봤습니다.
http://dev.daybreaker.info:1729/metabbs
포트를 일반 http 80으로도 쓸 수 있게 하면 좋겠는데 거기는 나중에..-_-;
ps. 어쩌면 PunBB를 설치할지도 모릅니다. =3=3=3
옵션으로 넣는 것도 괜찮을 듯합니다. (점점 옵션만 많아지는군요.. orz)
저도 루트가 아닌 하위 디렉토리에 넣고 사용하고 있습니다만 별도 .htaccess 등을 사용하는 다른 디렉토리 등에서도 전혀 문제가 발생하지 않고 있습니다.
.htaccess가 남아 있지 않은지 확인해보시면 될 것 같습니다.
태그 중간에 콤마를 넣고 싶다면 ""으로 태그를 묶어서 입력하게 하고, 그렇지 않았을 때의 콤마는 explode로 처리하는 건 어떨까요?
전 TT 의 노력으로 최대한 '웹표준' 이라는것의 걸음은 맞추려고 노력하시는것 멋지다고 생각됩니다. 그래서 1.1의 준수까지 가시는거 막지는 않습니다만 제 경험에 의하면 노력에 비해 결과는 별로라고 생각하고 있습니다. 제 홈같은 단순한 집에서야 1.1이 괜찮긴 합니다만,, 1.0 tradition 에도 감격이라고 말씀드리고 싶네요. 위에서 언급하셨듯이 문서와 프레젠테이션 분리는 필요하겠으나 너무 집착때문에 머리털이 빠지시면 "마이너스"라고 생각됩니다.
저도 그렇게 막 집착하고 싶지는 않습니다. 그래도 완벽한 validation을 원하는 분들이 있기 때문에, 툴 수준에서는 지켜주면 좋지 않겠나 하는 것이지요. 쩝.. 빈 ol 태그와 빈 ul 태그 같은 문제는 그냥 넘어가야 할 것 같습니다. -_-a 말씀마따나 이 잡다가 초가삼간 태우는 격이 될 것 같다는...;;
덧붙이자면,,
daybreaker 님께서 생각하시는 각각의 ul 에 id 를 주시는건 음,,, 정말 정교한 디자인을 원하시는 유저가 아니라면 솔직히는 필요없다고 생각이 됩니다. 그리고 그럴만한 이유도 적다고 생각이 됩니다. 카테고리 부분은 어느정도 패턴이 동일해야 되기 때문에 그정도의 부분까지 한다면 오히려 역효과가 나올수도 있겠네요.일단 카테고리 제어가 CSS 에서
메인 카테고리 선택 에는 #category_list ul li {어쩌구} 와
sub 카테고리 선택에는 #category_list ul li ul li {어쩌구}
로 선택이 가능하니 일단은 큰 어려움은 없다고 생각이 됩니다.
사실 저도 이렇게까지 id를 주어야 하나 하는 생각이 듭니다. 하지만 나니 님의 경우는 그걸 강력히(?) 원하시는 유저시기 때문에..-_-; 그래서 li 까지 주지는 않더라도 ul 정도까지는 괜찮지 않을까 하는 생각입니다. (사실 이것도 CSS 3에 있는 n-th element selector가 나온다면 필요 없어질 텐데 말이죠 -_- 생각 같아서는 CSS3나 CSS4 정도에서 정규표현식을 이용한 태그 속성 검색까지 해준다면 얼마나 좋을까 한다는...)
일단 category_list 치환자를 썼을 때 div id="categoryList"로 감싸주는 것이 필요하겠네요.
하지만 나니 님이 말씀하신 것처럼 카테고리별로 다른 디자인을 주기 위해서는 ul 별로 id를 주어야 할 것 같습니다
니들웍스 
<div id="box">
<div id="categoryList">
<ul id="category1">
...
<ul id="category1_1">...</ul>
<ul id="category1_2">...</ul>
...
</ul>
<ul id="category2">...</ul>
</div>
</div>기존 테이블 방식의 Tree Skin을 사용하려면 태터툴즈가 style 속성을 직접 넣어주거나 php로 생성한 css 파일을 포함시킬 수 있겠군요. 그렇지만 이 경우 스킨에서 정의할 수 있도록 옵션을 줘야 할 것 갈습니다.
원문을 읽어보았습니다.
그래서 태터툴즈 운영자의 친절한 답변에 따라 친절히 category_list 치환자를 써 보았어.
근데 여기서 또 발생하는 문제가 단순히 ul, li 만 사용함으로 인해
엄청나게 디자인이 컨추리해지는거야. 그래서 ul, li태그에 각각 따로
ㅡ 각각의 서브 카테고리에 서로 다른 캐스캐딩을 주어서 꾸미고 싶어서 ㅡ
class나 id 애트리뷰트를 추가하게 하면 안되겠느냐,고
또 문의를 했는데 이번엔 철저히 씹혔고.
이 부분은 반영할 수 있도록 노력하겠습니다.
사실 저도 "있지도 않은 애트리뷰트를 써야 하는가" 하는 부분은 어떻게 결론 지어야 할 지 모르겠습니다. 표준 준수를 위해서라면 안 쓰는 게 맞겠지요. HTML이 아닌 XML이라면 쉽게 가능하겠지만 기반이 HTML인 이상 custom attribute로 인한 오류는 어쩔 수가 없는 부분이라 생각됩니다.
애초부터 해당 속성을 사용하지 않는 방법이 있을런지는 잘 모르겠지만, input type="hidden" 같은 걸 쓰면 해결할 수 있을 것도 같습니다. (input 태그가 form 태그 안에 있지 않아도 validation이 됩니다. 다만 태터 자체의 작동에 영향이 없도록 해야겠죠.)
그리고, favicon을 표시하는 부분의 onerror 속성 문제.. 이건 참 난감하지요. 아직 저도 뚜렷한 해결책은 잘 모르겠습니다. -_-; 좀더 자료 조사를 해봐야겠네요.
ps. 하지만 현재의 category list로도 ul, li를 적절히 중복시킨 selector를 이용하면 원하는 디자인 구현에 큰 문제는 없을 것 같은데... 이 부분은 직접 테스트보겠습니다. -> 아, 각 서브카테고리별로 다른 디자인을 주고 싶다면 id, class가 필요하겠군요.;
흠...
저도 처음에는 validator 통과를 상당히 자랑스럽게 여기는 쪽이었습니다만, 요즘은 그렇게 엄격하게 생각지는 않습니다. (뭐 그 당시 습관이 그대로 남아서 제가 직접 짜는 php, xhtml 코드들은 웬만하면 다 통과가 됩니다만...-_-) 그저 웹브라우저가 해석하는 데 문제가 없다는 걸 보장해주는 정도로만 생각하고 있습니다. (그러나 항상 문제는 IE 때문에 발생하지요.. orz)
태터툴즈의 경우는 inureyes 님의 말처럼, 표준을 별로 개의치 않는 분과 함께 표준을 매우 중요시 여기는 분들을 모두 만족시키기 위해선 태터툴즈의 기본 틀이라도 표준을 준수하는 방향이 옳다고 생각합니다.
일단 현재는 XHTML 1.0 Transitional입니다만, Strict까지 가는 건 손을 상당히 봐야 할 겁니다. sandbox 실험본을 가지고 기본 스킨을 적용한 상태에서 태터툴즈 자체의 코드에 의해 발생하는 문제점들 위주로 편집을 해보겠습니다.
ps. 하지만 전 내용과 디자인의 분리는 되도록이면 지켜졌으면 좋겠다고 생각합니다. 물론 스킨 시스템이라는 것이 있어서 스킨을 어떻게 만드느냐에 따라 달라지지요. 태터툴즈 그 자체로 봐서는 꽤 잘 지켜졌다고 생각이 되구요(관리자 화면만 제외하면), 문제는 스킨을 어떻게 만드느냐겠지요.
학교하고는 관계 없구요, IRC를 통해 알게 된 사람들과 진행하고 있습니다.
학교 동아리 스팍스에서 진행하고 있는 프로젝트가 OCO이며 이올린 플랫폼을 활용하려고 생각 중입니다.
ps. 그리고 MetaBBS의 경우는 코어가 태터툴즈하고 완전히 다릅니다. 처음 설계부터 DB 백엔드를 분리하였고, 다른 보드 프로그램들에 비해서 작고 가볍게 만들고 있지요. 물론 기술적인 부분에서 태터툴즈의 소스로부터 도움을 받을 수 있는 부분들은 존재하겠지요.
사실 보드 프로그램도 근본적으로 블로그와 별반 다를 게 없지요.
MetaBBS의 경우는 스킨 템플릿을 통해서 블로그 형태로도 쓸 수 있고 보드 형태로도 쓸 수 있게끔 하려고 생각 중입니다.
태터의 본뜻에 맞게, 손으로 털옷 짜는 모습을 아이콘화하는 건 어떨까요? 잘만 하면 알파벳 T하고도 뭔가 연관시킬 수 있을 것 같은데..
제 웹호스팅 서버에 설치한 태터툴즈 1.0.4 버전은 전혀 문제가 없는데요, localhost에 설치한 1.0.x trunk 버전은 스킨 선택 화면의 한글 내용이 모두 깨집니다. (물음표로 나옵니다)
다른 특별한 이유가 있어서 그런 건지, 아니면 다른 분들도 이런 현상을 겪고 있는 경우가 있는지요?
이제 슬슬 제가 맡은 티켓들에 대한 코딩을 시작해보려고 합니다.
우선 XHTML 표준 준수 강화 부분이 있겠는데요.. 관리자 화면이 가장 오류가 많으나 이 부분은 애초부터 구조를 다 뜯어고쳐야 하는 데다 php 파일 자체에 inline html 코딩이 되어 있어 잘못 건드렸다가는 관리자 화면이 와장창 깨질 우려가 있기 때문에... 좀 더 두고 봐야겠습니다. (소스 구조를 완전히 파악하면 대수술을 감행해야 할 듯...orz)
일단 기본 스킨으로 XHTML Validation을 해봤습니다.
계속 그동안 개선이 되어서인지 생각보다 오류가 없더군요. 몇 가지 나타난 오류들은,
1. <ol></ol>, <ul></ul> 사이에 아무 내용이 없어서 end tag is undefined 오류 발생
2. 테이블 방식의 카테고리 트리 출력 시 사용되지만 표준에는 없는 "currentselectednode", "name" 속성
가 있었습니다.
1번의 경우는 스킨 치환자 자체 구조 상 해결이 불가능해보입니다. 트랙백 목록, 코멘트 목록 등에서 나타나는 문제인데 트랙백이나 코멘트가 없을 경우
<ol>
<s_rp_rep>
....
</s_rp_rep>
</ol>
형태에서 <s_rp_rep></s_rp_rep>으로 묶인 부분에 아무런 태그가 출력되지 않는데 ol 태그는 언제나 출력이 되기 때문입니다. 그렇다고 치환자 바깥의 태그를 자동으로 인식해서 없애준다든가... 이런 것도 거의 불가능하겠지요.
이 오류를 고칠 수 있다면 좋겠지만 스킨 구조를 뜯어고치지 않는 이상 불가능합니다. 한편 이거 하나 고치려고 그렇게 다 뜯어고치는 건 불필요하다는 생각도 듭니다만 또 validation이 깔끔하게 안 되니 좀 걸리기도 하네요.
2번의 경우는 lib/view/view.php의 printTreeView 함수와 관련이 있습니다. 태그에 custom 속성을 넣은 거라고 볼 수 있는데.. 이 부분은 현재 그대로 두는 게 나을 것 같습니다. 정말 validation을 해야겠다 싶은 분은 스킨을 수정해서 [##_category_list_##]를 쓰면 되겠지요.
일단 XHTML Validation 외에 javascript 쪽과 css의 사소한 오류들을 조금 고치겠습니다.
다음 주 월, 수요일까지 듀인 숙제들이 상당히 많기는 하지만 XHTML Specification 만족을 위한 간단한 코딩부터 슬슬 시작해보도록 하겠습니다.
아무래도 몇몇 티켓은 다음 버전으로 미뤄야 할지도 모르겠군요. orz
"Ticket Fixing 기간에 처리되지 못한 ticket들"이라고 하셨는데, 그러면 ticket fixing이 끝나기 전까지 해당 ticket에 대한 코딩 작업을 완료해야 한다는 뜻인지요? 조금 더 구체적으로 말씀해주셨으면 좋겠습니다..
음.. 위키백과 활동을 열심히 하시는 분인 Puzzlet 님이 태터 홈페이지에 올리신 걸 봤는데요.. 질문글에 GPL이라고만 쓰셔서 의도가 전달이 제대로 안 된 것 같아서 여기에 제가 다시 여쭤봅니다.
그분은 태터툴즈 로고를 GFDL(GNU Free Dcoument License)로 쓸 수 있는지가 궁금하신 것 같습니다. 위키백과 등에 자료를 올리려면 GFDL을 만족해야 하거든요. 그렇다고 그 로고를 상업적으로 이용하거나 하는 건 아닙니다.
저도 그 라이센스의 세부 조항은 잘 모르겠습니다만, 태터툴즈 로고에 적용이 가능한지 궁금합니다.
TNF : Tatter Network Foundation forum » daybreaker가 작성한 글