아직 로그인하지 않았습니다. 로그인 또는 회원 등록을 해 주시기 바랍니다.
TNF : Tatter Network Foundation forum » ghost_ghost가 작성한 글
정확한 문제점
element.childNodes 가 찾아오는 node list 가
dom node 가 아니라 열림태그 텍스트 닫힘태그 이런 식으로 가져옴 즉
<parent><ele> ldsfsdflj </ele></parent>
IE : parent.childNodes => { ele , dsljfldsf /ele }
FF : parent.childNodes => { ele(object) }
결국 그 옛날 처럼..... 브라우저에 따라 코드를 다르게 가져가야 할듯...... ㅠㅠ
ㅠㅠ 네 원래 설정 창에서도 설정값을 유지시키도록 적용하였습니다...
IE에서는 dom level1 표준대로 따라 했더니... 요상하게 작동을 하네요 ㅋ 역시 M$
ㅋ 어제 firefox 에서 개발 확인 해보고 걍 sandbox올렸다가... IE에서 작동안하는 것이 발견됬습니다.
pluginconfig.js 이 파일입니다... 지금 작업 중이니.... 확인해보실분은 파폭에서만 확인해주세요
네 알겠습니다. 해당 부분 일단 적용 해드렸습니다.
참고로 DOM white paper점 보다가.... 수정사항이 생겼습니다. ^^
xhtml을 사용하니 필드셋 렌더링 부분이 다음과 같이 변경되었습니다.
니들웍스 ----여기는 콘피그 화면 xhtml ---
<fieldset name="요값이 추가 되었습니다..." >
<legend>그룹명입니다.</legend>
<field name="요값은 제가 데이터 처리를 위해 넣은 값입니다.." type="요값은 제가 데이터 처리를 위해 넣은 값입니다..">
//IE에서는 cSS에서 display:block; 가 원하는데로 작동 안하더군요... ^^;;
<fieldTitle>설정값1</fieldTitle> //요거는 CSS를 먹이기 쉽게 하라고 ^^;;
<fieldControl>
여기에 각 콘트롤들이 type에 맞게 들어값니다...예를 들어
<input type="radio" name=""> 1 <input type="radio" name=""> 2 <input type="radio" name=""> 3
</fieldControl>
</field>
....
</fieldset>이제 데이터 처리부에 관련된 내용인데요...
저장 형식을 xml로 결정하였습니다. 아무래도 트리구조다보니 delimeter 가 신경쓰여서요...
<config plugin="">
<fieldset name="">
<field name="">여기에 설정한 값들이 들어 갑니다....</field>
<field name="">여기에 설정한 값들이 들어 갑니다....</field>
<field name="">여기에 설정한 값들이 들어 갑니다....</field>
</fieldset>
<fieldset name="">
...
</fieldset>
</config >흠 일단 이형식은 내부에서 저장 및 통신에서만 쓰일 예정이라 크게 신경안쓰셔도 되구요....
아마 플러그인 실제 구현시와 검증 hook handler에서는 array로 제공할 예정입니다.
$config= array( "필드셋네임" => array(
"필드네임" => "값",
"필드네임" => "값",
"필드네임" => "값"
),
"필드셋네임" => array(
"필드네임" => "값",
"필드네임" => "값",
"필드네임" => "값"
)
);요렇게 되겠지요
2) fieldset은 그냥 <fieldset>태그로 처리되면 어떨까요?
┌처음처럼1 ───────┐
│셋팅 ○○○. . │
└────────────┘
^^ ;;?? 지송합니다. 이해가... 안되서리
3) <table> 처리대신 <div>로 모두 처리하시는게 좋지 않을까 생각합니다.
원래는 div로 처리 했다가 모냥이 너무 안나와서 ^^ 대체한것입니다. 흠 table은 은근히 꺼려지긴 하죠.
1) textarea의 value값이 안넘어옵니다.(..currentSetting/index.php의 90번째줄)
변경전 : $DSP .= empty( $cmd['.value'] ) ? '' : htmlspecialchars($cmd['.value']);
변경후 : $DSP .= empty( $cmd['.attributes']['value'] ) ? '' : htmlspecialchars($cmd['.attributes']['value']);위와 같이 하셔야 value값이 전달되어 옵니다. '$cmd['.value']'는 다른 패턴이 있으신건가요?
.value는 field 태그의 textvalue(dom) 값을 가져옵니다.
걍 value attr로 처리 해도 되지만.. 대부분 textarea는 css 와 같이 비교적 많은 양의 text 데이터를 처리합니다. 그러므로 특수 문자에 안전하도록
text element로 처리하고 CDATA섹션을 먹일수 있도록 한것입니다.
파커님의 의도대로 하시려면 manifest부분이
<field type="textarea ~~> 가나다라마바사 디폴트 textarea setting 값입니다. </field>일케 되면 되겠네용
ㅠㅠ 지금 열심히 sandbox 에 패치시키고 잇는데 /blog/owner/setting/plugin/index.php 가 tt 1.0.6과는 완전히 다른 파일이되버려서리 (ㅠㅠ) ,,, 이쪽은 패치 시키지 않고 설정관련 로직 없이 임시로 오픈 버튼을 넣겠습니다...(ㅎㅎ 설정이 있는 플러그인만 일단 눌러보세용...)
아직 데터부분들은 작업을 안했지만 기존 시스템에 영향을 주지는 않습니다. 그럼 점심 먹기전에 커밋을 하겠습니다.
안녕하세요 ^^;; 넘 오랜만에 올립니다... ㅋㅋ
일단 스키마와 렌더링 부분은 끝났습니다.
스키마는 다음과 같은 사항을 지원합니다.
컨트롤 text, textarea, select, checkbox , radio
<config dataValHandle="핸들러">
//dataValHandle : 옵션 플러그인 제작자가 사용자가 설정한 값을 검증할때 쓰임 없으면 걍 저장됨...
<fieldset legend="타이틀" name="id">
// 하나의 설정값 그룹입니다. 나중에 각 플러그인 구현에서 $config['id'][...] 로 접근됩니다.
<field name='' title='' value='' type='text' [size=''] />
//<input type='text' size='' name=''> 로 변경됩니다. $config['fieldsetid'][name] 으로 접근
<field name='' title='' type='textarea' [rows=''] [cols=''] >기본값</field>
// <textarea > 기본값</textarea>
<field name='' title='' type='select' >
<op value='' checked='true/false'> 이름</op>
</field>
//<input type='select' name='' >
// <option value=''>이름</option>..
//</select> 로 변경됩니다. $config['fieldsetid'][name] 으로 접근
<field name='' title='' type='checkbox' >
<op value='' checked='true/false'> 값</op>
</field>
//<input type="checkbox" > 값 으로 변경됩니다. $config['fieldsetid'][name] 에 설정된 값의 스트링 값으로 저장됨 ex) '값1,값3'
<field name='' title='' type='checkbox' >
<op value='' checked='true/false'> 값</op>
</field>
//<radio type="checkbox" name='' value='' > 값 으로 변경됩니다. $config['fieldsetid'][name] 에서 접근 가능
</fieldset>
</config>아직 데이터 처리부는 안만들었고... 표현부만 되었습니다. 예를 들어 아래와 같은 manifest 는...
....
<binding>
<config dataValHandler = "TaatertoolsBirthdayDataSet" >
<fieldset legend="처음처럼1">
<field title="셋팅1" name="t1" type="text" size="3" />
<field title="셋팅2" name="t2" rows="2" type="textarea" value ="처음>>값" />
<field title="선택" name="t6" type="radio" >
<op value="1">1</op>
<op value="2" checked="true">2</op>
<op value="3">3</op>
<op value="4">4</op>
</field>
</fieldset>
<fieldset legend="처음처럼2">
<field title="선택" name="t3" type="select" >
<op value="1">1</op>
<op value="2" checked="true">2</op>
<op value="3">3</op>
<op value="4">4</op>
</field>
<field title="체크박스" name="t4" type="checkbox" >
<op value="1">가나다라</op>
<op value="2" checked="true">일이삼사</op>
<op value="3">오륙칠팔</op>
<op value="1">가나다라2</op>
<op value="2" checked="true">일이삼사2</op>
<op value="3">오륙칠팔2</op>
<op value="1">가나다라3</op>
<op value="2" checked="true">일이삼사3</op>
<op value="3">오륙칠팔3</op>
</field>
</fieldset>
</config>
</binding>
와 같이 그려집니다.
아 작업 중에 문제 사항이 있어 다시 올립니다.
위의 예제 설정 화면과 같이 특정 항목이 선택 되었을때 활성화되는 부분은 스키마로는 불가능 한듯 합니다.
다시 한번 생각이 드는 듯하는데 스키마에 로직을 넣는 다는 것은 하나의 언어를 만드는 것과 같은 듯하여 무리인 듯합니다.
일단 input type=text, type=radio, type=checkbox ,textarea , select 이 다섯가지 만을 제한하고 이에 대한 검증부분은
따로 manifast에서 핸들러를 받아서 처리하는 쪽으로 가는 것이 좋겠습니다.
^^ 네 지금 열심히 작업 중입니다. ^^
그리고 example 버튼에는 로직이 들어가는데.... 위의 스키마는 스키마일뿐 로직이 설계되어
있지 않아서요 ^^ 또 그로직부분은 너무 돌발변수가 많기 때문에( 그래서 프로그래머가 먹고
사는지도^^) 그부분을 감싸는 것은 거의 언어 설계 수준이 될듯합니다.
플러그인은 지속적으로 추천을 받아 추가 시킬 예정입니다.
DB쪽에서 당장쓸수 있는 자원은 plugins.setting (text) 입니다. 처음에는 제작자 임의로 데이터를 조립해서 넣는 구조였습니다.
대략 위 구조대로라면
imgkind[DEL1]GIF[DEL_G]explain[DEL1]sdlfjlsdf[DEL2]option[DEL1]a,b,c
이런 식으로 넣을 수 있겠죠
^^;; 이런 수준까지 제어 하려면 config 스키마가..... 상당히 복잡해지겠네요
아 그리고 example 쪽 버튼은 불가능할 듯합니다.
datatype ="" 이 항목은 괜히 제작자에게 혼란만 야기시킬것 같습니다. row="3"의 의미는 해당 필드를 3개를 더 만든다는 것이죠?
row는 ^^ text 컨트롤의 rows 와 같은 의미로 쓴 것 입니다.
검증 부분이 명확하면 datatype은 굳이 사용할 필요는 없는 듯 합니다.
또한 가지 부분이 데이터 검증쪽인데 어제 문서에서 dataHandler 쪽을 검증쪽 HOOK으로 꺼내 놓을 필요가 있을 듯 합니다.
즉 그쪽에서 받은 함수를 가지고 포스트 된 데이터를 검증하여 성공인지 혹은 검증실패(사유포함) 인지를 판별하는 루틴을 넣었으면 합니다. HOOK이니 구현안하면 기본적인 타입 체킹만 하는 쪽으로 가고요
<binding>
...
<config>
<fieldset legend ="set1">
<field title="" name= "3" datatype ="int" view="select">
<option> 1</option>
<option> 2</option>
<option> 3</option>
<option> 4</option>
</field>
<field title="" datatype ="string" name= "2" max = "1000" type="text" rows="3" />
<field title="" datatype ="bool" name= "1" type="radio" rows="3" />
</fieldset>
</config>
</binding>이런식으로 데이터 타입이 들어 가면 절충이 될듯 합니다.
그런데 이런쪽이면 그냥 HTML 코드 단편을 받는게 제작자에게 편할 듯하네요 ^^
네 이부분에 대한 설명이 부족한듯 하여 글을 수정하였습니다.
어제 graphittie 님이 채팅초대를 해주신듯한데 ^^;; 미처 못보고 넘어갔네요 ㅎㅎ
이메일 주소를 알려주시면 G톡에서 좀더 이야기를 해보았으면 합니다.
^^ 아침에 와보니 field 종류가 많이 늘었네요 ㅎㅎ
그런데 필드 종류가 플러그인 제작자가 필요한 데이터를 정의한다기 보다 컨트롤 위주로 되어있는 듯 합니다. HTML 수준의 세밀한 태그를 제공하게 되면 기존의 방식과 별차이가 없다고 생각됩니다. 설정 데이터는 서버쪽 코드에서 의미가 있는 것이므로 string bool int enumeration 와 같이 데이터 타입 측면에서 기술하게 하는게 플러그인 제작에 편할 듯 합니다. 그리고 플러그인 제작자쪽에서 데이터 입출력에 대해서 관여를 할 수 없게되므로 사용자가 서브밋한 데이터를 검증할 만한 방법이 있어야 합니다. 그런 측면에서 클라이언트 쪽 표현에만 의미가 있는 컨트롤 방식보다는 데이터 타입 명시쪽이 더 낳을 듯합니다. 적어도 이 값이 문자열인지 숫자인지 보장을 할수 있으니까요.
index.xml에 설정에 관련된 fieldset 구조를 정의 할수 있게 하고
설정 화면에서 이를 바탕으로 통일된 화면을 제공 하는 것도 갠찬을 듯합니다.
이쪽부분에 대해서는 일단 fieldset 구조에 대한 스키마가 필요할 듯 합니다.
간단하게 string integer enumeration 정도를 예상하고 있는데 또 필요한 것이 있을가요?
대략
.....
<binding>
.....
<config>
<field name="s1" type="string" />
<field name="s2" type="int" />
<field name="s3" type="enumeration" >
<e>강아지</e>
<e>소</e>
<e>개구리</e>
</field>
</cofing>
</binding>
.....이렇게 정의를 하면 좋을 듯합니다....
알겠습니다. 일단 관련 작업은 보류된 상태로 놔두겠습니다. ^^
3. 팝업 설정 자체에 대해서는 별다른 이견이 없습니다만, 어차피 설정 적용 여부를 실시간으로 보일 수는 없습니다. 그러므로
ghost_ghost 작성:두번째 이유 : 팝업을 사용하게 되면 유저가 팝업에서 설정을 하고 곧바로 적용여부를 확인
할 수 있습니다. 비슷한 예로서 외부 블로그 글 화면에서 글 수정을 팝업으로
처리한 경우가 있습니다.는 이유가 되지 못합니다.
결론적으로, 다른 방식으로 접근 하는 것이 낫다는 것이 제 의견입니다.
다만 개인적으로 팝업을 유지하는 것이 낳을 듯합니다. 매번 설정값을 바꾸고 확인 하기 위해서 이동하는 것보다는 팝업에서 수정을 하고 원본창에서 리프레시로 확인 을 하는 것이 더 편하다고 여겨집니다.
displayHandler에서 사용자가 설정 인터페이스를 작성을 해야하는 방법은...왠지~~~
흠... 상상했던 것과는 약간은 다른 폼인것 같습니다. 모든 플러그인들은 설정 인터페이스를
각자 갖춰야 한다는게 조금 걸립니다. 자유도를 보장한다는 것이 의도는 좋을듯 하나
많은 혼란을 야기시킬수 있을것 같은 예감이 듭니다.
설정에 관하여 한정된 규약을 제공하고 그 한도내에서 제공하는 방법도 고려되었으나 확장성
이 부족한 감이 들어 일단 이쪽으로 방향을 잡았습니다. 일단 포럼에서 이야기를 더 진행
해주시면 참고가 될 듯합니다.
ghost_ghost 작성:첫번째 이유 : 자유도를 보장하되 팝업으로 처리하여 기존 플러그인 관리자 화면과의 이질성을 해소합니다.
그러니까... 플러그인 설정화면의 레이아웃을 마음대로 조절하도록 허용하는 부분이 기획이었다는 말씀인가요?
일단 그렇습니다.
플러그인 제작자에게 설정 화면 구성까지 허용한 것은 자유도를 보장하기 위해서 였습니다.
설정 화면의 팝업 사용에 대한 이유는 다음과 같습니다.
첫번째 이유 : 자유도를 보장하되 팝업으로 처리하여 기존 플러그인 관리자 화면과의
이질성을 해소합니다.
두번째 이유 : 팝업을 사용하게 되면 유저가 팝업에서 설정을 하고 곧바로 적용여부를 확인
할 수 있습니다. 비슷한 예로서 외부 블로그 글 화면에서 글 수정을 팝업으로
처리한 경우가 있습니다.
현재 TNC에서 개발 완료 하였고 리뷰중에 있습니다.
관련 API 문서인데 보시고 의견 부탁드립니다.
http://dev.tattertools.com/wiki/pluginAPI
==> 참고로 ^^ 적용이 결정된 것은 아닙니다. 아래 나온 지적점들도 고민이 되었고
더 논의 되어야 할것 같습니다. 의견 부탁드립니다.
참고로 ^^ 1.0.6 ERD 입니다. 리버싱 한거에요.
주석은 아직 안달았습니다.
^^ 소규모요 설계 다보니 관계가 없네요 ^^ ( MYSQL의 한계인듯)
ERDhttp://www.ghosthigh.com/blog/ghost/att … 946460.xml
뷰어http://www.fabforce.net/==> 꽁짜 ERD 설계 툴 꽤 쓸만함( 절대 광고 아님 ㅎㅎ)
안녕하세요 TNF에 새로 조인한 ghost_ghost 입니다. ^^
지금 티스토리쪽에 들어갈 플러그인 선별 및 검증 작업을 하고 있습니다.
현재 추천해주신 플러그인을 대상으로 하고 있고 리스트는 다음과 같습니다.
일차 검증 완료
브레인 태그 차칸아이 님
리퍼러로그정리 CRIZIN 님
Lightbox TT EX 치리 님
보류 대상
Random Photo Viewer JUNO 님
Thumbnail List / RRMC Plugin J.Parket 님
미검증
FootNote gofeel 님
BlogAPI coolengineer 님
[태터 1.0.6?]태터 오에카키 Powring 님
무지개 링크 JustKidding 님
Entry Hits Plugin J.Parket 님
hk_plug_v1.7 ideA Kiss 님
CodeTagHelper 위쯔 님
선별 및 검증에 대한 기준은 다음과 같습니다.
필수
1. TatterTools 1.0.6 버전 기준으로 작동하는 플러그인
2. 플러그인 이외에 TatterTools 소스 수정 여부
3. 플러그인 내에 DB 스키마 변경 SQL문 존재 여부
4. 플러그인 설정 여부 하드 코딩
5. 포괄적인 버그나 적용이 불가능한 경우
검토
6. 기타 임시 파일에 대한 생성 수정 여부 ==> 이 기준은 따로 검토 됩니다.
7. 라이센스 제작자분들의 동의가 필요합니다. ^^
현재 보류 된 플러그인 등은 대부분 2,4번 기준에 부합되지 않아 보류된 경우입니다.
개인적으로도 참 있었으면 하는 기능 인데 아쉽습니다. ^^
제작자 분들께서 쪼금만 2,4번 부분을 수정해주시면 정말 정말 감사하겠습니다.
그럼 앞으로도 많이 플러그인 추천 올려주세요.
TNF : Tatter Network Foundation forum » ghost_ghost가 작성한 글