그누보드5 테마 기능 베타테스트를 시작합니다. 정보
그누보드5 테마 기능 베타테스트를 시작합니다.
본문
그누보드5에 테마를 적용할 수 있는 기능을 개발 중입니다.
기본적인 구조와 프로그래밍은 완료가 되었지만 실제 사용자 및 개발자의 입장에서
그누보드5의 테마 기능이 사용하기 편한지, 구조 변경의 필요성이 있는지 등의
테스트 및 의견 수렴 과정이 필요하다고 생각되어 베타 테스트를 진행하게 됐습니다.
그누보드5 테마 기능에 대한 의견은 댓글 또는 http://sir.co.kr/cm_bug 를 이용해 주시기 바랍니다.
베타버전 다운로드 : http://sir.co.kr/g5_pds/3014
그럼 간단하게 테마 기능에 대한 내용을 적어보도록 하겠습니다.
모든 일에는 시작점이 존재하듯 테마기능 역시 아래의 마인드맵으로부터 시작됐습니다.
이런 기본적인 구조를 바탕으로 약간의 디자인 및 코딩 작업을 거쳐 그누보드5의 테마 기능은 아래처럼 구현이 됐습니다.
테마 설정에서는 테마의 스크린샷을 통해 테마의 모양을 확인할 수 있으며 테마를 바로 적용할 수 있습니다.
테마 미리보기 화면입니다. 미리보기에서는 인덱스, 리스트, 뷰 화면을 제공하며 모바일 기기에서의 화면 역시 확인이 가능한 구조로 되어있습니다.
게시판 스킨 등은 기존의 스킨은 그대로 사용할 수 있도록 했으며 테마에 포함된 스킨이 있다면 이 역시 사용자가 설정 후 사용할 수 있도록 했습니다. 게시판관리 등의 페이지에서 스킨 항목에 skin 폴더에 있는 스킨 뿐만 아니라 테마에 포함된 스킨 역시 노출이 됩니다.
테마에서는 head.php, index.php, tail.php 뿐만 아니라 head.sub.php, tail.sub.php 파일 등도 사용할 수 있도록 해서 기본 그누보드5의 해당되는 각 파일을 대체할 수 있도록 했습니다. jquery 버전 등의 문제가 생긴다면 테마의 head.sub.php 파일을 수정해서 다른 버전의 jquery를 사용하실 수가 있습니다.
추천
0
0
댓글 40개
축하드립니다. 냑프레스가 목표인가봅니다.
위의 구조에서 Update 가 생기면.....ㅜㅜ
처리 로직은 기존 소스에 있고
테마은 UI 만 나오고, 테마에 처리값만 표현하는 방식은 힘들까요?
View 단 분리 <------ 이거 때문에 테마 만들어 배포하고 싶어도
패치 때문에 않하는분들이 더 많을듯 하거든요
처리 로직은 기존 소스에 있고
테마은 UI 만 나오고, 테마에 처리값만 표현하는 방식은 힘들까요?
View 단 분리 <------ 이거 때문에 테마 만들어 배포하고 싶어도
패치 때문에 않하는분들이 더 많을듯 하거든요
제 실력이 부족하여 이해도가 떨어지는 것이라 생각을 하는데요..
View 단을 분리했을 때 기존 스킨과의 호환성에 문제는 생기지 않나요?
View 단을 분리했을 때 기존 스킨과의 호환성에 문제는 생기지 않나요?
부족 하시다니요.....천만의 말씀이세요...
부족한 저의 실력으로
올려주신 소스 대충 더 봤는데,
너무 커지면 사용자들이 어려워하니
이것은 어떨지요?....
css, img, js, skin 은 기존 정식 배포판 구조 그대로 하고
특정 테마을 선택하고서 다른 테마늬 스킨을 같이 사용하게끔하면
같은 화면은 거의 없고 여러 화면이 나오니....
게시판에서 다른분들과 얘기 나누면 어떨까 싶어요...
부족한 저의 실력으로
올려주신 소스 대충 더 봤는데,
너무 커지면 사용자들이 어려워하니
이것은 어떨지요?....
css, img, js, skin 은 기존 정식 배포판 구조 그대로 하고
특정 테마을 선택하고서 다른 테마늬 스킨을 같이 사용하게끔하면
같은 화면은 거의 없고 여러 화면이 나오니....
게시판에서 다른분들과 얘기 나누면 어떨까 싶어요...
다른 테마의 스킨을 가져오는 부분을 고려하지 않은 것은 아닌데요..
문제는 $board_skin_path 등의 경로를 설정할 때 현재의 테마가 아닌
다른 테마의 스킨을 사용한다면 경로 설정 부분이 많이 복잡해져야
하기 때문에 기존 skin 폴더에 있는 스킨과 현재 설정된 테마에 포함된
스킨만 사용자가 설정할 수 있도록 했습니다.
그리고 테마에 css, js, skin 등의 구조를 포함시킨 것은 테마 설치 후
그에 맞는 스킨 등을 skin 폴더에 다시 업로드하는 불편함이 있을 수 있기 때문이었습니다.
테마에 모두 포함되어 있으면 테마 전체 파일을 theme 폴더 업로드 하고
스킨 설정 등은 관리자 페이지에서 별도로 하면 되는 부분이라 생각이 됩니다.
문제는 $board_skin_path 등의 경로를 설정할 때 현재의 테마가 아닌
다른 테마의 스킨을 사용한다면 경로 설정 부분이 많이 복잡해져야
하기 때문에 기존 skin 폴더에 있는 스킨과 현재 설정된 테마에 포함된
스킨만 사용자가 설정할 수 있도록 했습니다.
그리고 테마에 css, js, skin 등의 구조를 포함시킨 것은 테마 설치 후
그에 맞는 스킨 등을 skin 폴더에 다시 업로드하는 불편함이 있을 수 있기 때문이었습니다.
테마에 모두 포함되어 있으면 테마 전체 파일을 theme 폴더 업로드 하고
스킨 설정 등은 관리자 페이지에서 별도로 하면 되는 부분이라 생각이 됩니다.
혹시 생각하시는 구조에 대해 정리해두신 자료가 있으시다면
메일 *** 개인정보보호를 위한 이메일주소 노출방지 *** 으로 보내주시면 검토해보겠습니다.
메일 *** 개인정보보호를 위한 이메일주소 노출방지 *** 으로 보내주시면 검토해보겠습니다.
이러면 냑에서 놀면서 빌더 완성 안한게 잘한건가.....ㅎㅎ
UI부분만 테마에서 관여하고 스킨이나 게시판,회원은 기존방식을 사용하시는것도 좋을듯 한데요. 복잡하면 그것 조차 사용하기 힘들지 않을까요?
그리고 테마관리를 대메뉴로 바꾸시면 어떠실런지....
UI부분만 테마에서 관여하고 스킨이나 게시판,회원은 기존방식을 사용하시는것도 좋을듯 한데요. 복잡하면 그것 조차 사용하기 힘들지 않을까요?
그리고 테마관리를 대메뉴로 바꾸시면 어떠실런지....
ui 부분만 테마에서 관리한다는 게.. 생각보다 쉽지가 않은 것 같습니다.
테마에서 관리할 ui 부분을 어디까지로 정하느냐가 문제가 되겠죠..
이번 테마 기능은 기존 스킨을 그대로 사용할 수가 있고 테마에 포함된
스킨이 있다면 그것도 사용자가 선택을 할 수 있는 구조입니다.
테마의 스킨이 싫다면 기존 skin 폴더에 있는 스킨을 그대로 사용할 수 있습니다.
회원 등의 스킨 역시 마찬가지입니다.
테마에서 관리할 ui 부분을 어디까지로 정하느냐가 문제가 되겠죠..
이번 테마 기능은 기존 스킨을 그대로 사용할 수가 있고 테마에 포함된
스킨이 있다면 그것도 사용자가 선택을 할 수 있는 구조입니다.
테마의 스킨이 싫다면 기존 skin 폴더에 있는 스킨을 그대로 사용할 수 있습니다.
회원 등의 스킨 역시 마찬가지입니다.
제가 말주변이 없다보니.....ㅠㅠ
테마에서 관리할 UI는 메인과 서브페이지, 메뉴 정도만 관리하고
그외
이부분은 기본 디렉토리를 사용하면 되지 않을까요?
물론 편리님께서 말씀하신 테마와 스킨등을 사용자가 선택 가능한 구조로 만들어야 겠지요.
테마에서 관리할 UI는 메인과 서브페이지, 메뉴 정도만 관리하고
그외
이부분은 기본 디렉토리를 사용하면 되지 않을까요?
물론 편리님께서 말씀하신 테마와 스킨등을 사용자가 선택 가능한 구조로 만들어야 겠지요.
저두 말주변이 좋은 게 아니라서요.. ^^;
테마에서 필수 파일은 head.php, index.php, tail.php 파일입니다. 그외 파일과
디렉토리는 필요에 따라 삭제해도 되는 부분입니다. 예를 들어 테마안에 skin
디렉토리가 없다면 기존 skin 디렉토리의 스킨만을 사용하게 됩니다.
테마에 중복되는 걸 알면서 skin 등의 기본 디렉토리를 넣은 것은 테마제작자가
해당 테마에 맞게 회원 스킨 등의 디자인을 새로 했을 경우 테마에 skin 디렉토리가
없다면 테마외에 추가된 스킨을 별도 배포해서 사용자가 그 스킨을 skin 디렉토리에
업로드 해야만 합니다. 그런데 테마에 skin 디렉토리가 있고 그 안에 새로 만든
스킨을 함께 넣어서 배포를 하게 되면 사용자는 테마 전체를 한번만 업로드하면
되고 스킨은 관리자 페이지 지정을 하면 됩니다.
이 방법이 저는 일반 사용자입장에서는 편하겠다라고 생각을 했기 때문에
지금의 구조로 구현이 된 것입니다. css, img 등의 디렉토리 역시 이런 이유때문에
중복이 되는 걸 알면서 테마 디렉토리 구조에 포함되게 된 것입니다.
테마에서 필수 파일은 head.php, index.php, tail.php 파일입니다. 그외 파일과
디렉토리는 필요에 따라 삭제해도 되는 부분입니다. 예를 들어 테마안에 skin
디렉토리가 없다면 기존 skin 디렉토리의 스킨만을 사용하게 됩니다.
테마에 중복되는 걸 알면서 skin 등의 기본 디렉토리를 넣은 것은 테마제작자가
해당 테마에 맞게 회원 스킨 등의 디자인을 새로 했을 경우 테마에 skin 디렉토리가
없다면 테마외에 추가된 스킨을 별도 배포해서 사용자가 그 스킨을 skin 디렉토리에
업로드 해야만 합니다. 그런데 테마에 skin 디렉토리가 있고 그 안에 새로 만든
스킨을 함께 넣어서 배포를 하게 되면 사용자는 테마 전체를 한번만 업로드하면
되고 스킨은 관리자 페이지 지정을 하면 됩니다.
이 방법이 저는 일반 사용자입장에서는 편하겠다라고 생각을 했기 때문에
지금의 구조로 구현이 된 것입니다. css, img 등의 디렉토리 역시 이런 이유때문에
중복이 되는 걸 알면서 테마 디렉토리 구조에 포함되게 된 것입니다.
듣고보니 이 방법도 나쁘진 않네요....^^
이방법이 기준이 된다면 그방법을 따라가도 좋을것 같습니다.
이방법이 기준이 된다면 그방법을 따라가도 좋을것 같습니다.
이젠 빌더를 딛고 올라설 테마버전이 출시 되는건가요? 하긴 테마적용이 접근도 쉽고 커스텀도 용이하고 좋네요 ㅎㅎ;; 간편하게 테마에 따라 사이트분위기도 확확 바꾸고 ㅎㅎ..
아 근데.. 테마설정을..테마관리 로 해서 대메뉴로 확 빼면 더 좋을것 같은 느낌이 ㅋㅋ
아 근데.. 테마설정을..테마관리 로 해서 대메뉴로 확 빼면 더 좋을것 같은 느낌이 ㅋㅋ
편리님...역시...
엄청난걸 준비하고 계셨군요.
그누보드가 아닌 그누웨어가 되겠군요 ㅋㅋ
옷을 입히는 시스템이라 +_+
엄청난걸 준비하고 계셨군요.
그누보드가 아닌 그누웨어가 되겠군요 ㅋㅋ
옷을 입히는 시스템이라 +_+
그누웨어 이름 좋네요?
+1
드디어 어떻게 감사를 드려야 할지요. ^^
살았다 ㅎㅎㅎㅎ
살았다 ㅎㅎㅎㅎ
그럼 그누5는 앞으로 위와 같은 테마기능을 포함하여 업데이트 된다는 얘기겠죠..?
영카트에 대한 테마기능도 계획중인건지요..?
영카트에 대한 테마기능도 계획중인건지요..?
테마기능 베타테스트 종료 후 테마기능이 기본 포함된 그누보드5가 배포됩니다.
영카트5에 대한 테마도 되는건가요?
먼저 그누보드5에 대한 테마기능이 완료되면 영카트5 역시 테마 기능을 지원할 예정입니다.
네에 알겠습니다. 테스트 해보고 제안이나 버그 있으면 의견 드려보겠습니다.
아하 대규모업데이트가 이것 말씀이셨군요. 고생 많으셨습니다. 테스트 잘 거쳐 안정적인 버전으로 지원되면 좋겠네요. ^^
안정적인 버전이 되면.. 영카트5가 기다리고 있죠.. ㅎㅎ
이번 기능 관련해서 몇군데 좀 물어봤는데 다들 반응이 제각각이네요. 제법 흥미롭습니다.
시원한 거 땡기실 때 톡 함 주세요~ ㅎㅎㅎ
시원한 거 땡기실 때 톡 함 주세요~ ㅎㅎㅎ
그러죠.. 리자님과 상의해볼게요.
반응이 제각각이라.. 어느 정도 예상은 했지만.. ㅎㅎ
반응이 제각각이라.. 어느 정도 예상은 했지만.. ㅎㅎ
좋네요!! 지지합니다.
한번에 업로드해서 클릭 한번에 적용되는게 좋지요
한번에 업로드해서 클릭 한번에 적용되는게 좋지요
좋은 소식이네요. 앞으로 많은 기대하겠습니다.
고생 많으십니다.
구조 잡는데 고민 많으셨겠네요~
멋진 작품 기대합니다. 화이팅하셔요!
멋진 작품 기대합니다. 화이팅하셔요!
기대됩니다...빨리 정식 버전이 나오길 바래봅니다.
고생많으셨어요!
그리고 또 고생하시겠군요! ㅋㅋㅋ
그리고 또 고생하시겠군요! ㅋㅋㅋ
우왓, 저같은 초보도 쉽게 사용할 수 있을까요?!!!
시간있을 때 함 들여다 보겠습니다!! 기대되네요 ㅠ ㅠ
시간있을 때 함 들여다 보겠습니다!! 기대되네요 ㅠ ㅠ
테마
많은 고민과 노력의 흔적이 보입니다.
고생많으셨습니다.
개인적인 생각은
일단 제로보드만세!
오픈보드의 특성상 사용자 계층이 여러갈래로
나누어 집니다.
하드코딩 베이스의 솔루션들이
사용자단의 기능들을 배려해 많은 기능들을 넣을수록
기본적인 솔루션의 덩치가 커지는건 어쩔수 없는듯 합니다.
그누보드나 영카트의 "편리" 한 점 중 하나는
저같이 발로 코딩하는 개발자 입장에서는
차고 넘치지 않을정도의 필요한 기능만 있다라는 점입니다.
UI에 편의를 주고 wyswyg 기능을 강화할수록
사용자 편의기능은 늘겠지만
XE로 넘어가면서 오히려 기본기능 수정자체가 어려워졌던
제로보드의 전철을 밟게 되지 않을까
고민이 됩니다.
"만들어 준대로 써라. 대신 니가 필요한 만큼의 기능을 넣어주겠다." 라는것과
"기본기능에 충실히 만들었으니 더 필요한건 만들어서 써라."라는 문제는
원래부터가 양립할 수 없는 문제인것 같습니다. 어느것이 옳다고 할 수도
없는것 같구요.
테마 적용이 위에서 언급한것 만큼의 문제를 야기할 부분은 아니지만
고민해 볼 부분이 아닌가 혹은 이런 의견도 있더라
정도로 들어주시면 좋을것 같습니다.
멋진 작품 기대합니다.
ps . G5_PATH 요런거 상수들 대문자로 다 정의해놔서
타이핑 할때 대문자 치면서 욕 많이 했습니다. 오래 사실겁니다 크하하
고생많으셨습니다.
개인적인 생각은
일단 제로보드만세!
오픈보드의 특성상 사용자 계층이 여러갈래로
나누어 집니다.
하드코딩 베이스의 솔루션들이
사용자단의 기능들을 배려해 많은 기능들을 넣을수록
기본적인 솔루션의 덩치가 커지는건 어쩔수 없는듯 합니다.
그누보드나 영카트의 "편리" 한 점 중 하나는
저같이 발로 코딩하는 개발자 입장에서는
차고 넘치지 않을정도의 필요한 기능만 있다라는 점입니다.
UI에 편의를 주고 wyswyg 기능을 강화할수록
사용자 편의기능은 늘겠지만
XE로 넘어가면서 오히려 기본기능 수정자체가 어려워졌던
제로보드의 전철을 밟게 되지 않을까
고민이 됩니다.
"만들어 준대로 써라. 대신 니가 필요한 만큼의 기능을 넣어주겠다." 라는것과
"기본기능에 충실히 만들었으니 더 필요한건 만들어서 써라."라는 문제는
원래부터가 양립할 수 없는 문제인것 같습니다. 어느것이 옳다고 할 수도
없는것 같구요.
테마 적용이 위에서 언급한것 만큼의 문제를 야기할 부분은 아니지만
고민해 볼 부분이 아닌가 혹은 이런 의견도 있더라
정도로 들어주시면 좋을것 같습니다.
멋진 작품 기대합니다.
ps . G5_PATH 요런거 상수들 대문자로 다 정의해놔서
타이핑 할때 대문자 치면서 욕 많이 했습니다. 오래 사실겁니다 크하하
좋은 의견 감합니다.
+1
개인적인 생각은
일단 제로보드만세! 부분에서 빵 터졌어요 ㅎㅎㅎㅎㅎㅎㅎ
일단 제로보드만세! 부분에서 빵 터졌어요 ㅎㅎㅎㅎㅎㅎㅎ
엄청 기대됩니다. 멋진 작품 기다려 지네요...
테마기능 사용해봤는데 정말 최고군요..
일하기 재미있어집니다.
일하기 재미있어집니다.
와~ 계속해서 발전하는 그누보드. 대단합니다.
