아직 로그인하지 않았습니다. 로그인 또는 회원 등록을 해 주시기 바랍니다.
TNF : Tatter Network Foundation forum » inureyes가 작성한 글
1. 크기를 조절해도 출력시 그 값을 무시합니다.
2. 에디터에서 그림을 선택해서 폭을 조절한 후 다시 그림을 선택하면 속성 창에 폭을 읽어오지 않습니다. 그리고 다시 포커스를 이동하면 저절로 원래 사이즈로 돌아갑니다.
3. 2번의 경우 html 모드로 변경해보면 위의 과정을 한 번 거칠 때 마다 height에 NaN이라고 입력됩니다. 두 번 그러면 NaNNan이, 세 번 그러면 NaNNaNNaN이 입력됩니다.
위의 경우 gif 파일로 테스트 해 본 결과입니다. 아마 jpg의 경우에도 같지 않을까 생각됩니다. 버전은 latest sandbox입니다.
방금 설정 화면에서
<p>
<a href="http://validator.w3.org/check?uri=referer"><img
src="http://www.w3.org/Icons/valid-xhtml10"
alt="Valid XHTML 1.0 Transitional" height="31" width="88" /></a>
</p>
요거 따놨습니다.. ㅋㅋ
흐흐흐 무서운 분들 천집니다. 곧 '의미론적'으로 코드가 맞는지도 검증 들어갈 듯^^
그리고 자신있게 1.1 strict로 가시죠 하하하 
어쨌든 기본적인 화면 XHTML 제어권은 우리가 갖고 있어야 한다고 봅니다(땅 싸움인가...). 아무래도 관리자 화면이니까요. 관리자 화면의 느낌을 일관적으로 주기 위해서는 어쩔 수 없다고 생각하고 있습니다. 그러나 이 부분을 꼭 피해가려는 소수 사용자를 극구 막고 싶지 않은 것이 저의 솔직한 마음입니다.
아마 조금 답답함을 느끼셨을 것 같은데, 뭐 약간의 답답함이 있는 것이 토론 아니겠어요(저도 솔직히 좀 답답했습니다). 그러나 서로 납득 못할 수준의 주장을 하고 있는 것도 아니니, 좀 더 넓게 봐야겠지요. 문제가 있거나 방침이 달라지면 언제든지 바꿀 수 있는 것이 소스니까요. 하하하!
플러그인 디렉토리 안에 setting.css등이 있을 경우는 그걸로 파싱하고, 없을 경우에는 관리자 화면 안에 든 디폴트 css로 파싱하는 방법을 사용하면 되겠군요.
이름 변경이 아니라, 태터 네트워크 재단의 구성요소로 태터앤프렌즈가 들어가는 형태가 되어야 한다고 봅니다
자세한 이야기는 지금 '괴물'보러 나왔으므로 새벽에...
덧) 네트워크는 무섭습니다 하하 언제나 접속 가능하고 막;
하는 김에 헝가리안 노테이션도 좀 정하고 갔으면... 저마다 소스 짜는 방식이 달라서... 적어도 전역에서 선언되는 변수나 함수 정도에만이라도 이름만 봐도 식별가능한 네이밍 방식이 있었으면 좋겠습니다.
변수나 함수 죽 보시면 라지 사이즈 캐릭터와 스몰사이즈 캐릭터는 언제 사용되는지 정해져 있죠
그리고 이름들을 보시면 기능이 앞으로, 주체가 뒤로 가도록 되어 있습니다.
나중에 공지를 해야겠네요^^
필요한 것 같아서 스크립트 넣고 돌려서 커밋해 놨습니다.
<? 찾아서 <?php로 모두 바꾸시오~ 해서 컴퓨터가 알아서 소스 수정해주면 참 좋겠네 (...........)
사실 그렇게 간단하게는 안됩니다. 이미 일부의 소스에 <?php가 있는 상황에서 그렇게 패치 돌리면 <?phpphp가 생긴다거나, 출력을 위한 <?xml 부분은 <?phpxml이 된다거나 하는 식으로 치환되어 버리죠. 그리고 <?= 등은 <?php echo 가 되어야 하는데 그냥 돌리면 <?php= 가 되어버리는 등등의 일이 일어납니다^^
대 -충 두가지 빼고 기능이 '일단은' 대부분 들어갔습니다.
스킨 부분이 고정된 이상 이제 몇군데 세세한 곳들을 마무리하고 내일이나 모레쯤 development alpha test 버전을 내놓는 것이 어떨까 합니다만.
다들 어떻게 생각하시는지 이야기를 꺼내 주시죠^^
관련해서 DAT 발표 이후에 변화된 사항 공지와 함께 1.1 스킨 컨테스트를 할 예정입니다. 상품으로 뭐가 좋을까요?
(상품은 TNC에서 협찬 받을겁니다 하하^^)
그거 한 번 엎었는데
어차피 옵티마이저에서 규칙 하나 집어넣어 엎을 수 있다는 papacha님의 말씀따라 놔 뒀습니다.
(사실 한 번 엎을 때도 정규식 두 줄로 치환해서 엎었으니 뭐...)
코딩할 땐... 편하잖아요 아하하하^^
혹 원하시면 한 번 더 치환 돌릴까요? <?xml부분이 한 곳 잘못 치환되는 부분만 고치면 나머지는 다 치환해서 처리됩니다
차기 버젼이 예상 배포될 그달의 꽃이름으로 하는것도 괜찮을듯 합니다.
흐흐 사실은 공모로 갈까 꽃말의 뜻을 찾아서 그 버전이 나타내는 목표와 같은 꽃을 찾아서 이름붙일까 고민하고 있었습니다
잘 다녀 오셨습니다^^
역시 돌아오고 나면 하늘 색 빼고는 우리나라가 제일 좋더라는...
맥퓨처 작성:확장에 대한 메뉴 선택 문제는 개인적인 의견으로는 메뉴 사용도의 여부도 중요하지만
어느 사용자를 목표점으로 메뉴를 개편할 것인가도 중요하리라고 봅니다.. 대략적으로라도
개편 후 사용할 대상자들을 우선 고려해 본 후 그 관점에서 접근하는 것도 의미가 있을 것 같네요..
아마도 블로그 초심자들이 주 목표점이 될 듯 싶군요.. 흠흠..
그런 점에서 이 논의는 개인적으로는 정말 좋은 의견이라고 한표 던집니다.. (그럼 본인의 의견은...? --; )보통 코덱 인스톨러에 보면 선택 사항이 여러개잖아요. "최소 인스톨", "전부 인스톨"은 물론이고, "DVD 플레이어 전용", "곰 플레이어 최적화 설치" 등등요. 이것처럼 관리자 메뉴 보이기/가리기도 여러 종류로 하는 거죠. 간단하게는 초급/중급/고급으로 할 수 있겠고... 이외에도 여러 종류가 나올 수 있겠지요.
차라리 절 죽이시죠;;;
라고 하면서 기본 / 확장 / 사용자 지정으로 코딩에 들어간...
차라리 술 깨지 말고 있을걸 싶습니다..
r729로 해 보시면 다 될겁니다^^
플러그인 목록에서 나오지 않는 이유가 있습니다 알림판 관리하기를 보시면 바로 아실듯^^
...
넷은 광대하다고 누가 그랬는데 별로 그런것 같지도 않은;
ㅎㅎ 구경중입니다 ~
설득해주세요 하하^^
말 그대로입니다. 무엇을 가릴까요?
관리자화면의 복잡도는 갈수록 늘어날거고, 더이상 '안되겠다' 싶을 때가 올겁니다. 아무리 배열을 잘 해도 뭔가 많으면 복잡해 보이는 것은 당연한 일입니다. 여기서 중요한 것이, 그렇다고 기능을 뺄 수는 없지 않겠습니까?
그래서 관리자 화면의 인터페이스를 '기본' 과 '확장' 으로 나누는 것이 어떨까 합니다. 뭐 어려운 것은 아니고, 환경설정에서 '기본'을 선택할 경우 보통 신경도 안쓰는 여러 요소들은 과감히 감추는 거죠. 설치시에 선택도 할 수 있게 하고요. (나중에 환경 설정에서 바꾸면 되니까요)
예를 들면, 에디터에서의 절대주소 지정이나 데이터베이스 최적화 (생길겁니다), xhtml 다듬기 등등, 그런 요소들은 '기본'을 선택할 경우 가려지게 되는거죠.
(구현하기로 맘 먹었습니다. 하하;) -그게 뭐가 필요 있냐?!- 하시는 분은 제 여자친구와 저희 어머니께 태클을 걸어 주세요)
그래서말인데, 기본 인터페이스에서는 현재의 인터페이스 중 어떤 것들이 가려져야 할까요?
끄고 켜는 쪽으로 해야겠군요.
덧) 술이 안깨서 두시간은 더 있다가 코드 만져야 할듯 합니다 -_- 저장소에 스파게티 요리집을 차릴 수는 없으니까요.
덧2) 그라피티에님 죄송합니다; 두시간이 여덟시간이 되어 버렸습니다 ㅠ_ㅠ
... 플러그인 환경설정 리스트에 나오는 순서를 사이드바에 표현되는 순서로 한다... 로 이해되는데... 맞나요?
... 팝업뜨고 AJAX로 끌어 순서정하면 그 순서가 저장되는 방식을 선택했다가 지금 그다지 보기가 별로라 (게다가 가로 사이드바 사용할 분도 있겠죠?) 고민 중입니다.
사이드바 플러그인 백개까지는 각오하죠 하하
사이드바 관련 플러그인만 10개군요. 플러그인 설정이 가능해지면 하나로 묶는 게 좋을 것 같습니다.
설정 화면에서 출력할 개체들을 선택하는 식으로 그라피티에님 말처럼 묶어버리는 것이 가능하기는 할겁니다.
하지만 이 경우 기본 플러그인이 아닌 특정한 플러그인을 사용할 때 기본 사이드바 플러그인들 '사이에' 위치를 지정해 줄 수가 없게 됩니다
태그 직접 적용은 ;;; 좋은 생각이 아닌 것 같습니다.
'사용자가 그것을 올바른 형식대로 쓰리라는 법이 없다' 는 진리를 가슴깊이... 새겨봐야 합니다. (위지윅 에디터의 모토죠)
차라리 lightweight wygiwyg editor를 하나 달아 버리는 게 나을 수도 있습니다
덧) 차라리 BBCode를 자체지원하는 방법도 있을 수 있겠군요. 뭐 그냥 아이디업니다.
div를 포함한 xhtml로의 변경과 플러그인별 css 적용은 그라피티에님께서 해 주실겁니다 하하 
(도망중)
1.0.6.1 과 변화된 /blog/owner/setting/plugin/index.php 의 diff를 보내 주시면 제가 sandbox로 인간패치-_- 하겠습니다^^
graphittie 작성:inureyes 작성:카테고리별 body id는 현재 지원이 되지 않습니다. 똑같이 category로만 나오죠
이유는, id명에 한글이나 특수문자가 들어갈 수 없는데 대부분의 국내 블로그의 경우 한글명으로 카테고리를 정하기 때문입니다
그냥 id 입력부분에 정규식으로 유효성을 판단해 주면 안 되나요?
카테고리 생성화면에서 카테고리 별로 적용될 ID를 직접 입력하는 방식으로 이미 구현이 되어 있던데요;
제가 지금 그렇게 쓰고 있습니다.
좀된 r6xx 버전인데 버전업 되면서 사라진건지도 모르겠습니다만..
(어 근데 rxxx 버전확인 방법은 따로 없나요?)
맞습니다 카테고리별로 body id를 설정할 수 있고, 설정한 경우에는 카테고리 선택시 그 body id가 나오게 됩니다. (설정하지 않으면 categody죠)
처음에는 태그나 검색어에 따른 body id도 그에 맞게 주려고 했지만, 카테고리만큼 고정되어 있지 않고 효용성이 떨어진다고 판단하여 그 경우들은 그냥 묶어버렸습니다^^ 그리고 주제가 다른 글들을 한 블로그에서 운영하는 경우, 완전히 다른 블로그처럼 보이게 하는 방법의 시작점으로 넣은 것이기도 합니다.
현재는 카테고리에 body id를 줄 경우 유효성 검사를 하지 않지만, 유효성 검사 루틴을 집어넣을 예정입니다 그게 css의 id로의 조건에 맞추려니 생각보다 쉽지 않더군요.
아이고, 아무래도 텍스트만으론 내용 전달이 잘 안되는것 같네요.
이미지를 첨부합니다;http://www.pink-hman.com/pink/qwerqwer.jpg
카테고리1을 만들고 body id를 이용해 그곳만 다른 CSS 효과를 주었습니다.
카테고리1 리스트 첫화면에서는 적용이 잘 됩니다.하지만 동일 카테고리의 동일한 내용의 포스트라도 그곳에서 리스트를 클릭하냐 아님 페이징을 클릭하냐에 따라서 각기 다른 body id를 불러옵니다.
그래서 첨부 이미지-_-와 같은 현상이 발생합니다.리스트에는 고유 url로 링크가 되어있고 페이징에는 /카테고리1?page=2 처럼 링크가 되어있어서 벌어지는 일입니다.
전 고유 url로 들어가던 페이지 넘버로 들어가던 body id는 page가 아니라 카테고리1로 불러와야 하는것 아닐까 하는거죠.이게 안된다면 최소한 리스트 페이지에서의 포스트 링크들을 /카테고리1?page=no. 로 통일을 시켜야 할것 같습니다.
카테고리별 body id는 현재 지원이 되지 않습니다. 똑같이 category로만 나오죠
이유는, id명에 한글이나 특수문자가 들어갈 수 없는데 대부분의 국내 블로그의 경우 한글명으로 카테고리를 정하기 때문입니다
문제 파악했습니다 바꿔 놓겠습니다.^^
TNF : Tatter Network Foundation forum » inureyes가 작성한 글
니들웍스 