ress가... 정보
ress가...
본문
head1.php
head2.php
head3.php
이렇게 만들어 놓고 기종 또는 가로 사이즈별로 호출하는건가요?
그럼 업데이트도 세파일 다 따로 해 줘야하는건가요!?
추천
0
0
댓글 9개
제가 보기에 RESS를 가장 쉽게 설명하면서
동시에 RESS의 단점을 명확히 보여준 설명/이해이신것 같습니다. ^^
동시에 RESS의 단점을 명확히 보여준 설명/이해이신것 같습니다. ^^
미디어쿼리와 마찬가지로 장단점이 있는 방법이군요... 모바일 트래픽만 우선으로 생각하면 보이지않는 항목들 불러서 display:none하는 미디어쿼리보다는 위대하게 보이는 방법입니다 ㅡ.,ㅡ;;
좀더 살을 붙이자면,
RESS라는 개념이 사실상 코딩단위로 내려가면 천차만별의 구현이 가능할 것 같습니다.
HackYa님이 말씀하시는 (거의 모든) 컨텐츠와 스타일을 별도로 만드는 형태도 가능할 것이고,
서버측 반응형 이미지의 선택적 전송 ( http://sir.co.kr/bbs/board.php?bo_table=pb_lecture&wr_id=247#vc_ri_ss ) 처럼 한단위만을 콘트롤 할 수도 있을것 같고요.
제 개인적인 생각은, 가능하면 잘게 잘라서 구현해야, 보다 유연한 구현이 가능하고, 또한 관리측면에서도 낫지 않을까 하는 것입니다.
RESS라는 개념이 사실상 코딩단위로 내려가면 천차만별의 구현이 가능할 것 같습니다.
HackYa님이 말씀하시는 (거의 모든) 컨텐츠와 스타일을 별도로 만드는 형태도 가능할 것이고,
서버측 반응형 이미지의 선택적 전송 ( http://sir.co.kr/bbs/board.php?bo_table=pb_lecture&wr_id=247#vc_ri_ss ) 처럼 한단위만을 콘트롤 할 수도 있을것 같고요.
제 개인적인 생각은, 가능하면 잘게 잘라서 구현해야, 보다 유연한 구현이 가능하고, 또한 관리측면에서도 낫지 않을까 하는 것입니다.
하지만 벌써 어느개발자분은 G5 를 너무 잘게 썰어놨다고 하시네요. 그리고 한편에서는 더 잘게 썰어야 할 것 같다는 의견이 나올 것 같고...
제 개인적인 생각이지만, 그래서 G5에서 이부분을 워드프레스 처럼 플러그인으로 처리했으면 어땠을까 하는 생각이 조금 들긴 하지만, 그건 아마 제가 워드프레스 사용자라서, 그런 생각이 드는 것 같습니다.
제 개인적인 생각이지만, 그래서 G5에서 이부분을 워드프레스 처럼 플러그인으로 처리했으면 어땠을까 하는 생각이 조금 들긴 하지만, 그건 아마 제가 워드프레스 사용자라서, 그런 생각이 드는 것 같습니다.
아실지 모르겠지만, G4, G5 용 wp 형태의 플러그임 프레임웍이 있기는 합니다.
byfun님의 GPF 죠: http://sir.co.kr/bbs/board.php?bo_table=g5_plugin&wr_id=68
이전에 나린위키때의 프레임워크보다 더 쉬운 형태로 만드셨다는데,
나린위키도, 제가 필요한 (위키) 플러그인 만들어서 잘 사용하고 있고요..
개인적으로, 그누보드의 스킨 방식 커스터마이징이 큰 장점이 있다고는 생각하는데
G5에서는 테마나 플러그인 방식도 들어왔으면 하는 바람이 있었죠. ^^
byfun님의 GPF 죠: http://sir.co.kr/bbs/board.php?bo_table=g5_plugin&wr_id=68
이전에 나린위키때의 프레임워크보다 더 쉬운 형태로 만드셨다는데,
나린위키도, 제가 필요한 (위키) 플러그인 만들어서 잘 사용하고 있고요..
개인적으로, 그누보드의 스킨 방식 커스터마이징이 큰 장점이 있다고는 생각하는데
G5에서는 테마나 플러그인 방식도 들어왔으면 하는 바람이 있었죠. ^^
전진님 역시 워프의 방식에 익숙하시기 때문에 워프식의 테마나 플러그인 방식을 편하게 생각하실 수 있는게 아닐까 생각 됩니다.
하지만 대다수 개발자 분들이 워프를 접해보신 적이 없고, 이런 워프식 테마나 플러그인 구조를 core 단 차원에서 도입하려고 하면 그 저항이 엄청날거에요.
제 기억으로는 여러번 그누보드의 스킨이나 빌더에 대한 표준화/규격화에 대한 논의가 있었는데, 일단 리자님이 큰 관심이 없으신 걸로 알고 있습니다.
또 이런 문제도 있을 겁니다. core 단 차원에서 스킨이나 빌더에 대한 획일화를 강요하게 되면, 누구나 쉽게 빌더를 만들어 낼수 있게 됩니다. 어떠어떠한 파일들이 어떤 name 명을 갖고 어디에 속해야 하고, 이런 룰을 만들면, 누구나 그 룰만 따르면 테마를 만들어 낼수 있게 되는데요. 빌더 제작에 대한 하나의 메뉴얼이 생기는거죠. 현재 빌더제작하시는 분들이 이걸 반가워하지는 않으실 겁니다.
아무빌더나 워프처럼 설치했다 삭제하고, 맘에 드는걸 또 설치해 보고, 이런식의 무한경쟁이 되어 버리면, 유료빌더 제작자 분들의 수익에 막대한 지장이 생길거고...
저는 개인적으로 이런건 바라지 않습니다. 그분들도 밥먹고 사셔야 하는데....
하지만 대다수 개발자 분들이 워프를 접해보신 적이 없고, 이런 워프식 테마나 플러그인 구조를 core 단 차원에서 도입하려고 하면 그 저항이 엄청날거에요.
제 기억으로는 여러번 그누보드의 스킨이나 빌더에 대한 표준화/규격화에 대한 논의가 있었는데, 일단 리자님이 큰 관심이 없으신 걸로 알고 있습니다.
또 이런 문제도 있을 겁니다. core 단 차원에서 스킨이나 빌더에 대한 획일화를 강요하게 되면, 누구나 쉽게 빌더를 만들어 낼수 있게 됩니다. 어떠어떠한 파일들이 어떤 name 명을 갖고 어디에 속해야 하고, 이런 룰을 만들면, 누구나 그 룰만 따르면 테마를 만들어 낼수 있게 되는데요. 빌더 제작에 대한 하나의 메뉴얼이 생기는거죠. 현재 빌더제작하시는 분들이 이걸 반가워하지는 않으실 겁니다.
아무빌더나 워프처럼 설치했다 삭제하고, 맘에 드는걸 또 설치해 보고, 이런식의 무한경쟁이 되어 버리면, 유료빌더 제작자 분들의 수익에 막대한 지장이 생길거고...
저는 개인적으로 이런건 바라지 않습니다. 그분들도 밥먹고 사셔야 하는데....
HackYa님의 분석이 아마 정확할 것 같습니다.
리자님도 개발 경력이 보통이 아니실텐데, 플러그인 같은 구성을 만들지 않고 스킨의 형태로 계속 유지하시는 이유이겠지요.
저도 스킨/빌더 규격화 표준화도 몇번 제안해봤는데, 우선 리자님이 관심이 없으시니.. ^^;
그리고 말씀대로 빌더제작 하는 분들이나, 외주작업 하시는 분들도 크게 환영하지 않을것 같네요..
리자님도 개발 경력이 보통이 아니실텐데, 플러그인 같은 구성을 만들지 않고 스킨의 형태로 계속 유지하시는 이유이겠지요.
저도 스킨/빌더 규격화 표준화도 몇번 제안해봤는데, 우선 리자님이 관심이 없으시니.. ^^;
그리고 말씀대로 빌더제작 하는 분들이나, 외주작업 하시는 분들도 크게 환영하지 않을것 같네요..
그리고 절대 리자님이 워드프레스의 코드를 도용했다는 소리가 아니라, 새로 구현된 G5 의 로직의 일부가 (모바일 용 element 의 path 를 지정하고 불러오는 부분) 놀랍도록 닮아 있습니다. ㅎㅎㅎㅎㅎ
그래서 저는 G5에 대해 쉽게 이해가 왔고 감탄을 할수 밖에 없었던 것 입니다.
그래서 저는 G5에 대해 쉽게 이해가 왔고 감탄을 할수 밖에 없었던 것 입니다.
아, 모노폴리님 질문. ㅎㅎㅎㅎ
head.php 가 3개일수도 두개일 수도 하나일 수도 있습니다.
얼마나 잘개 써느냐 그 문제죠. 그러니까 head.php 에서 include 되는 element 들만 접근하는 기기에 따라 바뀌는 구조라면 굳이 head.php 가 여러개일 필요가 없습니다.
그부분이 단점인가? 아니라고 저는 주장합니다.
그누보드 처럼 오픈소스의 경우 그 로직을 (그 로직이 얼마나 잘게 썰리든 간에) 사용자가, 또 사이트 구축자가 다시 만들 필요가 없기 때문입니다.
head.php 가 3개일수도 두개일 수도 하나일 수도 있습니다.
얼마나 잘개 써느냐 그 문제죠. 그러니까 head.php 에서 include 되는 element 들만 접근하는 기기에 따라 바뀌는 구조라면 굳이 head.php 가 여러개일 필요가 없습니다.
그부분이 단점인가? 아니라고 저는 주장합니다.
그누보드 처럼 오픈소스의 경우 그 로직을 (그 로직이 얼마나 잘게 썰리든 간에) 사용자가, 또 사이트 구축자가 다시 만들 필요가 없기 때문입니다.