1

주제: 스킨변경시 사이드바 초기화에 대해서...

스킨을 변경할때마다, 사이드바가 초기화 되더군요.
초기화 되지 않도록 할 수 없나요???
어느경우에 보니, 사이드바를 3단으로 할 수 있게 하고,
그 3단을 일렬로 표현해서, 1단형식을 취하는 경우를 본적이 있는데...

이와같이, 기본으로 3단으로 할 수 있게 하고, 각 구성을 기억하게해서.
이리저리 스킨을 테스트해보려 바꾸는중에, 사이드바 등이 초기화 되지 않도록 할 수 없을까 합니다.

역시, 스킨의 edit 모드에서 값을 변경하였을때,
다른 스킨으로 갔다가 다시 오면, 역시 초기화 되어 있는데...
이 문제도 해결할 수 없나요???

Yesterday is history, tomorrow is a mystery, and today is a gift; that's why we call it - present

2

답글: 스킨변경시 사이드바 초기화에 대해서...

htna 작성:

스킨을 변경할때마다, 사이드바가 초기화 되더군요.
초기화 되지 않도록 할 수 없나요???

음... 이런 상황이 있을 수 있지 않을까요. A라는 스킨 사이드바에는 달력 모듈이 있고, B라는 스킨 사이드바에는 달력 모듈이 없습니다. 사용자는 A 스킨을 쓰고 있었고, 지금 B라는 스킨으로 바꿨습니다. 이렇게 하면 달력 모듈의 정보는 증발해야 맞는 거죠. 사이드바 시스템에서 누락된 모듈을 찾아내 자동으로 제거해 주면 좋겠지만 사이드바 내부 시스템 상에서 개별 모듈은 아이덴티티를 가지고 있지 않습니다. 전부 order 값으로 구분되고 있지요. 이 문제점 때문에 스킨 변경시마다 초기화되고 있습니다.

htna 작성:

역시, 스킨의 edit 모드에서 값을 변경하였을때,
다른 스킨으로 갔다가 다시 오면, 역시 초기화 되어 있는데...
이 문제도 해결할 수 없나요???

이 문제는 스킨 편집의 중간 경유지로 customize 디렉토리를 공유하기 때문에 생기는 문제입니다. A스킨을 사용중 스킨 편집을 눌러 내용을 바꾸고 저장하면 customize 디렉토리에 저장되고 현재 사용중인 스킨이 customize 디렉토리 안에 있는 스킨으로 바뀝니다. 이 상태에서 B스킨으로 바꾸시면 현재 스킨은 B스킨이 되고, 이 상태에서 편집을 누르시면 customize 디렉토리 안에 있던 내용은 B스킨으로 덮이게 되죠. 이 상황을 반복하기 때문에 매번 초기화 되는 것입니다. 이 문제는 현재 다음 버전의 개선사항에 포함되어 있습니다. 자신이 편집한 스킨은 디렉토리를 정해 따로 저장하거나 다운로드 받을 수 있도록 개선할 생각입니다.

3

답글: 스킨변경시 사이드바 초기화에 대해서...

graphittie 작성:
htna 작성:

스킨을 변경할때마다, 사이드바가 초기화 되더군요.
초기화 되지 않도록 할 수 없나요???

음... 이런 상황이 있을 수 있지 않을까요. A라는 스킨 사이드바에는 달력 모듈이 있고, B라는 스킨 사이드바에는 달력 모듈이 없습니다. 사용자는 A 스킨을 쓰고 있었고, 지금 B라는 스킨으로 바꿨습니다. 이렇게 하면 달력 모듈의 정보는 증발해야 맞는 거죠. 사이드바 시스템에서 누락된 모듈을 찾아내 자동으로 제거해 주면 좋겠지만 사이드바 내부 시스템 상에서 개별 모듈은 아이덴티티를 가지고 있지 않습니다. 전부 order 값으로 구분되고 있지요. 이 문제점 때문에 스킨 변경시마다 초기화되고 있습니다.

