첫번째 이유 : 자유도를 보장하되 팝업으로 처리하여 기존 플러그인 관리자 화면과의 이질성을 해소합니다.

displayHandler에서 사용자가 설정 인터페이스를 작성을 해야하는 방법은...왠지~~~
흠... 상상했던 것과는 약간은 다른 폼인것 같습니다. 모든 플러그인들은 설정 인터페이스를
각자 갖춰야 한다는게 조금 걸립니다. 자유도를 보장한다는 것이 의도는 좋을듯 하나
많은 혼란을 야기시킬수 있을것 같은 예감이 듭니다.

ghost_ghost 작성:

첫번째 이유 : 자유도를 보장하되 팝업으로 처리하여 기존 플러그인 관리자 화면과의 이질성을 해소합니다.

그러니까... 플러그인 설정화면의 레이아웃을 마음대로 조절하도록 허용하는 부분이 기획이었다는 말씀인가요?

두번째 이유 : 팝업을 사용하게 되면 유저가 팝업에서 설정을 하고 곧바로 적용여부를 확인
                    할 수 있습니다. 비슷한 예로서 외부 블로그 글 화면에서 글 수정을 팝업으로
                    처리한 경우가 있습니다.

자유로운 레이아웃이라고 하면 CSS 제어권만 줘도 충분하지 않을까 싶은데요... 플러그인 개발자의 로고 정도는 따로 삽입할 수 있는 구조를 만들어줘도 좋겠습니다.

제가 나름대로 생각했던 방식은, fieldset 구조를 XML의 bind 구조 안에 옮겨서 그걸 XHTML로 뿌려주는 구성이었습니다. 현재 관리자 화면의 XHTML은 폼 형식에 대해 fieldset/dl/dt(dd)/div로 이어지는 구조를 가지고 있어서 이 구조만 따르면 별도로 CSS를 제작할 필요 없이 제법 쓸만한 레이아웃이 나옵니다.

그런데, 팝업을 해야 하는 이유도 있으니... 팝업에 맞춰 생각을 수정해 보면, 일단 HTML 구조는 위에서 말씀드린 XML 방식대로 뿌려주되 사용자 플러그인 디렉토리로 지정되어 있는 CSS 파일 link를 추가해주는 거죠. 이 파일이 있으면 이 CSS를 사용하지만(이 CSS는 플러그인 제작자가 작성하는 것이기 때문에 기획의도대로 다양한 레이아웃이 나올 수 있다고 봅니다.) 이게 없으면 관리자 스킨에서 설정된 CSS를 사용하도록 하는 겁니다.

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>
.....

이렇게 정의를 하면 좋을 듯합니다....

이 구조로는 조금 부족하지 않은가 하는데요...
우선 input 태그만 해도 checkbox, radio, image, button, submit, text, password를 구분해 줘야 하고, 이 input에는 label이 따라 붙는 경우가 있으니 이도 있어야 하고... select 박스도 포함해야 하고, 반드시 fieldset을 하나만 사용하라는 법이 없으니 이도 반영해야 하고, radio의 경우 여러개를 박스 하나로 묶어 이 박스에 label을 붙이므로 이에 대한 반영도 있어야 하고... id와 name은 너무 당연한 거고, (onclick 등의) 이벤트도 지원되어야 하고... 이벤트가 지원된다고 하면 설정 팝업의 head에 script 파일을 삽입해 주는 치환자([##_SKIN_head_end_##]와 흡사한)도 있어야 하고...:(

J. Parker 작성:

<binding>
.....
<config>
 <field title="이름" name="s1" type="text" size="10" value="홍길동" />
 <field title="비밀번호" name="s2" type="password" size="10" value="1234" />
 <field title="종류1" name="s3" type="radio" />
  <op value="1" checked="true">1</op>
  <op value="2">2</op>
 </field>
 <field title="종류2" name="s4" type="checkbox" >
  <op value="1" checked="true">1</op>
  <op value="2">2</op>
 </field>
 <field title="종류3" name="s5" type="select" >
  <op value="1" checked="true">1</op>
  <op value="2">2</op>
 </field>
</cofing>
</binding>

필드셋도 추가되면 좋겠는데요...:)

<binding>
.....
<config>
 <fieldset legend="필드셋 1">
  <field title="이름" name="s1" type="text" size="10" value="홍길동" />
  <field title="비밀번호" name="s2" type="password" size="10" value="1234" />
  <field title="종류1" name="s3" type="radio" />
   <op value="1" checked="true">1</op>
   <op value="2">2</op>
  </field>
 </fieldset>
 <fieldset legend="필드셋 2">
  <field title="종류2" name="s4" type="checkbox" >
   <op value="1" checked="true">1</op>
   <op value="2">2</op>
  </field>
  <field title="종류3" name="s5" type="select" >
   <op value="1" checked="true">1</op>
   <op value="2">2</op>
  </field>
 </fieldset>
</cofing>
</binding>

이렇게요.

^^ 아침에 와보니 field 종류가 많이 늘었네요 ㅎㅎ 거의 HTML 컨트롤 태그 수준인듯합니다.
플러그인 제작자쪽에서는 위의 타입을 모두 필요로 하지는 않을 듯 합니다. 제작자의 편의성과
통일성이 중요 요점인 만큼 데이터 타입은 php 에서 쓰이는 쪽으로 간결하게 가는게 어떨지
싶습니다. 다만 fieldset element dhk title name 등등의 어트리뷰트는 필요할듯합니다.

string bool int enumeration 와 같이 데이터 타입 측면에서 기술하게 하는...

string bool int enumeration 와 같이 데이터 타입 측면에서 기술하게 하는...

방법도 좋겠지만 누구나 설정셋에 접근용이하게 쉽게 풀어주는것도 괜찮을듯 합니다.
위 방법도 익숙해지면 괜찮겠죠. 위 text, radio or checkbox, select의 세가지 정도의 기본 컨트롤태그를
사용하게끔만 하여 html를 이용하는것처럼 사용해도 괜찮을듯 합니다.
시현되는 예제를 보면 더욱 확연하게 들어날것 같습니다.

datatype ="" 이 항목은 괜히 제작자에게 혼란만 야기시킬것 같습니다.  row="3"의 의미는 해당 필드를 3개를 더 만든다는 것이죠?

또한 가지 부분이 데이터 검증쪽인데 어제 문서에서 dataHandler 쪽을 검증쪽 HOOK으로 꺼내 놓을 필요가 있을 듯 합니다.
즉 그쪽에서 받은 함수를 가지고 포스트 된 데이터를 검증하여 성공인지 혹은 검증실패(사유포함) 인지를 판별하는 루틴을 넣었으면 합니다. HOOK이니 구현안하면 기본적인 타입 체킹만 하는 쪽으로 가고요