inureyes 작성:멋집니다.
플러그인 구조 자체를 클래스로 모듈화하는거군요.살-짝 제작 진입장벽이 높아지기는 하겠지만, 그런거야 간단한 설명서로 금방 채울 수 있을 것 같습니다.
(그리고, plugins.php는 현재도 model로 분리되어 있습니다.
아이디어와 방향만 선다면 (그리고 시간!) 적용이 가능하죠.)
아 이미 따로 있나보군요. 아직 개발트리를 못봐서요.
내일은 현재 어떻게 되어 있는지 천천히 한번 봐야겠네요.사실 저는 플러그인뿐만 아니라 가능한 다른 부분들도 전부 독립시켜서 개발하는게 좋다고 생각하거든요.
빠른 피드백뿐만 아니라 스몰코어가 되기 위해서라도요.
스몰코어 , 리치 컴포넌트 !!!
누구나 외치는 말이고 ..태터툴즈의 방향성 역시 그방향임은 확실합니다
멋집니다.
플러그인 구조 자체를 클래스로 모듈화하는거군요.살-짝 제작 진입장벽이 높아지기는 하겠지만, 그런거야 간단한 설명서로 금방 채울 수 있을 것 같습니다.
(그리고, plugins.php는 현재도 model로 분리되어 있습니다.
아 이미 따로 있나보군요. 아직 개발트리를 못봐서요. 
내일은 현재 어떻게 되어 있는지 천천히 한번 봐야겠네요.
사실 저는 플러그인뿐만 아니라 가능한 다른 부분들도 전부 독립시켜서 개발하는게 좋다고 생각하거든요.
빠른 피드백뿐만 아니라 스몰코어가 되기 위해서라도요.
세세한 것까지 깊게 생각한게 아니라 단편적으로 생각나는 것을 적은거라 오류가 있을 수도 있으니 양해해주세요.
현 플러그인의 문제점(?)
1. 악의적인 플러그인 제작자에게 취약하다.
2. 추가적으로 필요한 것이 있어도(이벤트 등) 태터툴즈가 버전업을 하지 않으면 지원이 될 수 없다.
3. 플러그인을 제작하는데 있어서 (태터툴즈 기능중) 필요한 것들을 찾기가 쉽지 않다.
4. 플러그인간 충돌이 발생할 가능성이 존재한다.(현재는 긴~ 함수명으로 해결; )
5. php코드와 javascript, css 등이 한 곳에서 다 짬뽕(; )이 된다.
개인적으로 js, css는 전부 head 태그 안에 들어가야된다고 생각(...)
6. 환경설정 및 백업이 불가능아래의 내용은, 대략 위와 같은 문제점(?)들이 존재하는데
어떻게하면 이것들을 해결할 수 있을까? 란 생각을 하다가
플러그인 관련 부분을 class로 제작해보면 어떨까? 라는 생각에서 출발했습니다.
제 생각들이므로 경어는 생략(...)/plugins/ 디렉토리에 plugins.php 파일을 생성하고 그 안에는 plugins class를 만들어
모든 플러그인들이 이 class를 상속받아 제작이 될 경우..1. 이 class에 DB에 액세스하는 부분을 넣고(물론 DB 모듈은 따로 제작해놓고)
개별 플러그인은 이 것을 사용해서 제작을 하며
mysql_* 등의 함수가 플러그인에 존재하면 작동이 안되게 하는 방식으로 한다면
약간이나마 도움이 되지 않을까?
(물론 config.php 파일을 include 시키는 것도 금지)2. 관련된 부분을 plugins.php 파일로 독립을 시켜놨기때문에
개별 플러그인은 필요한 plugins.php 파일의 버전만 명시해주면 되니
이 파일만 개별적으로 업데이트가 이루어져도 상관이 없지 않을까?
(자세한 구현방법은 나중에 생각해보고; )3. (원칙적으로 문서화만 잘되어있다면 문제가 되지 않는 상황이지만)
한 파일 안에 다 몰려있으니 찾는 것도 쉽겠지(...)4. 개별 플러그인의 class 이름은 디렉토리 이름과 동일하게 만들면 끝(?)
(index.xml 내에서의 정의는 className::functionName 정도로 하면 되지 않을까?)5. 개별 플러그인의 class에 head 라는 메소드를 만들어 이 곳의 내용은 자동으로 head 태그 안에 포함
6. 여기서 다룰 내용은 아닌거 같으므로 패스;;
욕만 하지 마세요.
멋집니다.
플러그인 구조 자체를 클래스로 모듈화하는거군요.
살-짝 제작 진입장벽이 높아지기는 하겠지만, 그런거야 간단한 설명서로 금방 채울 수 있을 것 같습니다.
(그리고, plugins.php는 현재도 model로 분리되어 있습니다. 아이디어와 방향만 선다면 (그리고 시간!) 적용이 가능하죠.)
현 플러그인의 문제점(?)
1. 악의적인 플러그인 제작자에게 취약하다.
2. 추가적으로 필요한 것이 있어도(이벤트 등) 태터툴즈가 버전업을 하지 않으면 지원이 될 수 없다.
3. 플러그인을 제작하는데 있어서 (태터툴즈 기능중) 필요한 것들을 찾기가 쉽지 않다.
4. 플러그인간 충돌이 발생할 가능성이 존재한다.(현재는 긴~ 함수명으로 해결; )
5. php코드와 javascript, css 등이 한 곳에서 다 짬뽕(; )이 된다.
개인적으로 js, css는 전부 head 태그 안에 들어가야된다고 생각(...)
6. 환경설정 및 백업이 불가능
아래의 내용은, 대략 위와 같은 문제점(?)들이 존재하는데
어떻게하면 이것들을 해결할 수 있을까? 란 생각을 하다가
플러그인 관련 부분을 class로 제작해보면 어떨까? 라는 생각에서 출발했습니다.
제 생각들이므로 경어는 생략(...)
/plugins/ 디렉토리에 plugins.php 파일을 생성하고 그 안에는 plugins class를 만들어
모든 플러그인들이 이 class를 상속받아 제작이 될 경우..
1. 이 class에 DB에 액세스하는 부분을 넣고(물론 DB 모듈은 따로 제작해놓고)
개별 플러그인은 이 것을 사용해서 제작을 하며
mysql_* 등의 함수가 플러그인에 존재하면 작동이 안되게 하는 방식으로 한다면
약간이나마 도움이 되지 않을까?
(물론 config.php 파일을 include 시키는 것도 금지)
2. 관련된 부분을 plugins.php 파일로 독립을 시켜놨기때문에
개별 플러그인은 필요한 plugins.php 파일의 버전만 명시해주면 되니
이 파일만 개별적으로 업데이트가 이루어져도 상관이 없지 않을까?
(자세한 구현방법은 나중에 생각해보고; )
3. (원칙적으로 문서화만 잘되어있다면 문제가 되지 않는 상황이지만)
한 파일 안에 다 몰려있으니 찾는 것도 쉽겠지(...)
4. 개별 플러그인의 class 이름은 디렉토리 이름과 동일하게 만들면 끝(?)
(index.xml 내에서의 정의는 className::functionName 정도로 하면 되지 않을까?)
5. 개별 플러그인의 class에 head 라는 메소드를 만들어 이 곳의 내용은 자동으로 head 태그 안에 포함
6. 여기서 다룰 내용은 아닌거 같으므로 패스;;
욕만 하지 마세요.