아직 로그인하지 않았습니다. 로그인 또는 회원 등록을 해 주시기 바랍니다.
TNF : Tatter Network Foundation forum » Peris가 작성한 글
네 정확히 이러한 집단지성을 활용한 방안으로 스팸필터링을 준비하고 있습니다.
대부분의 협업기반 스팸필터링 방식이 이러한 방식을 사용하고 있지요 ^^다수의 사람들이 나쁜놈이라고 하는 놈은 정말 나쁜놈이다.
뭐 이런 원칙이라는..
그럴리야 없겠지만 주인장이 쓴 글에는 안붙도록 해주세요.
방문자들이 주인장 글 필터링 해버리면 난감;
(반은 농담이예요 )
아.. 여기다가 참석 희망이라고 써야되는거였나요;;
일단 저도 참석 희망입니다.
음 잘 몰라서 여쭈어봅니다
getElementsByName 은 모든 브라우저에서 호환되는데, this. 속성은 어떤가요?어디에선가 (아마 W3C 권고안이었던듯?) 최대한 this. 속성을 쓰는 것을 자제하라는 글을 본 적이 있어서요^^;
헛 W3C에 그런 내용이 있었나요?;;
근데 this를 못쓰게된다면 자바스크립트를 사용하는데 상당한 애로사항이 있을거 같네요.;
좀 찾아봐야겠네요.
일단 제가 알고 있는 브라우저에서는 다되긴 합니다.(몇 개 되지도 않지만요;; )
음.. 도저히 못찾겠네요. OTL
혹시 어디있는지 아시면 저에게도 알려주세요. 흑;;
<input type="text" name="search" value="" onkeypress="if (event.keyCode == 13) { try{window.location.href='/search/' + document.getElementsByName('search')[0].value.replace('%', '%25'); return false;}catch(e){} }" class="sinput" />
현재 검색창은 저렇게 되어있는데 아래와 같이 수정하는게 맞을거 같습니다.
<input type="text" name="search" value="" onkeypress="if (event.keyCode == 13) { try{window.location.href='/search/' + this.value.replace('%', '%25'); return false;}catch(e){} }" class="sinput" />
아시겠지만 name 속성의 값은 중복이 되어도 상관이 없기때문에
저 코드가 나오기 전에 이미 name="search" 를 쓴 경우 검색이 안되는 일이 발생합니다.
게다가 getElementsByName을 사용하는 것보다 this를 사용하는게 더 자바스크립트 다운것 같고요.
MySQL 이 유니코드 지원을 하기 시작한게 4.1 부터이지 않나요 ??
그리 말씀하시니 헥갈리는데용.. ㅠ.ㅠ
4.1.x 맞습니다.
아이디어는 아니고 의견쯤 되는거 같은데 마땅히 적을 곳이 없군요(버그는 아니니..)
IE 설계변경에 따라 태터에서도 수정을 해줘야 하지 않을까라는 생각에 적어봅니다.
일반 유저의 경우 이런 것에 대해 알고 있을 가능성이 매우 적은 상황에서
당연히 예전과 같은 방식으로 동작이 될거라 생각할꺼라 생각합니다.(말이 꼬이는군요.; )
따라서 IE 패치가 적용된 상황에서도 예전과 같은 방식으로 동작되게 할 필요성이 있을거 같습니다.
자세한 내용은 아래를 참고 해보세요.
그럴 수도 있겠지만 현재 태터툴즈 홈페이지의 경우라면 header나 footer등을 이중으로 작성할 경우는
태터툴즈 매뉴얼하고 자주묻는 질문 밖에 없는거 같네요.
MySQL에 이미 들어가 있는 데이터도 dump받아서 문자셋만 수정해서 덮으면 되니까요.(귀찮기야 하겠지만 -_-)
뭐 이미 다 utf-8로 바꿔두셨는데 이제와서 다시 바꿀려면 여러모로 짜증나긴 하겠군요.;
며칠 전에 제 블로그에 작성한 글이 있었는데 도움이 될려나 모르겠군요.
http://rsef.net/tt/entry/UTF-8-서버에서-제로보 … ard-41-pl8
euc-kr 환경에서 제작된 것을 억지도 utf-8로 바꾸다가 생긴 문제니
그냥 euc-kr로 보게 만들어버리자는 생각으로 해놓은 거예요.;
딱히 utf-8이어야 될 이유도 없고요.
http://rsef.net/zboard/zboard.php?id=peris
테스트는 여기서 해보세요.
(아 물론 utf-8 환경의 서버입니다.)
blog/suggest/index.php 파일에 GET으로 filter 값을 넘겨주는데
그 값이 아래와 같은 형식으로 넘어가더군요.
filter=name%20like%20'%ED%83%9C%25'
파일을 열어서 보니
$filter=isset($_GET['filter'])?$_GET['filter']:'1';
만 해주고 바로 쿼리에 포함되어 버리던데..
당장 문제가 될만한 쿼리는 생각이 안나긴 하지만;
앞으로도 위험을 수반할 수 있는 방법이라고 생각되네요.
수정하셔야되지 않을까 싶어서 써봅니다.
저도 처음에 그 생각을 했었는데, 그 경우 백업기능 사용시 플러그인의 환경설정 백업 문제가 있더군요.
또한 파일입출력을 위해서 플러그인 디렉토리에 쓰기권한을 주는 것이 위험하기도 할 겁니다.
제 생각에 백업같은 경우는 이렇게 하기로 결정만 난다면 별로 무리가 없을 거 같습니다.
(제가 다른 글에 적었듯이 플러그인까지 함께 백업 받아버리면 끝! 이니까요; )
파일입출력을 한다고 쓰신건 정확히 어느 시점을 말씀하시는건지 이해가 잘 안되서; 제가 이해한게 맞는지는 모르겠지만,
다른 글에 적혀있는 superuser 개념이 생긴다면 역시 큰 문제가 되진 않을거 같네요.
* 플러그인 아키텍처 개선
* 환경 설정 및 백업 지원
* 자동 업데이트 지원
* 관리자 화면용 플러그인 구조 추가 및 일반적인 태터툴즈에 적용되는 플러그인 구조와의 분리
* 관리자용 플러그인의 예) DB 정리기능, 모든 첨부파일 다운로드하기 기능, PDF 변환 기능 등.* DB 독립적 구조
* mySQL이 아닌 다른 SQL (postgresql, sqllite) 에서도 사용할 수 있도록 쿼리루틴의 모듈화 및 분리.
* 이 경우 SQL의 버전 차이나 SQL의 종류 차이에 의한 다양한 호환성 문제를 태터툴즈 전체를 수정해야 하는 상황에서 모듈의 개선 문제로 완전히 분리할 수 있음.
.tar 이나 .zip 등으로 전체 백업 기능도 한번 생각해보면 어떨까요?
플러그인이나 스킨을 이것저것 사용하는데 data만 백업받는다고 백업이 다 된건 아니니까요.
그리고 플러그인을 만들다보면 이미 태터에 구현이 되어있는 부분을 복사 or 새로 제작하는 경우가 있습니다.
꼭 DB 만이 아니더라도 그런 부분들을 재사용할 수 있도록 따로 떼어내야되지 않을까라고 생각합니다.
(iconvWrapper 함수 등등)
2.링크를 새 창으로 띄우도록 해주세요
태터 1.0이 W3C표준을 지키려는 의지는 알지만, 유저의 불편함을 감수 하면서 까지 지킬 필요가 있나 의문이 듭니다.
프래임이 없어지면서 존재할 이유가 없어진 target으로 새창을 띄울수 없다면, 스크립트를 제공해 글안에 포함되는 링크는 새창으로 좀 띄울 수 있도록 해 주었으면 합니다.지금 태터는 하이퍼링크를 삽입할때 대화창이 뜨는데, 그 곳에 새창으로 띄울지 여부를 묻는 채크박스 하나를 집어 넣어주면 안되겠니~? (개콘 생활 백수 버젼^^)
물론 새창이 디폴트..(FF유저의 경우 새창으로 뜨면 불편하다는 분도 있으신데, Tab Preference같은 익스텐션으로 충분히 설정이 가능하니 문제가 안된다고 생각합니다)
=========================
2번의 경우 웹표준에 예민하신 분들이 반발 하실수도 있지만, target="_blank"가 아닌 onclick="return openLinkInNewWindow(this)" 식으로 대처 할 수 있을것 같습니다.
새창으로 띄우는 문제는 간단한 플러그인으로도 처리가 가능할거 같은데요.
(뭐 옵션이 생기면야 더 좋겠지만..)
그리고 웹표준 얘기가 나오니 생각난건데 다음 버전에서는
카테고리에 사용하는 currentselectednode 속성을 다른 걸로 대체해 주셨으면 하네요.;;
(이 것 때문에 일부러 list 형식으로 사용하시는 분도 본..)
뭐 중요한 것도, 어려운 것도 아니라서 쓰기도 민망합니다만..;;
위키매뉴얼 / 태터툴즈 소개 에서 좌측 상단의 로고 링크가 잘못 걸려있네요. -_-;;
ps. 제로보드하고 위키하고 막 섞여있어서 헷갈리네요.;;
물론 이 일은 플러그인 자체에 문제가 없다는 전제하에 이루어져야 되는 작업이라고 생각되네요.
(하지만 사람을 거치지않고 플러그인 자체에 문제가 없다고 단정을 지을 방법이 과연 있을까요?)
현재의 플러그인 제작 방식은 플러그인 제작자가 마음만 먹으면 무슨 짓이든 할 수 있기때문에 상당히 위험하니까요.;
현재의 배포 방식이라고 해서 위와같은 문제를 해결할 수는 없다는게 가장 큰 문제겠지만요.
구현 자체는 규칙만 정확하게 압축되어 있다면야 (플러그인 디렉토리까지 압축되어 있어야겠죠?) 그다지 어려울 것은 없을겁니다. 그런데 현재의 플러그인 설치 구조로는 인스톨 / 언인스톨 시에 php의 system함수를 사용해야 할텐데, 이 함수가 보안에 쥐약입니다. fopen으로 대체해서 압축 풀기가 가능한지는 아직 안해봐서 모르겠네요.
예전에 php로 직접 파일을 만들어 쓰거나 경로 이동하고 복사하는 프로그램을 짜야 할 일이 있었는데, 당시엔 그냥 @system함수로 긁었었더랩니다. (...)
http://kr.php.net/manual/kr/ref.zip.php
위 주소의 아래 User Contributed Notes를 보면 unzip을 구현해 놓은 것을 볼 수 있습니다.
(물론 system 등의 Program Execution 함수를 사용하지 않고요.)
근데.. 생각해보니 저것도 PHP를 --with-zip=DIR 옵션을 주고 컴파일을 했어야 되는군요.;
정 안되면 직접 구현을..(누가?...; )
.tar 는 구현되어있는게 있긴 하네요.;;
세 줄 요약입니다 :
* 플러그인의 환경설정이 가능하도록 지원해야 한다.
* 파일 입출력을 통한 플러그인 환경설정은 정말 비효율적이며 결국, 각 플러그인의 환경설정값은 sql에 들어가야 한다.
* 플러그인 아키텍처가 사용할 수 있는 필드를 유저별 sql 필드에 추가해야 하며, 그 값들은 백업시에 함께 저장되어야 한다.
저도 예전에 같은 생각을 했었습니다.
대신에 저는 sql이 아니라 개별 플러그인의 index.xml 파일에 추가가 되어야 한다고 생각합니다.
그렇게 된다면 태터 자체에서 어차피 index.xml 은 한번 읽기때문에 추가적인 부담도 줄일 수 있다고 생각하고요.
(배열로 받아두면 다중사용자일 경우 역시 문제 없겠죠?
방법은 대충 아래처럼 될거 같네요.
<plugin ~>
~
<setup owner="1">
<bgcolor>#000000</bgcolor>
~
</setup>
<setup owner="2">
<bgcolor>#FFFFFF</bgcolor>
~
</setup>
</plugin>
있는지도 모르고 왜 이런거 안만들지!! 하고 있었.. OTL
앞으로 재미있는거 많이 만들었으면 합니다.
TNF : Tatter Network Foundation forum » Peris가 작성한 글
니들웍스 