커뮤니티 사이트의 미래와 그누보드 확장성 정보
커뮤니티 사이트의 미래와 그누보드 확장성
본문
엔피씨님이 제기하셨던 '커뮤니티 사이트의 미래' 에 관한 토론을 이곳에서 이어가 봤으면 좋겠네요.
(제가 제대로 이해했다면) 엔피씨님의 제안은, '회원이 손쉽게 선택/설치하고 커스터마이징 할 수 있는 위젯'을 도입하자는 것입니다. 물론 엔피씨님의 제안은 이것보다 더 개념적이고 상위적일텐데, 일단 손에 잡히는 형태로 보자면 '위젯'과 이러한 위젯을 관리하는 위젯 스토어? 개념일 것 같습니다.
개념자체는, 엔피씨님과 다른 분들이 지적한대로, 이미 다른 웹 솔루션 들에서 구현/운영하고 있는 것일텐데,
이를 그누보드에 도입하기 위해서 어떤 작업과 접근방법이 필요할지 한번 얘기해봤으면 해서요..
제 기억에 여러분들이 애드온이나 그누보드의 CMS화 등에 대해서 의견을 내어놓으셨는데, 자게에서는 그닥 토론이 잘 이루어 지지 않은것 같아서 여기로 옮겨봤습니다.
타 php 솔루션의 플러그인 메카니즘 (후킹, 이벤트 처리 등)과 그누보드의 스킨 시스템의 장단점,
그누보드 플러그인의 보다 구조적인 표준화 등 기술적인 접근방법에 대해서 의견을 나눠봤으면 좋겠습니다.
또한 엔피씨님이 시작하신, '커뮤니티 사이트의 새로운 방향'에 대해서도 아이디어를 모아볼 수도 있을것 같습니다. :)
추천
1
1
댓글 17개
왜 아무도 시작하지 않죠 ?
그러게요.. ^^;
하긴 제가 워낙 듣보잡이라.. ^^;
하긴 제가 워낙 듣보잡이라.. ^^;
님 글은 항상 잘보고 있어요~ 특히 반응형 웹 부분요 *^^*
상당한 실력자인것 같은대요 ~~
그누스타디도 잘 되시죠 ?
상당한 실력자인것 같은대요 ~~
그누스타디도 잘 되시죠 ?
앗, 지켜보고 계시는 군요. ^^'
저도 잘 몰라서 배우고 있는 부분입니다.
그누스터디도 그런 의미로 하고 있고요. ^^
저도 잘 몰라서 배우고 있는 부분입니다.
그누스터디도 그런 의미로 하고 있고요. ^^
헉, 저는 이리 옮겼단 말 듣고 좀더 자료를 철저하게 할까 하고 늦어지고 있네요. + _ +;
기대됩니다 !!!!!
전 좀.. 부정적인 의견이라서..
지금 상태에서 그누에 앱스토어 시스템을 적용하려면 화면에 뿌려주는 내용을
텍스트큐브나 드루팔, JSP프로그램 처럼 버퍼에 담았다가 뿌려주도록 재구성하는것이 먼저 필요합니다.
또는 head.sub.php 에 담당 자바스크립트를 추가시킨 후 화면 onload 후에 플러그인을 적용할 수 있게 js파일이 화면을 재구성하도록 해야겠죠.
지금 상태에서 그누에 앱스토어 시스템을 적용하려면 화면에 뿌려주는 내용을
텍스트큐브나 드루팔, JSP프로그램 처럼 버퍼에 담았다가 뿌려주도록 재구성하는것이 먼저 필요합니다.
또는 head.sub.php 에 담당 자바스크립트를 추가시킨 후 화면 onload 후에 플러그인을 적용할 수 있게 js파일이 화면을 재구성하도록 해야겠죠.
꼭 '지금 상태' 일 필요는 없지 않을까요? ^^
오히려 라엘님의 구현방법이 더 흥미롭습니다. 언제한번 더 자세히 들어볼 수 있는 기회가 있었으면 좋겠습니다. ^^
오히려 라엘님의 구현방법이 더 흥미롭습니다. 언제한번 더 자세히 들어볼 수 있는 기회가 있었으면 좋겠습니다. ^^
그누보드 자체도 스킨이나 익스텐드에 대한 모듈화가 '나름' 구현되어 있긴 하지만 컨트롤러를 후킹해 기능을 더하거나 빼는 등의 형태가 안되다보니 대다수의 스킨이 컨트롤러를 겸하게 되어 지금의 상황이 되었다 봅니다. 기존 방식의 장점은 아무래도 기존 플로의 개발 방식(절차지향의..)을 그대로 유지할 수 있는 점이고 단점은... 모듈화가 쉽지 않다는 점인데...
만약 소스 전체를 모듈화해서 리펙토링 하지 않는 이상 위와 같은 에드온을 도입 하기 위해서는 워드프레스와 같은 add_action, do_action을 도입하는 방법이 가장 빠르다고 봅니다. 데이터를 조작하는 각 포인트마다 후킹 포인트를 do_action으로 지정해주고 add_action으로 연결해주는 식인데 라엘님 말씀대로 전체 버퍼에 담아서 템플레잇 하는 것보다는 좀 더 간편하게 되지 않을까 생각되네요.
만약 소스 전체를 모듈화해서 리펙토링 하지 않는 이상 위와 같은 에드온을 도입 하기 위해서는 워드프레스와 같은 add_action, do_action을 도입하는 방법이 가장 빠르다고 봅니다. 데이터를 조작하는 각 포인트마다 후킹 포인트를 do_action으로 지정해주고 add_action으로 연결해주는 식인데 라엘님 말씀대로 전체 버퍼에 담아서 템플레잇 하는 것보다는 좀 더 간편하게 되지 않을까 생각되네요.
저도 비슷한 고민을 했던적이.. ^^
http://blog.gnuboard.org/2012/04/gnuboard-extend-framework/
그나저나 호주는 겨울이겠네요? ^^:
http://blog.gnuboard.org/2012/04/gnuboard-extend-framework/
그나저나 호주는 겨울이겠네요? ^^:
탁월한 분석글이네요. 현행 그누보드에서 가장 빠르게 전환할 수 있는 방법이라 판단됩니다. 후킹에 대한 네이밍 룰만 잘 정해진다면 어느 정도 표준화도 끌어낼 수 있으면서 학습곡선도 완화하고 작업도 빠르게 진행될 수 있으리라 생각됩니다.
춥습니다 여기 ^^; 그래도 조금씩 봄이 오려고 하네요.
춥습니다 여기 ^^; 그래도 조금씩 봄이 오려고 하네요.
^^
네이밍 룰이나 접근 방식으로, byfun님의 나린위키의 방법은 어떨까 합니다.
사용중인 이벤트 목록은 http://narinwiki.org/docs/folder/narin/events 입니다.
버전이 올라가면서 더많은 이벤트 (또는 후킹포인트) 를 지원할 수 있겠죠.
플러그인/애드온/위젯의 구현도 어느정도 표준화하고 설치위치도 고정하는 등의 과정도 거쳐야 겠고요..
지금의 스킨 시스템과의 충돌은 없을까하는 생각을 잠깐 해보고 있습니다.
말씀대로 스킨안에 컨트롤러 기능이 다 들어가 있으니, 장점으로는 스킨 레벨에서 do_action 같은 것을 시행할 수도 있고, 반대로 그것이 단점이 될수도 있겠네요..
네이밍 룰이나 접근 방식으로, byfun님의 나린위키의 방법은 어떨까 합니다.
사용중인 이벤트 목록은 http://narinwiki.org/docs/folder/narin/events 입니다.
버전이 올라가면서 더많은 이벤트 (또는 후킹포인트) 를 지원할 수 있겠죠.
플러그인/애드온/위젯의 구현도 어느정도 표준화하고 설치위치도 고정하는 등의 과정도 거쳐야 겠고요..
지금의 스킨 시스템과의 충돌은 없을까하는 생각을 잠깐 해보고 있습니다.
말씀대로 스킨안에 컨트롤러 기능이 다 들어가 있으니, 장점으로는 스킨 레벨에서 do_action 같은 것을 시행할 수도 있고, 반대로 그것이 단점이 될수도 있겠네요..
결과적으로 봤을 때 그누 전반적인 부분을 갈아엎는거네요.
(flow는 그대로이나 코드는 다 엎기)
(flow는 그대로이나 코드는 다 엎기)
어떤 방식이든, 원본 수정은 불가피 하지 않을까 생각합니다. ^^
오히려, 원본의 수정 여부보다는, 기존 스킨과의 호환성이, 아마도 현재 그누보드 사용자를 계속 이어나갈 수 있는 관건이 되지 않을까 하고요. ^^
스킨 개발자/사용자 분들에게, 보다 많은 '함수'를 제공하는 차원이랄까요?
오히려, 원본의 수정 여부보다는, 기존 스킨과의 호환성이, 아마도 현재 그누보드 사용자를 계속 이어나갈 수 있는 관건이 되지 않을까 하고요. ^^
스킨 개발자/사용자 분들에게, 보다 많은 '함수'를 제공하는 차원이랄까요?
위 방식으로 하면 완전히 갈아 엎기 보다는 후킹 포인트만 만들어주면 되니 그나마 좀 덜 갈아엎는(?) 편입니다.
보안적인 부분에서 걸리는 것 외에는 전진님 올리신 글처럼 가는 것이 좋겠습니다.
보안은... 워프도 공식 사이트에 올라오는 플러그인은 코드리뷰가 된 플러그인만 업로드 되는 방식이지만 그누보드는 그렇지 않으니까요.
그리고 스킨이 뷰와 컨트롤러를 확실하게 분리하면 좋긴 하겠지만 그러면 러닝커브가 심하니 기존 그누보드가 가져오던 장점(이라 얘기되는) 부분에 마이너스 요소가 될 것 같아서...
글로만 하니 두루뭉술한 얘기만 계속 쓰게 되네요 ㅎㅎ
보안은... 워프도 공식 사이트에 올라오는 플러그인은 코드리뷰가 된 플러그인만 업로드 되는 방식이지만 그누보드는 그렇지 않으니까요.
그리고 스킨이 뷰와 컨트롤러를 확실하게 분리하면 좋긴 하겠지만 그러면 러닝커브가 심하니 기존 그누보드가 가져오던 장점(이라 얘기되는) 부분에 마이너스 요소가 될 것 같아서...
글로만 하니 두루뭉술한 얘기만 계속 쓰게 되네요 ㅎㅎ
보안부분은.. 만일 위젯스토어? 가 sir 등에 생긴다면, 리뷰어들을 두는 방법도 괜찮겠네요.. 강제사항은 아니더라도 리뷰가 되었다는 정보를 제공해주는 정도로..
글쵸? 코드를 짜면서 얘기해야 하는데..
밀로즈님이 어디에든지 저장소 하나 만들어 주시면 거기서 얘기해봐도 좋을듯 합니다.. ^^
글쵸? 코드를 짜면서 얘기해야 하는데..
밀로즈님이 어디에든지 저장소 하나 만들어 주시면 거기서 얘기해봐도 좋을듯 합니다.. ^^