오메.. 이거 클립해둬야겠는데. -ㅇ/

저도 일단 copy.. ^^

폰 브라우져가 좋아서 기본으로 되는게 아니었군요.. ^^;;

가끔 폰으로 태터 블로그 사이트들을 돌아다닌답니다.
폰에서 gif는 안 받아주는것 같아서 버튼을 깨지지만
왠만한 이미지들도 잘 나오고 글 보기에도 어렵지 않고.. ㅎ

..... 이게 뭔지 이해 못하고 있는 저로썬 OTL

네. 그렇기 때문에 모든 플러그인은 다른 플러그인에 상관없이 동작할 수 있도록 제작해 주셔야 합니다.

흠 개인적으로 태터 플러그인에 관한 이야기를 포스팅하면서 차근차근 리뷰하던중 이상한 점이 있어 올립니다....

개발본 기준

파일명 tattertools\\blog\owner\entry\add\index.php
line 34 부터

if ($id = addEntry($owner, $entry)){
    fireEvent('AddPost', $id, $entry);
    setUserSetting('LatestEditedEntry',$id);
}

이렇게 되어 있는데 이벤트를 파이어하여 할 수 잇는 것은 이메일 날려주는 것 밖에 할 수가 없네요...
플러그인에서 실제적인 데이터의 가공에는 권한이 없는 것으로 되어서 그런지 .... 궁금하네요...

if ($id = addEntry($owner, fireevent('AddingPost', $entry) )){
    fireEvent('AddPost', $id, $entry);
    setUserSetting('LatestEditedEntry',$id);
}

이렇게 추가가 되어야하지 않을 가요?

흠 플러그인이 어디까지 커버해야하고 각 바인딩(index.xml 의 기술(記述)상) 형식 별로 어떤 한계와 어떤 역할을 해야 할지 먼가 스팩을 정해야 할 듯 합니다.

이외에도 /lib/model/rss.php line 82
    if (fwrite($fileHandle, publishRSS($owner, $rss))) {
        fclose($fileHandle);
        @chmod($path, 0666);
        fireEvent('refreshRSS',$rss);
        return true;
    }
도 있네요...

넵 그런데  현재 상황으로는 저 이벤트의 파워가 '알림' 이외에는 없는듯합니다. 몇몇 이벤트들도 플러그인이 태터에 관여 할수 있는 여지를 주지 않은 경우가 보이네요..

아 원하는 답을 얻었습니다. ADDPOST 란 이벤트 이름에서는 위와 같은 정보를 얻을 수 없었던게 문제인 듯 합니다.

플러그인쪽 보면서 생각이 드는 것이 Tatter 소스를 보지 않는 이상 정확한 정보를 얻을 수 없다는 점이 문제인듯합니다.

특히 event 이름은 혼란을 줄수 있는 듯합니다.

이 의견에 동감합니다.

wordpress 의 경우 플러그인이 테이블에 임의의 필드를 추가시킨 후 (alter table...) 그 추가된 필드를 이용해서 여러가지 동작을 하는 것이 가능하지만 (실제 tag 관련된 플러그인들이나 related_post plugin 들이 비슷한 동작을 합니다.) 제가 지난 며칠간 테태툴즈를 이용해서 비슷한 것을 시도해본 결과...

1. AddPostEditorToolbox 를 이용해서 임의의 인풋 박스를 추가하더라도 실제 넘겨질 데이타들은 javascript 를 통해 수집되므로 실제 필드를 추가하기 위해선 blog/owner/post/entry/post 에 있는 javascript 를 hack 할 필요가 있게됩니다. (실제로는 저것만이 아니라 blog/owner/post/entry/add 와 blog/owner/post/entry/update 의 첫라인도 수정해야합니다.)

그냥 일반적인 textarea, input tag 등을 이용해서 쉽게 확장할 수 있는 구조로 가는 것이 더 좋지 않았을까 하는 생각을 해봅니다. 그렇다고 textarea, input tag 등을 이용해서 구현한다고 현재 지원하는 것들을 지원하지 못하는 것도 아닙니다.

2. blog/owner/entry/add/ 등에서 사용하는 insert query 에서는

insert into tablename (column_name1, column_name2,...) values (value1, value2,... );
식의 쿼리가 아닌

insert into tablename values (value1, value2,... )
식의 축약된 쿼리이기 때문에 alter table 등을 사용해서 필드를 추가하게 될 경우 글을 추가하는 것이 불가능하게 되는 문제가 있습니다. (처음부터 이런 식의 확장은 고려를 하지 않은 설계로 보이긴 합니다만)

3. 위와 같은 문제로 인해 테이블에 필드를 추가하기보다는 새로운 필드들을 집어넣은 테이블을 새로 만들고, 그 테이블을 이용하려해봤습니다.

하지만 AddPost 만이 존재하고, UpdatePost 이벤트는 존재하지 않기 때문에 값을 넣을 수는 있어도 수정까지는 할 수가 없네요. 또 한 번 막혀버렸습니다.

만약 AddPost 와 UpdatePost 등의 이벤트가 모두 존재하고, javascript 를 이용해 값들을 모아 넘겨주는 구조가 아니며,  축약된 쿼리를 사용하지 않았다면 alter table 을 통해 필드를 만들고 AddPost, UpdatePost 등의 이벤트에서 값을 Update 해주는 것을 통해 tatter 에는 전혀 손을 데지 않고도 플러그인 형태로 간단한 구현이 가능했을텐데 이래저래 처음 생각했던 것과는 많이 달라 결국 테터를 hack 해야겠네요. 흑;;

정태영 (2007-04-30 21:25:04)에 의해 마지막으로 수정

add 나 update 의 $IV 변수를 통해 그런 동작을 하는 것은 알고 있습니다.

하지만 허용하지 않는 값 이상은 받지 않는 것이 얼마나 보안상의 도움이 될 지 의문이 드는군요.

별 도움이 되지 않는다면 js 를 이용하지 않고, 제한된 값말고도 넘어가는걸 허용하는 방향으로 가는게 확장성 측면에서 좋을거라 생각하고,

정말 허용하는 값 이상을 받지 않는 것이 보안에 도움이 된다고 하면 json 등으로 serialize 하기보다는 plugin 의 index.xml 에서 추가 필드들을 명시해줄 수 있도록 하는게 더 좋지 않을까 싶네요. (단 로딩한 플러그인 리스트가 구축된 후에 POST 값 체크를 해야하기 때문에 손이 좀 많이 간다는 문제가 있겠습니다.)

IV 는 목적이 스크립티(?) 보안홀을 막기 위한 최소한의 장치입니다. 규모가 작은 ( 많이 작은) 경우는 보안홀에 대해서 케어가 가능하지만 개발자 2인이상이 필요한 곳에서는 필연적으로 실수나 미스커뮤니케이션에 의한 보안홀이 생기기 마련입니다. 이에 대해서 최소한도로 문제가 발생하지 않도록 제어하는 역할을 합니다.

index.xml 에 추가 필드를 명시해주는 것은 좋은 아이디어인듯합니다.. ( 비슷한 피쳐도 있구요) 다만 이에 대해서 모든 부분에 대해서 오픈하기는 다른 측면에서 무리가 있지 않나 합니다..