Comment Macro/토론

FrontPage|FindPage|TitleIndex|RecentChanges| UserPreferences U P RSS

FrontPageEfficientMarketHypothesis노스모크사행시IllusionsDBDic CommentMacro/토론

CommentMacro 기능 개선 및 문제점 해결을 위해 마련된 토론 페이지.

Comment매크로를 활용하면 위키의 접근성을 높일 수 있게됩니다. 어떤 식으로 해결해야 할까요?

Comment매크로를 모든 페이지에 붙게하는 설정을 없애는게 나을까요? 아니면 BrightsKorea처럼 모든 페이지에 Comment매크로를 붙게 하고 위의 두 문제를 해결하는 방향으로 해야할까요?
--무신

지금대로, 맑은이는 "NoComment를 기본으로 하고, Comment를 선택적으로 추가하는 방법" 쪽으로 기웁니다. 내용을 중심에 두는 기본 양식입니다. 특별히 접근성을 높여야 하는 페이지. 예를 들면, 노스모크쿵쿵따, 나는모른다, 집중을 요하는 토론이 진행되고 있는 뜨거운페이지들, 등과 같은 페이지에서라면 접근성을 높이기 위해 Comment를 선택적으로 추가하게 하면 두루두루 좋지 않을까, 생각합니다. --맑은

아마도 CommentMacro를 가장 많이 쓰게되는 곳은 위키홈페이지가 아닐까 하군요. 위키홈페이지 만드는 Template에 Comment매크로를 넣어둬도 충분히 써먹을 수 있을듯. --무신
위키홈페이지라면 Comment가 참 잘 어울리는 곳이로군요. 훌륭한 생각입니다. (팍팍떠밀자!낭떨어지밑으로!) --맑은

분류딱지와 SeeAlso를 맨 위로 옮겨적으면 어떨까요. 다른분 홈페이지에서 그렇게 한 걸 보고 제 홈페이지도 그렇게 바꾼적이 있습니다. 나쁘지 않던데요. --Astro

네 저도 그렇게 생각합니다. FreeFeelZone한국브라이트넷이 그런 식으로 하고 있는듯, 다만, 위키키워드토론에도 얘기가 나왔었지만 현 분류시스템은 뒤떨어지고 유지관리도 쉽지 않습니다. 장기적으로 키워드 시스템으로 가야하지 않을까 합니다. TaggingSystem을 참고해주세요 --무신

하단에 분류딱지가 있어서 Comment를 붙이기도 힘들고, 처음 오는 사람들이 글을 쓸 때 자신의 글을 어디에 놓아야 할지 쉽게 갈피를 잡을 수도 없고 하는 등의 불편함이 있긴 합니다.

하지만 맑은이의 바람은 Astro님, 무신님의 의견과는 다릅니다. 상단에 분류딱지가 들어가는 경우는 한 페이지의 길이가 너무 길어서 페이지를 잘르고자 할 때, 이 페이지가 어느 페이지에서 찢어져 나온 것이라는, 길안내를 붙이는 정도에 그치길 바라지요. 상단이 너무 무거워 집니다. 지금도 상단이 결코 가벼운 편은 아니잖아요. 그래서 print라는 action까지 따로 제공하고 있기도 하고요.

그렇다 하여 "print 기능이 따로 있기 때문에, 머리 쪽이 얼마든지 무거워져도 상관이 없다고 보시는지요?" 지금까지의 노스모크 관례가 본문을 가장 잘 보여주고 있다고 생각합니다. SeeAlso 같은 분류 딱지, 참고 자료 등의 인덱스가 문서의 제일 앞쪽에 오도록 해야겠다는 발상이 어떻게 가능했는지 잘 모르겠어요. 맑은이가 너무 늙었나 봐요. 아마도 모르는 게 너무 많아서 그렇겠지요? 아무튼, 위쪽에 붙이자는 제안에는 반대입니다. "손가락의 편의성, 본문의 전달력" 등을 모두 만족할 수 있는 방법을 좀 더 찾아 보았으면 해요.

--맑은

위에서도 밝혔지만, 장기적인 관점에서는 키워드시스템을 도입하여 현 분류체제를 버리는 것이겠지만 여기서는 이것은 논외가 되겠고, 현 시점에서 Comment매크로를 기본으로 하는것을 바로 적용하기엔 역시 무리인 것 같네요. --무신

두번째 코멘트창


