편리님 도와 드려야 저희들도 먹고 살죠 > 자유게시판

자유게시판

편리님 도와 드려야 저희들도 먹고 살죠 정보

편리님 도와 드려야 저희들도 먹고 살죠

본문

 

서로 얘기 나누면 어떠실지 해서....

 

편리님께소 올려주신 구조에서 

- 기존 소스로 운영하시는분들 소스 그대로 살리는 방향

- 패치하기 쉬운 효과적인 구조

 

편리님께서 올려주신 맵과 소스을 보고 

최대한 살리는 방향으로 저의 사견을 적어 봐요.

 

 ........

........

 

1) 전체 layout 은 테마(자체적)으로 만든다

2) SKIN 부분은 다른 분들의 테마 스킨을 공유 할 수 있게 한다

3) 공통된 js, css 을 같이 사용한다...(예) bootstrap (css, js)

 

4) 테마나 스킨명은 앞에 유일한 명칭으로 한다

     구분: 닉네임_종류

    예) theme 명 : /theme/bengi​_sky

         해당 테마 스킨명 : /skin/board/bengi_sky

 

 

이렇게 되면 기존것도 살리고, 다른분들의 테마나 스킨도 공유되고

스킨들이 서로 썩여서 유일한 화면이 나올수는 없을것 같아서요

게다가 파일 용량도 줄어들고...

 

 

[ 제가 느낀 가장 문제 되는 부분 ]

 

그누 patch 에서 skin 쪽에 수정(기능추가,삭제,변경)이 발생하는 경우

기존 소스을 최대한 않 건드리는 방법인데

MVC 로 하더라도 손은 다 봐줘야 하니​, 이건 100% 정답이 없는것 같는데

기존 사용자들을 고려해야 하니 좋은 방법이 없을지 아직도 생각만...

 

........

........

 

위의 기기별로 큰 모바일 기기일 경우 반응형이나 PC 화면으로 가게 분리 시키면 어떨까 싶어서요..

기기 화면은 PC 화면처럼 큰데, 모바일 화면이 나와서요.

 

당장 떠오르는 생각을 정리 없이 작성하는거라 참고만 해 주셔요..

 

 

추천
0
  • 복사

댓글 18개

디렉토리 구조에서 mobile 안에 theme를 추가하신 건 모바일용 테마 때문이겠죠?
저는 테마기능을 기획할 때 각각 분리해서 테마 파일을 업로드하는 것보단 theme 디렉토리에
테마 관련 전체 파일을 한번만 업로드 하는 게 편할 것이라 생각을 했습니다. 그래서 지금의
구조가 된 것이구요.. 이 부분은 사용자마다 느끼는 것이 다를 수 있습니다.

또한 반응형 관련해서 실제로 테마를 만들어 본 것이 아니라서 확실치는 않지만 제 생각은
테마에 포함된 mobile 디렉토리에 스킨 등이 없으면 PC용 스킨이라고 해야겠죠? 상위의
스킨을 적용하는 방법을 생각했습니다. 현재 베타 버전에 포함된 베이직 테마의 구조는
가장 기본적인 구조이지만 mobile 디렉토리는 없어도 된다는 것입니다.

그리고 해상도가 큰 기기에서는 특정 화면으로 이동시키는 것은 사용자 또는 테마 제작자의
몫으로 남겨둬야 한다고 생각을 합니다. 이건 이거니까 이렇게 해.. 라고 강제를 하는 것은
제 개인적인 생각과 맞지 않는 부분입니다.

개인적인 생각이지만 저는 테마 기능을 만들면서 모바일 전용 테마를 만들어 보는 것은
어떨까라는 생각을 했습니다. 이런 경우라면 device 분리를 코어단에서 해버리게 되면 테마
제작자의 의도대로 작업하는 게 쉽지 않을 것 같다는 생각이 듭니다.
A)
mobile 안에 theme를 추가 한거 <----- 예에....^^

B)
그누 Patch 문제로 이리저리 만들다 최종 확정 지은 구조가
지금 본 글과 비슷한 구조구요

C) common.php 에 지금처럼 mobile 인지, pc 인지에다가
    response 값만 추가해 주셔도 감지 덕지예요....ㅋ

D)
저의 부족한 시견으로는 의뢰자님들의 공통점이 크게 나뉘더라구요

1) PC 화면
2) 모바일 화면
3) 반응형 화면
4) 앱 (하이브리드)
5) 관리자 화면 ( 최고관리자외 서브 관리자 )
    5-1) PC 용 관리자 화면
    5-2) 모바일 용 관리자 화면

그래서
"기기별로 다른 화면이 필요하다" 라는 생각이 들었어요..
agent 에 기기 명칭들이 있어서 명칭별로 가로와 세로폭이
노트2 이상인 경우 Response 로 하면 어떨까 했어요.

강제성을 않 주고 싶으시다면
function_exists 을 최대한 활용해서
있다면 개발자가 정의한걸 적용하고
없다면 기본 소스 이용하고.....
노트2 이상이면 response 로 정해버리는 건 아무래도 위험할 것 같습니다.
response 로 결과를 넘겨줄 경우를 상수 등에 직접 정의하도록 하는 게 맞을 것 같습니다.
예에....
고객님들은 자동으로 원했지만
편리님께서 개발 하시는것이니 맞죠....^-^

게시판보니 저만 떠들어서, 저도 앞으로는 공개적으로는 않할께요...ㅋ
주시대로 넙죽...
C) common.php 에 지금처럼 mobile 인지, pc 인지에다가
    response 값만 추가해 주셔도 감지 덕지예요....ㅋ

라고 적어주셨는데요.. 아무래도 벤지님이 생각하고 있는 것을
이해할 수가 없어 다시 댓글을 남깁니다. 현재 G5_IS_MOBILE
상수에 true, false 대신 response 를 넘겨 달라는 건가요?

근데 이렇게 하면 if(G5_IS_MOBILE) 는 true 이기 때문에 벤지님의
의도대로 작동을 하지 않을 것 같습니다. 만약 이게 맞다면 기존
코드도 수정을 해야하는 문제가 있구요.. 이게 맞는 건가요?
제가 볼때는 일단,

1. 세션 저장 방식의 다양화

2. common.php 에 변수를 받던 common.php 를 용도별로 나누던지 해서

디비 사용이 필요없는 경우, 세션 사용이 필요없는 경우 로 나누어서 사용할수 있으면 좋겟습니다.

아작스로 호출되는 경우의 파일들은 세션이 필요없거나 디비연결이 필요없이 요청수만 많을수 있는 경우가 많습니다.

3. 기존 스킨의 호환성 문제를 고려하지 말고 보안위주로 작업되면 좋겟습니다.

extract 는 일단 빼는게 좋다고 봅니다.

4. 짧은 주소 사용 지원

저는 이정도만 먼저 반영되면 좋을것 같습니다.
© SIRSOFT
현재 페이지 제일 처음으로