네.
비슷한 문제로 이러한 처리가 골치아프리라 미리 생각하고 있었습니다.
1.1.0.2 깔아본 결과, 현재의 스킨은 sidebar를 dynamic하게 정리할 수 있는듯 합니다.
제 생각입니다만. (소스를 보고 이해하고 말씀을 드려야 옳은것으로 생각됩니다만. 현재 이해해 주시기 바랍니다.)
기존의 방법은 [##_달려_##], [##_트랙백_##] 등과 같이 처리하던것을.
현재의 방법에서는 [##_사이드바_##] 로 처리하면서, 내부적으로 순서를 DB등에 저장하고 있는듯 합니다만...

이렇다면,
[##_사이드바1_##], [##_사이드바2_##], [##_사이드바3_##]
와 같이 3개의 기본카테고리로 두고,
스킨편집자가 사이드바1 을 왼쪽, 사이드바2 를 오른쪽, 사이드바3 을 아래쪽 등에 배치하거나,
다른 스킨편집자는 사이드바1, 2, 3 을 모두 나란히 오른쪽, 혹은 왼쪽 등에 배치하게하면,
이런문제가 어느정도 해결되지 않을까 합니다.
물론 [##_달려_##] 등을 직접 사용하는 경우라면, 사이드바1 의 order는 남아있는다고 전제를 하구요.

추가로, [##_사이드바1_##] 의 아이템들인 [##_달려_##], [##_트랙백_##], [##_링크_##] 등이...
가로로출력 이면
[##_달려_##], [##_트랙백_##], [##_링크_##]
이렇게 (이경우는, 본문 밑에 리스트를 달 경우...)
세로로출력 이면
[##_달려_##]
[##_트랙백_##]
[##_링크_##]
와 같이 지정할 수 있게 된다면, (이경우는, 본문 좌/우 쪽에 리스트를 달 경우...)
스킨개발자와 사용자간의 자유도(??)도 높이고, 테더스킨의 사용자도 늘릴 수 있지 않을까 합니다.

Yesterday is history, tomorrow is a mystery, and today is a gift; that's why we call it - present

4

답글: 스킨변경시 사이드바 초기화에 대해서...

현재 사이드바의 갯수는 스킨에 따라 다르게 지정할 수 있도록 되어 있습니다. (스킨에 사이드바 영역을 몇 번 지정했느냐에 따라 안 써도 되고 세 개 써도 됩니다. 더 써도 되려나?)  말씀하신대로 사이드바 갯수를 고정하는 방법도 있겠지만, 사이드바 갯수의 자유도는 유지해 줘야 하지 않나 싶습니다.^^

그리고 사이드바 아이템의 경우 스킨에 내장되어 있는 사이드바 패널과 플러그인이 만든 패널을 함께 사용하도록 되어 있습니다. 스킨이 변경될 경우에도 사이드바 설정을 유지하면 스킨에 내장된 사이드바 아이템의 처리가 미묘해집니다. 본질적으로, 이 스킨에서 구현하고 있는 사이드바 패널에 들어있는 '최근 트랙백' 이 저 스킨에 구현되어 있는 '최근 트랙백' 과 같을 필요가 없기 때문입니다. 그것들이 같은 패널인지에 대해서도 판단을 해야겠죠.

각 사이드바가 어떻게 출력되는가에 대한 아웃라인은 스킨에서 어떻게 표현하고 지정하느냐에 따르는 구조입니다. (완전히 디자인 요소이죠) 말씀하신 경우라면 3단 스킨의 양쪽에 사이드바 영역을 지정하고, footer영역에 사이드바 영역을 지정한 후 스킨 제작자가 거기에 들어가면 좋을 부분을 구현한 후 그냥 패널 치환자 (<s_sidebar_element> 였을거에요)로 묶으면 됩니다. 가로세로도 스킨에서 디자인 하는대로 들어갑니다. 현재 사이드바의 자유도 부분은 스킨에 다 주어져 있습니다.

편집 초기화 문제는 대안을 생각 중입니다. 스킨 편집하면서 스킨에 내장된 사이드바의 기본값이나 위치도 변경할 수 있기 때문에 (뭣하면 만들어 넣을 수도 있죠) 이걸 어떻게 해야 할지 참 어렵네요.

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

5

답글: 스킨변경시 사이드바 초기화에 대해서...

위와 같은 (사이드바&스킨특성화) 에 대해서 다을과 같이 처리하면 되지 않을까 생각합니다.

우선, 스킨마다 선호하는 사이드바의 구성이 다르리라 생각됩니다.
그리고, 각 스킨마나 지정하는 특성화가 다르리라 보구요.
이 문제를 해당 스킨디렉토리에 저장하는 방식이 어떨까 생각합니다.
예를들어...

custom.skin.html <- skin.html 을 사용자가 수정하였을 경우에 저장되는 파일 입니다.
custom.style.css <- style.css 를 사용자가 수정하였을 경우에 저장되는 파일 입니다.
cuntom.sidebar.xml <- 사용자가 사이드바의 위치 구성 등을 수정하였을 경우에 저장되는 파일 입니다. 이는 xml로 하지 않고 txt로 적당히 저장을 해도 될 듯 합니다.

이와같이 저장을 한다고 하구요...
사용자가 테더에서 스킨을 선택하는 순간,
저 화일들이 있으면, 그냥 그 화일을 오픈합니다.
저 화일들이 없으면, 스킨화일을 복사해서 저 화일들을 만든뒤, 오픈합니다.
블로그 홈페이지가 오픈되면, 기본적으로 저 화일들이 존재한다는 가정을 두고 이용합니다.

이렇게 하면, 속도문제와, 각 테마별 스킨화일 커스터마이징을 같이 할 수 있다고 보여집니다.
물론, 기존의 테마가 저 화일들을 가지고 있다면, 문제가 될 수 있습니다만, 우선 저런 이름을 가질일이 거의 없다고 보구요.
화일이름으로 custom.* 인 화일은 테더에서 기본적으로 customize를 위한 화일이므로, 임의로 스킨개발자가 만들지 말도록 하자 고 한다면, 앞으로의 확장에 여유가 생길 듯 합니다.

그리고, 앞서, sidebar 문제로 고민이 된다고 하셨습니다만,
custom.sidebar.xml 등과 같이 처리한다면, 각 스킨이 사용하고 있는 sidebar pannel의 처리 역시 쉽게 해결되지 않을까 합니다.

htna (2006-12-08 20:27:50)에 의해 마지막으로 수정

Yesterday is history, tomorrow is a mystery, and today is a gift; that's why we call it - present

6

답글: 스킨변경시 사이드바 초기화에 대해서...

htna 작성:

위와 같은 (사이드바&스킨특성화) 에 대해서 다을과 같이 처리하면 되지 않을까 생각합니다.

우선, 스킨마다 선호하는 사이드바의 구성이 다르리라 생각됩니다.
그리고, 각 스킨마나 지정하는 특성화가 다르리라 보구요.
이 문제를 해당 스킨디렉토리에 저장하는 방식이 어떨까 생각합니다.
예를들어...

custom.skin.html <- skin.html 을 사용자가 수정하였을 경우에 저장되는 파일 입니다.
custom.style.css <- style.css 를 사용자가 수정하였을 경우에 저장되는 파일 입니다.
cuntom.sidebar.xml <- 사용자가 사이드바의 위치 구성 등을 수정하였을 경우에 저장되는 파일 입니다. 이는 xml로 하지 않고 txt로 적당히 저장을 해도 될 듯 합니다.

이와같이 저장을 한다고 하구요...
사용자가 테더에서 스킨을 선택하는 순간,
저 화일들이 있으면, 그냥 그 화일을 오픈합니다.
저 화일들이 없으면, 기존의 스킨화일로부터 저 화일들을 복사한 뒤 오픈합니다.
블로그 홈페이지가 오픈되면, 기본적으로 저 화일들이 존재한다는 가정을 두고 이용합니다.

이렇게 하면, 속도문제와, 각 테마별 스킨화일 커스터마이징을 같이 할 수 있다고 보여집니다.
물론, 기존의 테마가 저 화일들을 가지고 있다면, 문제가 될 수 있습니다만, 우선 저런 이름을 가질일이 거의 없다고 보구요.
화일이름으로 custom.* 인 화일은 테더에서 기본적으로 customize를 위한 화일이므로, 임의로 스킨개발자가 만들지 말도록 하자 고 한다면, 앞으로의 확장에 여유가 생길 듯 합니다.

옙^^ 좋은 아이디어네요.

문제라면 다중사용자를 위해선 굉장히 복잡해집니다. 현재 변경된 파일은 customize/유저번호 디렉토리 아래로 들어가게 됩니다만, 위의 기능을 지원하려면 그 아래 하위 디렉토리들이 더 만들어져야 하겠네요. 그리고 스킨이 지워졌을 경우 모든 유저의 해당 변경 스킨도 지워줘야 합니다.

예를 들어, 천명이 쓰는 태터 블로그에 스킨이 15개 설치되어 있으면 (....)

그냥 지금 편집한 파일을 백업해서 사용자가 가지고 있을 수 있게 하는 것으로는 안될까요? 태터툴즈 데이터 백업처럼 현재 편집한 스킨의 설정과 백업을 사용자가 가질 수 있도록 지원하는게 나을 것 같다는 생각이 듭니다. 이 경우 스킨 배포 및 업로드나 다운로드가 자유로와지는 장점도 있겠네요. smile

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

7

답글: 스킨변경시 사이드바 초기화에 대해서...

inureyes 작성:

예를 들어, 천명이 쓰는 태터 블로그에 스킨이 15개 설치되어 있으면 (....)

그냥 지금 편집한 파일을 백업해서 사용자가 가지고 있을 수 있게 하는 것으로는 안될까요? 태터툴즈 데이터 백업처럼 현재 편집한 스킨의 설정과 백업을 사용자가 가질 수 있도록 지원하는게 나을 것 같다는 생각이 듭니다. 이 경우 스킨 배포 및 업로드나 다운로드가 자유로와지는 장점도 있겠네요. smile

customize/유저번호/skin.html
customize/유저번호/style.css
이렇게 되어있을 경우에 역시, 어드민이 스킨을 지울경우, 같은 문제가 생기지 않나요?
각 skin.html이 참조하고있는 image 등이 존재하지 않을테니 말이죠...

그렇기에...
customize/유저번호/스킨네임/skin.html
customize/유저번호/스킨네임/style.css
이렇게 진행한다고 해서 큰 문제가 되지 않을듯 합니다.

Yesterday is history, tomorrow is a mystery, and today is a gift; that's why we call it - present

8

답글: 스킨변경시 사이드바 초기화에 대해서...

htna 작성:
inureyes 작성:

예를 들어, 천명이 쓰는 태터 블로그에 스킨이 15개 설치되어 있으면 (....)

그냥 지금 편집한 파일을 백업해서 사용자가 가지고 있을 수 있게 하는 것으로는 안될까요? 태터툴즈 데이터 백업처럼 현재 편집한 스킨의 설정과 백업을 사용자가 가질 수 있도록 지원하는게 나을 것 같다는 생각이 듭니다. 이 경우 스킨 배포 및 업로드나 다운로드가 자유로와지는 장점도 있겠네요. smile

customize/유저번호/skin.html
customize/유저번호/style.css
이렇게 되어있을 경우에 역시, 어드민이 스킨을 지울경우, 같은 문제가 생기지 않나요?
각 skin.html이 참조하고있는 image 등이 존재하지 않을테니 말이죠...

그렇기에...
customize/유저번호/스킨네임/skin.html
customize/유저번호/스킨네임/style.css
이렇게 진행한다고 해서 큰 문제가 되지 않을듯 합니다.

그게, 이미지까지 카피를 합니다....

그렇기에 문제가 됩니다 ~ 용량의 로드부터 주욱 -

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

9

답글: 스킨변경시 사이드바 초기화에 대해서...

inureyes 작성:
htna 작성:
inureyes 작성:

예를 들어, 천명이 쓰는 태터 블로그에 스킨이 15개 설치되어 있으면 (....)

그냥 지금 편집한 파일을 백업해서 사용자가 가지고 있을 수 있게 하는 것으로는 안될까요? 태터툴즈 데이터 백업처럼 현재 편집한 스킨의 설정과 백업을 사용자가 가질 수 있도록 지원하는게 나을 것 같다는 생각이 듭니다. 이 경우 스킨 배포 및 업로드나 다운로드가 자유로와지는 장점도 있겠네요. smile

customize/유저번호/skin.html
customize/유저번호/style.css
이렇게 되어있을 경우에 역시, 어드민이 스킨을 지울경우, 같은 문제가 생기지 않나요?
각 skin.html이 참조하고있는 image 등이 존재하지 않을테니 말이죠...

그렇기에...
customize/유저번호/스킨네임/skin.html
customize/유저번호/스킨네임/style.css
이렇게 진행한다고 해서 큰 문제가 되지 않을듯 합니다.

그게, 이미지까지 카피를 합니다....

그렇기에 문제가 됩니다 ~ 용량의 로드부터 주욱 -

흠야.. 설마 이미지까지 카피할 줄이야...
그렇다면, 걱정하시는게, 모든 사용자의 스킨 커스터마이징 디렉토리에, 모든스킨이 들어있을 것을 걱정하시는 거군요...
흐미...
그렇다면, 스킨을 지운다고 해도, 각 사용자가 사용하고 있는 스킨은 지워지지 않겠군요...

직접 대면하고 얘기하는게 훨씬 쉽겠습니다만..
우선 봐야할게...
skin/스킨네임/skin.html 이 있을때
1) skin/스킨네임/custom/유저번호/skin.html
2) customize/유저번호/스킨네임/skin.html
두가지 방법을 고려해 봐야 겠군요...

1) 유저를지웠을때, 사용자정보가 같이 지워지지 않는다는 단점이...
2) 스킨을 지웠을때, 사용자는 여전히 각 스킨을 커스터마이징 했다면, 쓸 수 있다는 단점이...

1의경우에는,
할당량과 관련된 문제이기에 그리 추천하는 방법은 아니겠군요.

2의경우에는,
이미, 기존의 스킨을 지운다고 해도, 멀티유저가 그 스킨을 복사해서 사용하고 있기에 (자신의 쿼터가 허락하는 한..)
각 유저가, 자신이 사용할 스킨'들'을 복사해서(커스터마이징 해서) 사용한다해도, 큰 문제가 되지 않으리라 봅니다.
이때 필요한 기능이...
시스템에 깔려있는 스킨을 내가 사용하도록 설정할지 -> 시스템의 스킨을 내 커스텀 스킨 디렉토리로 복사할지..
내가 사용하도록 설정한 스킨을 삭제할지 -> 내 커스텀 스킨 디렉토리를 지울지..
의 기능을 하는 것을 추가해주면 되지 않을까 생각되는군요...

물론 각 사용자가 사용하는 디스크용량이 늘어날 수 있다는 단점을 가지고 있지만...
각 사용자에게 약 5개의 스킨을 커스터마이징해서 사용할 수 있게 한다고 하면,
멀티유저들이 더욱 환영하지 않을까 합니다.

Yesterday is history, tomorrow is a mystery, and today is a gift; that's why we call it - present