"<이전 글의 위치와 [[comment]]표시가 부착된 위치 사이에 CommentMacro를 통해 쓴 코멘트가 저장되도록>" CommentMacro를 수정할 수는 없는지요?" CommentMacro가 사용된 곳의 위치 정보를 알 수만 있다면 프로그램을 다듬어 볼만한 가치가 있지 않을까요? 일단 그렇게 하면 지금의 상태에서도 "nocomment를 기본으로, comment를 선택적으로" 사용하는 것이 가능해 집니다. 또한 한 페이지 내에서도 여럿의 MacroComent를 사용할 수도 있게 되겠지요.

에 또 하나 더 추가한다면 MacroComment에 들여쓰기 기능까지 적용해 준다면 뜨거운 페이지에서의 "스레드 글뭉치" 부위에 슬쩍 밀어 넣으면 아주아주 훌륭하게 편리하게 쓸 수 있게 됩니다. 가지치기는 이제 그만.

아무튼, 이 페이지에서 사례를 보이도록 하고, 동의를 얻는다면 완성된 결과도 이 페이지에서 볼 수 있길 바라옵고 또 바라옵니다. (물론, 지금은 요망사항) 이 페이지의 제일 아래쪽에 있는[[Navigation(매크로사용법)]] 위에 CommentMacro를 위치시켰습니다. 그러면 바로 그 위치에 글쓰기창이 납니다. 마찬가지로 "특정 위치에서 쓰여진 글이므로, 저장된 텍스트 내에서도 그 위치(CommentMacro 표시 바로 앞 쪽)에 저장되는 게 바람직"하다고 생각됩니다. 이 제안이 받아 들여진다면 '''" <분류꼬리표와 코멘트 사이의 자리 다툼>은 자연스레 피할 수 있게 됩니다. 뿐만이 아닙니다.

"Comment를 어떤 곳에서든 위상에 맞게 선택적으로 사용할 수 있게만 된다면" 아주아주 유연하게 응용의 범위도 넓힐 수 있습니다. 현재 CommentMacro를 기본으로 쓰도록 설정 돼 있는데, CommentMacro가 어울리는 페이지보다 어울리지 않는 페이지가 더 많을 것이라 짐작으로 가늠이 되는데 이유는 토론 페이지와 위키홈페이지를 제외한 나머지 모든 페이지는 일단은 CommentMacro가 어울리지 않는다고 생각됩니다. 다른 분들도 한 번 둘러 보면서 생각을 보태 주셔요.

어차피 지금과 같이 기본 설정된 CommentMacro의 쓰임새는 한정되어 있을 따름이라 여겨집니다. 페이지의 끝에 추가하는 게 다 잖아요. 그 외으 모든 것은 EditText기능을 써야 합니다. 이런 경우 처음 오는 이들이 받는 느낌은 '편하다'는 것 뿐만이 아닙니다. 일반적인 홈페이지의 방명록에 글을 쓸 때와 마찬가지로, 한 번 쓰고 나면 '더 이상 건드릴 수가 없는' 상태인 것으로 얼마든지 착각할 수 있습니다.

이번의 노스모크 업그레이딩에서 "자동성고유연성의 원리를 자꾸만 벗어나려 한다"는 냄새를 맡습니다. 판단을 내릴 수야 물론 없습니다. 다만, 그런 "깸새를 느낀다"는 것입니다. 의도했든 의도하지 않았든 말입니다. 의도하지 않았다 하여 그 길로 가는 커다란 흐름을 막을 수야 없겠지요. 어디까지나 흐름이니까요. 하지만, 어쩌면, "노스모크노스모크계정관리자 없이도 굴러가야 하는 날이 언젠가는 오지 않을까"도 생각해 봅니다.

프로그램 의존성이 강한 시스템에서는 도움을 줄 수 있는 프로그래머가 더 이상 없을 때 그 시스템에 문제가 생기면 그 순간 멈춰 버릴 수 밖에 없겠지요. 자동성이 높으면 그만큼 문제가 생길 가능성도 클테니까요. 하지만 프로그래머가 없다하여 시스템이 멈추어야 할까요? 프로그래머가 없다해도 시스템이 굴러갈 수 있다면 좋지 않을까요? 그래야, 무료로 봉사하고 있는 프로그래머 자신도 쉬고 싶을 때 발 쭉 뻗고 쉴 수 있지 않겠어요? 이상에서의 <요지>를 한 줄로 적어 봅니다.

"자동성고유연성을 최대한 유지한 상태에서 기능의 확장을 고려하고, 확장된 기능은 선택적으로 사용토록 하자!"


고자동고유연 아닌가요 ㅎㅎ 이미 제안하신 비슷한 방법을 사용하실 수 있습니다. ##Comment가 있으면 ##Comment 앞쪽으로 문두쓰기 방식이 됩니다. ##Comment가 없으면 [[Comment]]가 그 페이지에 있는지 검사를 해서 그것의 앞쪽으로 글이 쓰여지게 됩니다. 이저 저도 아니면 페이지의 맨 끝에 남게 되죠. 여기까지가 예전 버전의 CommentMacro가 작동하던 방식입니다. 그런데, 최근 다중 Comment를 사용할 일이 생겨서 이 쓰임새가 조금 바뀌었고 예전방식대로 작동하지 않는 그런 문제점이 또 생겼습니다. 아무튼 제안하신 방식이 이미 구현되었었다는 것이고, 이걸 조금 더 고치면 multiple comment macro를 쓰실 수 있도록 조만간 고칠것입니다. ^^ --무신

그러나, 맑은 제안에서 구체적인 부분의 핵심사항은 Single이 되든, Mutiple이 되든 간에 (결론은 멀티 지향이 되겠지만) 요소기술로 먼저 확인되어야 할 것은 "[[comment]]가 삽입된 곳의 위치 정보를 제대로 파악하여 그 바로 앞에 저장 해 주는가 하는 것입니다. 이것이 확인되어야 Multiple Comment Macro 로 나아가든 말든 하지 않을까 싶거든요.

그러므로, 현재 상태에서는 Single만이라도 어떤 위치에서라도 놓여진 위치에서 쓰고 놓여진 위치에 저장되도록 성공 시켜서, 기본 설정을 nocomment로 돌려 놓은 뒤에" 비로소 Multiple Comment Macro 구현으로 나아가는 게 좋지 않을까 싶습니다.

그래야만, 다른 노스모키안도 개발이 진행중인 것과 사용이 가능한 것을 구분하여 "아직도 뭔가 진행 중인가"라는 의문을 떨치고 주어진 범위에서나마 믿고 사용할 수 있으리라 봅니다.

아무튼, 맑은이의 소망이 이루질 날이 눈 앞에 다가 오고 있는 중이라 이 거지요? (아이조아) 참, 그런데, '자동고유연(?)'도 위험수위가 어지간히 높은 건데, 지금의 방향이 그렇게 되어 가나요? (큰일이네) 그러나, "선택적으로 사용할 수 있다"는 건 고자동의 위험을 극복할 수 있는 하나의 안전장치가 되어 주리라 믿어 마지 않습니다. (이제그만)(뽀글뽀글뽀글뽀글뽀글) --맑은

ㅎ 고자동고유연은 또 다른 저자동고유연으로 간다고 하는군요 ^^ 어쨌거나, 말씀하신 내용을 최대한 간단히 구현할 것입니다. 위치만 알아내면 Single이던 multiple이던 구현비용이 매우 간단해집니다. 그러나 그 위치를 정확히 알아내는 것이 간단하지 않습니다. 위키텍스트는 언제라도 변할 수 있으니(Comment날리기 전에 누군가가 그 페이지를 변형했다던가..) 정확히 그 위치를 판별해서 글을 쓰게하는 것은 어렵고(고자동) 이게 구현하기 쉽지 않아서, 사용자가 그 위치를 사용자가 지정하게 하는거죠(저자동) [[Comment(blah)]]이라는 식으로요(multi일 경우) Single인 경우는 그냥 [[Comment]]를 쓰면 그 페이지에 유일하게 그거 하나뿐이라고 가정하고 글을 올리게 하면 되죠. 너무 간단한가요? 아무튼 적용되어서 cvs에 올라갔습니다. 남은것은 PuzzletChung님이 업뎃을 하시면 되는겁니다. ^^ --무신

맑은이는 어차피 "위치 정보를 사용하는 일이 쉬운지 어려운지"까지는 모릅니다. 다만, 위치 정보를 알아내는 게 중요하다는 것만 얘기할 수 있을 따름이지요. 이런 새로운 시도를 함에 있어 Single을 먼저 선 보여주셨으면 합니다. 이건 Multi가 쉬운지 어려운지와는 전혀 상관없는 얘기랍니다. Multi가 만들어졌다고 하더라도, 막바로 Multi를 내 놓지 말고, Multi기능이 막아진 Single을 먼저 맛보변서 복잡한 다른 문제에 맞닥드리지 않도록 했으면 해요. (이거, 주유소습격사건의 '한 놈만 패!' 전법이지라예)

"어디에서나, CommentMacro가 놓여진 바로 그 곳에서 작은 글쓰기창이 보여지고, 글쓰기창이 보여지는 바로 그 곳에서 글을 쓰고, 글을 쓴 바로 그 곳에 글이 저장되도록 하는 CommentMacro"를 여러 노스모키안들이 경험해가면서 발전적 적용의 제안이 추가적으로 나오면 그 때 비로소 Single제한을 풀어서 Multi기능을 사용토록 하는 게 더 낫다고 생각합니다. 물론 그 제한을 푸는 것은 PuzzletChung님이 해 주시면 될 것이고요.

노스모키안의 행동에 제약을 줄만한 어떤 '심각하고 부적절한 변화' ;) 에 대한 고려도 이제는 심각하게 해야할 때가 되었다고 봅니다. 그래서 이런 부탁이 더욱 절실해지는 것입니다. 그래 주실 거죠? :D

(여까지)(뽀글뽀글뽀글)--맑은

무신섹션 편집기(그것 참 이름이라도 좀 알았으면) 그 거 위치를 인식 안하나요? 사용 결과로 보아서는 위치 인식 안하고는 그렇게 나오기가 힘들 것 같던데. 아, 그게 아니면, 첫번째 섹션, 두번째 섹션, 뭐 이런 식으로 되었나? 음, 몰갔다(당연하지!), 거기에 답이 있는 줄 알고 들어와 봤는데, 아무래도...:( ( 내 몫이 아닌 게 벼)(뽀글뽀글뽀글) --맑은

섹션편집은 위치를 보다 쉽게 판별할 수 있죠. 우선 제목줄이 들어가니까, 그 제목줄이 서로 겹치는 것이 없다면 제목줄은 일종의 지문으로 작용합니다. 물론 이 방법보다 훨씬 단순하게 구현했고요. Comment는 Macro이기 때문에 글 중간에 오더라도 입력 폼은 나옵니다. 글 중간에 들어가면 오히려 위치를 판별하기 더 쉽겠지만, 속성상 Comment매크로는 한줄로 쓰는것이 가장 자연스럽게 되는 것이고, 한줄로만 쓰려니 이것을 여러번 썼을 경우 어느 입력 폼 근처에 글이 올라가는지를 잘 판별해야 하는 문제가 있는 것이죠. 어쨌건, Single로만 넣은 경우는 지금도 문제가 없다고 알고있습니다. ^^ --무신

또 한가지 더 생각난 게 있는데, 저장된 페이지를 읽고 해석해서(이라고해야하는지는잘모르겠고,암튼,뜻만전달) 보여주고 필요한 경우 다른 일꾼들에게 일을 넘겨주는 일을 하는 어떤 놈이 있다고 치고, 그 놈이 [[Comment]]를 만나면 이 놈의 현재 위치를 넘겨 받을 수 있는 다른 인터페이스로 바꿔치기 해 줄 수는 없는지요? 그게 된다면 사용자는 아무런 고민없이 [[Comment]]라고 쓰기만 하면 되는 거고, 그게 된다면 [[Comment(어쩌구)]]를 쓸 필요는 없게 되잖아요. 그러나,그런데,그래도. --맑은

"어쨌건, Single로만 넣은 경우는 지금도 문제가 없다고 알고있습니다."라고 하셨지만, 맑은이의 Single테스트 결과를 보시는 바 대로, 쓴 곳이 아니라 완전히 다른 위치에 저장되었습니다. 맑은이가 본 것은 바로 이것이었거든요. 그래서 안 되는구나 하고선 "글을 쓴 위치에 저장되도록 만들어 달라"고 제안을 하게 된 것이었답니다. 이렇게 안 되는데 된다고 하니, 어케 받아 들여야 하는 건지요? 아마도 서로 생각하는 게 다른 것인지요? --맑은

그건, 위에서 예로 [[Comment]]를 썼기 때문에 그 위치에 글이 들어갔던거죠. 프로그램이 아주 똑똑하게 만들어진건 아니거든요 ^^;; --무신
히히, 그럼 고쳐주는거지요? :D 그렇게 찰떡같이 믿고 이제 그만 퇴청하겠사옵니다. (뽀글뽀글뽀글) --맑은

그다지 상관없는 이야기지만, 지금 여기서 얘기되고 있는 것은, 텍스트의 위치를 나타내는 방법이 필요하고, 그것이 해결되면 [[Comment]] 매크로가 아예 필요하지 않게됩니다. [http]Purple number라고 하는 것이 텍스트의 위치에 고유의 번호를 부여하는 방법으로 알고있습니다. 코멘트는 텍스트를 바꾸는게 아니라 그것의 근처에 새로운 텍스트를 첨가하는 것이므로, 이걸 잘 지원하면 CommentMacro없이도 Comment를 처리할 수 있게 되겠죠. --무신

Single 코멘트창 앞


Username:


Single 코멘트창 뒤

CommentMacro를 선택적으로 충돌없이 사용하기 위한 방법으로 곰곰히 생각해 본 것 (검증바람)

  1. 각주기능 : 해당문서 전체에 미치는 SeeAlso는 각주 기능을 사용. 이 각주기능도 출력할 위치를 지정해 줄 수 있도록 만들기. 지금의 CommentMacro가 그러하듯이.
    FootNoteMacro를 참고하세요. 위치 지정은 이미 지원하고 있는 것 같습니다.

    책이라면, 여러 페이지로 짜여져 있기 때문에 각주와 Reference를 따로 다루고 있습니다. 위키에서는 그것들을 하나로 관리할 수 있지 않을까요? 각주라기 보다는 Reference라는 타이틀로서 말이죠.
    각주를 많이 쓰게 될 상황이 아닌 이상, FootNoteMacro로도 충분히/비슷하게 원하시는 것을 할 수 있을 듯 합니다.

  2. SeeAlso : 특정부분에 참고자료로 제시하고자 할 때는 SeeAlso를 기존대로 사용
    이건 왜 언급하신거죠? 분류태그와 마찬가지로 페이지의 맨 끝에 있기 때문에 언급하신 것인가요?
    맞슈미다. --맑은
  3. CommentMacro : 선택적으로 사용

이렇게 하면 안될까요? 물론 맑은이가 검증할 수 있는 수준은 못되지만 이렇게 하면 '분류'를 문서의 머리에 넣지 않아도 되고 문서 전체에 미치는 'SeeAlso'역시도 충돌을 회피는 한다고 보옵니다. 그러나, ... 그 다음 문제는 ... ?

하룻밤을 보낸 뒤 생각이 좀 바뀌었습니다. 그래서 수정안을 올리게 되었습니다.

분류문제를 워드시스템을 통해 해소하게 된다면 이런 문제점이 있지 않나 싶습니다. 지금은 한 페이지 내에 구조(관계)를 만들어 줄 수 있는 모든 정보가 저장되어 있는 것으로 보입니다. 그러나 분류태그를 페이지에서 떼어 내 버린다면, 페이지들 간의 관계를 만들어 줄 수 있는 정보가 저장되지 않게 되므로, 이런저런 이유로 워드시스템을 사용할 수 없는 불행한 상황에 처하게 되면 페이지들 간의 구조적 연결선들이 모두 끊어져 관계를 전혀 알 수가 없고 모든 페이지는 고아 페이지가 되어 버리는 문제점이 있습니다. 음, 혹시라도, 그런 상황에 처하게 된다면, 그냥 대대적 페이지인양작업을 하면 되는 건가? (에고 정말 헷갈린다. 뱅글뱅글)

그래서, 결론은, 처음 제기했던 "1. 키워드시스템구현 : 일반키워드 + 분류용" 이 의견을 취소했습니다. "분류태그의 위치를 어디로 잡든 간에, 분류태그는 지금처럼 페이지 내에 있는 것이 바람직"하지 않을까요? 그래도, 워드시스템 개발 자체에는 동의합니다. 오해 없으시죠?

(북치고장고치고혼자서도너무잘노는) --맑은

  1. 분류태그를 때더라도 페이지의 키워드가 그 페이지 내에 함께 저장되므로 문제 없습니다.
  2. 현 분류태그는 페이지간의 관계를 연결하는데 큰 도움을 주지 못하고 있습니다. 분류 대신에 키워드로 페이지간의 동적인 연결 뷰를 보여줄 수 있습니다. 따라서, 그 이후에 쓰신 우려는 없다고 생각합니다.
  3. 고아 페이지의 개념도 새로이 정의되어야 할것입니다. 예전에는 링크가 전혀 없는 페이지 혹은 역링크가 전혀 없는 페이지가 고아페이지가 될 가능성이 높았지만, 키워드를 쓰게 되면, 페이지간의 연결이 없더라도 키워드만 적절히 잘 할당되어 있다면 고아페이지가 아닐 수 있습니다.
당분간 분류시스템과 키워드시스템이 공존되겠지요. 써보면서 위키에 알맞도록 맞춰나가야 할것입니다.

참고로, WikiPedia는 고전적은 분류방식을 그대로 고수하면서 분류분류를 매크로를 이용해서 분류합니다. 예를 들어 [[Category(생물학)]]과 같은 식입니다. 공짜기능을 활용하는 수준에서의 분류분류는 WikiPedia처럼 큰 위키에서는 쓰기 어렵기 땜에 그렇게 한 것이겠지요 --무신

동적인 연결, 풍부한 연결 모두 좋은 의견이라고 생각합니다. 고아페이지에 인식의 전환에 관한 이야기도 그렇고요. 그것들에 더해서 맑은이는 분류가 독자적으로 존재하는 것은 의미가 크다고 봅니다. 너무 많은 연결선들은 찾는 사람에게 아무길도 보이지 않게 하는 단점이 있다고 생각합니다. 그래서 아직은 분류가 의미가 있다고 생각합니다.

분류를 분류답게 쓰이도록 하기 위해 특별한 표기식을 쓸 수는 없는 건지요? "이 곳에는 분류태그만 있다"라고 범위를 주는 거죠. 가령,,,


얼씨구
절씨구
----
{ 분류 : [MoniWiki] ![매뉴얼] }


이렇게. 안되나요? 물론 {}는 그걸 쓰라는 것이 아니라 예를 드는 중에 깔끔하게 보이는 듯하여 썼지요. 분류는 링크가 없으므로 그냥 장식이구나 하는 거고, 링크된 페이지들을 분류라고 보는 겁니다. (아이고, 점점 혀가 꼬이는구나)

맑은이가 별 쇼를 다 합니다, 그죠? :D 다음에는 불 쇼를 보여 드릴까 '생각중'입니다. ;) 찡그리지 말고, 웃어요 웃어! --맑은

CommentMacro 건의/제안


  • 이전 글의 위치와 [[comment]]표시가 부착된 위치 사이에 CommentMacro를 통해 쓴 코멘트가 바로 그 위치에 저장되도록.
    이미 그렇게 구현/설계되어 있습니다.

  • 들여쓰기 기능
    이 제안은 당장은 구현하는 것보다는 여러가지 조합적인 아이디어를 낼 수 있기 때문에 중요하긴 하지만, 첫번째 제안사항이 완성되면 그 때 제안할께요. --맑은

  • Multiple Comment macro
    cvs에 간단히 구현됨

    테스트 해보고 싶으시면 MoniWikiDev:CommentTest에서 확인하세요. 연습도 많이 하시구요. ^^ --무신

  • 프린트 페이지에서는 CommentMacro창이 나오지 않도록 해야. --맑은
    아래 폼이 print할 때 나타나지 않게 하려면 기본 print.css를 고쳐야 하겠지요. (반영함) --무신 (글상자토론에서 옮겨옴)

  • 코멘트 글쓰기 창 아래에 있는 단추를 비롯한 모든 것들을 옆으로. (TheBrights Net Korea 참고)
    그러면 코멘트 창이 분류태그나 SeeAlso 목록 위에 있어도 크게 미워 보이지 않을 것 같습니다. 잉, 좀 해 줘 봐요! (씩씩)--맑은

  • 코멘트를 달기 전에(그러니까 그냥 페이지를 봤을 때) 어디에 달리는건지 볼 수 있음 좋겠네요. 아니면 코멘트 폼에 전후 몇줄씩을 같이 보여주면 어떨까하는 생각을 해봅니다. --장모


CommentMacro 버그

  • [[Comment]][[comment]의 처리결과가 다르게 나옵니다. 차이점은 대문자C와 소문자c입니다. 수정하시면서 과거의 것을 살려두셨던 모양입니다. 매크로는 대소문자 구분 안하는 줄 알았는데, 깜짝 놀랐네요. 옛날버전으로 엔진이 되돌아가 버린 줄 알고 말에요. 아무튼 고쳐주세요. 앞의 대문자 쪽이 정상적으로 되고 있습니다. 창을 놓는 위치에서 추가 되도록 다듬어진 것 같습니다. 이것까지 골라 쓰라고 하시지는 않으시겠죠? :-( 테스트 내역은 맑은이 페이지에 있습니다. --맑은 2007.02.26(월)


"; if (isset($options[timer])) print $menu.$banner."
".$options[timer]->Write()."
"; else print $menu.$banner."
".$timer; ?> # # ?>