Stutter 1차 완성
아직 지뢰밭 상태일 것 같다는 느낌이 좀 들긴 하지만... 대충 쓰는데는 무리가 없어진지라 1차적인 완성을 해놓고, 현재 기존 컨텐츠들을 옮기는 중이다.
기본적인 프로그램의 목적은
- 위키언어를 통해서 프리젠테이션 양식과는 별도의 데이터를 구성한다.
- HTML, Flash, mobile HTML 등 어떤 플랫폼을으로든 파서를 구현한다. (그래서 다른 위키 언어들에 비해서 심각하다 싶을 정도로 단순하다는게 문제...;;;)
- 데이터는 하나의 폴더에 sqlite db 파일 하나와 첨부파일이 되는 폴더들로 구성되고, 이 데이터는 웹에 올린 다음 PHP 나 JSP 등의 서버 모듈과의 결합을 통해 보여질 수 있도록 한다.
- ===plugin=== 문법을 통해 javascript, actionscript 등으로 위키 언어를 확장시킬 수 있다.
뭐 대충... 위의 것들을 합치면 지금까지 내가 경험했던 "아 썅! 이놈의 글들은 써놓으면 플래시에 올리기도 애매하고, 홈페이지 리뉴얼 할때마다 스타일 수정하느라고 졸라 피곤해!" 가 될 것 같다... ㅡ ㄴ ㅡ;;; 애초에 홈페이지 만들다가 글관리가 왜이리 빡센가... 라는 짜증으로 부터 시작한 글관리 프로그램 이니깐... 뭐...
어쨌든 글의 원론적인 데이터를 아주 단순한 위키 문법을 써서 관리하고, 위키 언어의 불편함을 극복시키기 위해서 전용 프로그램을 만들었고, 데이터는 sqlite + 첨부파일이라는 단순한 형태로 존재하기 때문에 뭘로든 결합시켜가지고 view 를 다양하게 만들 수 있다... 는게 이 프로그램의 목적...
원노트나 에버노트와 같은 프로그램들이나 블로그툴 같이 졸라 좋은 프로그램들 보다 쬐끔 좋은 점은 프리젠테이션 서식에 독립적이라는 점과 데이터가 단순해서 간단한 프로그래밍으로도 다양한 활용을 할 수 있다는게 아닐까 싶다. (그거 하나 바라보고 몇 달동안 이 개고생을 해서 만든거니... 원 글 관리하기가 이렇게 힘들어서야... ㅜ ㄴ ㅜ)
뭐 아무도 참여할 것 같진 않지만... 어쨌든 소스가 공개되어 있는 프로그램...
http://dev.naver.com/scm/viewvc.php/trunk/?root=ssen
최하단의 Button 부터 Scroll, ScrollPane, Selector 등 모든 기능들을 죄다 개인적으로 만든 framework 를 사용해서 만들었더만 시간이 무진장 오래 걸려버린 케이스 이긴 하지만, 만들면서 왠만한 컨트롤의 작동 구조를 파악했다는 자산은 남았다.
위키언어를 새로 만들어서 진행하고 있고, 아직 파서가 Javascript 용 밖엔 없는데, 컨텐츠들에 대한 이주가 다 끝나면 Flash 와 RSS, PHP 용으로도 새로 만들 생각이다.
막상 다 만들고 나니 내가 왜 이 개고생을 했는지 의문이 드는 프로그램이기도 한데... 어쨌든 만들긴 만들었다는...
callback 구조 만들기
만들고 있는 framework 를 callback 구조로 변경중이다. 아무래도 event 보다는 불편한 편이지만, 테스트 돌려보니 callback 구조랑 event 구조랑 속도차이가 다섯배 정도 나더라... ㅡ ㄴ ㅡ;;; 이건 뭥미? 하면서 구조를 바꾸는 중이다.
대충 callback 구조로 변경을 하면서 multicallback 구조도 만드는 중인데, 그간 일방적인 수신구조를 가지던 event 구조에 대비해서 독점권 구조를 넣고 있다. 대단한 건 아니고, 그간 stage mousemove 와 같은 이벤트를 일방적인 수신을 함으로서 A 와 B 등의 다중 인스턴스들이 모두 이벤트를 강제로 받음으로서 발생하는 에러를 방지해보려는 것이 첫번째 목적이다.
var callbacks:Callbacks = new Callbacks();
var node1:SLLNode = callbacks.append(callback1);
var node2:SLLNode = callbacks.append(callback2);
var node3:SLLNode = callbacks.append(callback3);
callbacks.dispatch(); // 모든 callback 에 이벤트 전달
callbacks.monopoly(node1);
callbacks.dispatch(); // 독점권이 설정된 callback1 에만 이벤트 전달
callbacks.open();
callbacks.dispatch(); // 모든 callback 에 이벤트 전달
위와 같은 구조로 만들었다. 이로 인해 독점 이벤트가 발생해야 하는 일부 기능들에 대해서 비활성 상태에서 강제로 이벤트가 날아듦으로 인해 발생하던 에러를 원론적인 단계에서 거부할 수 있게 되었다.
문득 만들면서 이게 왠 삽질인가 싶은 느낌이 들고, 혹은 개발하기 졸라 불편하겠는데 싶기도 하지만... 뭐 불편하다 싶으면 다시 뒤집어 엎으면 되는거고... 인생 뭐 있나...
TLF 를 향한 여정의 끝
TLF 최초의 프리뷰 버전부터 사용을 했었으니 TLF 만 거의 1년을 팠던 것 같습니다.
이놈의 TLF 때문에 adobe open source 사이트에서 TLF 소스를 까보면서 문제를 해결하기 위해 노력했었고, 소스가 공개되어 있지 않은 녀석은 디컴파일 까지 해가면서 문제를 해결하기 위해 노력했었죠.
http://cafe.naver.com/flashactionscript/43762
http://cafe.naver.com/flashactionscript/44397
http://cafe.naver.com/flashactionscript/44544
http://cafe.naver.com/flashactionscript/50213
http://cafe.naver.com/flashactionscript/50226
http://cafe.naver.com/flashactionscript/52161
http://cafe.naver.com/flashactionscript/52623
http://cafe.naver.com/flashactionscript/52836
http://cafe.naver.com/flashactionscript/52856
http://cafe.naver.com/flashactionscript/53256
http://cafe.naver.com/flashactionscript/53478
대충 FTE, TLF 에 대해 썼던 글만 해도 이정도군요...
일단 간단히 결론만 이야기 하자면, 저와 TLF 는 "우리 이제 그만 헤어져~" 상태가 되어버렸습니다. TLFTextField 의 에러도 에러지만, 거의 호러에 가까운 스크롤 시의 속도 저하와 입력텍스트 상황에서 고속 입력의 경우 입력시키는 글자가 누락되어 버리는 등의 현상들은 도저히 감당히 되지 않는거죠...
일단 몇가지 안내를 하자면
1 . 스크롤 되어야 하는 텍스트에 절대로 TLF 를 사용하지 마십시오.
지옥에 가까운 스크롤 속도의 저하를 보게 될 것입니다. TLF 텍스트 스크롤의 리소스를 찍어보면 그 원인을 알 수 있는데 스크롤이 조금이라도 움직일때마다 모든 글자들이 addChild 와 removeChild 를 미친듯이 반복하게 됩니다.
TextField 가 스크롤바를 따라 자연스럽게 움직이는 모습을 보여준다면, TLF 를 통한 Text 의 스크롤에서는 의도치 않은 트위닝 효과를 보게 될 것입니다...
2 . 입력텍스트에 TLF 를 사용하지 마십시오. (특히나 embed 된 font 를 통해서는 더더욱...)
어지간히 가벼운 입력일 경우 대충 돌아가지만 부하가 일어나기 시작하는 순간 입력중이던 글자들이 드롭되는 채로 입력되는 모습을 볼 수 있을 것입니다.
3 . 쉽게 이야기해서 위의 두가지 상황 덕분에 여러분은 TLF Markup 을 사용하는 것을 포기하는 것이 좋습니다.
TLF 로의 변화에서 가장 우리를 기쁘게 했던것이, Flash Text 도 드디어 멀쩡한 형태의 Markup 기준이 생겼다는 것이었을텐데... 스크롤과 입력텍스트 에서 일어나는 과부하 문제 덕분에 여러분은 이 Markup 에 대한 기대를 버리는 것이 좋습니다.
4 . 스크롤 되어야 하는 장문의 글과 입력텍스트는 embed font 를 사용하지 않는 TextField 를 통해 처리하십시오.
윈도우와 비 윈도우 간의 포맷표현이 문제가 되는데 이 문제는 아래와 같이 해결하십시오.
var format : TextFormat = new TextFormat();
format.font = /Windows/g.test(Capabilities.os) ? "돋움" : "Verdana";
위의 코드는 windows 기반의 OS 에서는 돋움을 표현하고, 그 외의 경우에는 sans serif 폰트를 지정하는 Verdana 를 지정하게 됩니다. (Arial 은 맥에서 한글입력시 serif font 로 대체되게 됩니다. Verdana 를 사용하십시오.)
좀 더 세분화 시키면 Windows 의 버전을 체크해서 xp 이전까지는 "돋움" 으로 하고, Vista, 7 이후에서는 "맑은 고딕" 을 사용할 수 도 있습니다. 그리고, 좀 더 세분화해서 들어가면 Font.enumerateFonts(true) 를 통해서 현재 디바이스 상에 설치된 폰트들을 읽어내고, 그 중, 여러분이 의도하는 폰트들을 지정할 수도 있습니다.
TLF 의 FontFamily 기능은 편리하지만, 위와 같이 대체할 수도 있습니다.
그리고, TextField 에서 embed font 를 통한 입력텍스트 표현은 최근 저 자신이 입력지연 및 입력이 날아가는 문제를 겪었습니다. (가장 최신의 플레이어에서...) 입력텍스트에 embed font 를 사용하는 것은 지양하십시오.
5 . 하지만, StringTextLineFactory 와 같은 경우는 사용을 권장합니다.
TLF 의 여러가지 성능문제는 대체적인 경우 반복적인 TextLine 의 재생성과 반복적인 addChild, removeChild 의 반복에서
일어나는 것으로 보여집니다. 하지만, StringTextLineFactory 와 같은 경우는 위에서 이야기한 반복이 없습니다.
그리고, 아주 가벼운 텍스트의 표현에 있어서는 TextField 보다 빠른 퍼포먼스를 보여줍니다.
다만, StringTextLineFactory 와 같은 Factory 류의 생성방식은 상호작용 (selection, input, link) 등의 기능을 모두 사용할 수 없는 단순한 디스플레이 용도로 제한이 됩니다.
하지만, 단순한 디스플레이 용도로 사용하더라도 TruncationOption 이나 Vertical Align, 보다 적은 용량의 embed font 와 같은 TLF 의 장점들을 활용하기엔 StringTextLineFactory 도 충분한 역할을 할 수 있을 것입니다.
6 . 결과적으로 이야기하는 것은...
스타일링 된 텍스트의 표현엔 "StringTextLineFactory" 를 사용하고 (이것은 fla 를 사용하는 이들에겐 상관없는 이야기임... 애초에 StaticTextField 는 Text 가 아니라 그림이니깐...), 입력과 스크롤, 셀렉션 등의 상호작용을 요구하는 기능들에는 embed font 를 사용하지 않는 TextField 를 사용하십시오.
물론... 느린것을 보았던 몇달 전의 저와같이 "뭔가 방법이 있겠지~" 라고 생각하면서 해결방법을 찾느라고 고생할 몇몇 사람들이 있긴 하겠지만... 그리고, 제가 이야기한 TLF 의 부정적인 부분들을 해결할 방법을 찾아낼 수 있는 분들도 있을지 모르겠지만...
(어쩌면 지금까지 이야기했던 면면들은 제 실력이 부족해서 제대로 활용을 못했던 것일지도 모르죠...)
일단, TLF 에 상당한 시간을 투자한 저로서는 StringTextLineFactory 와 같은 디스플레이용의 텍스트 표현을 제외한 영역에서의 TLF 의 사용을 지양하라는 말을 하고 싶습니다.
상당히 오랜시간을 투자했는데도 불구하고 애초에 잘못 만들어진 녀석이라는 것 이외엔 어떤 해결방법도 찾지 못했습니다.
어쨌든... TLF 와는 가끔 카페에서 만나 StringTextLineFactory 에 대한 이야기나 나누는 좋은 친구로 돌아가려 합니다. "우리 이제 그만 헤어지자..."
Text Layout Framework 간단한 안내
HTML 과 Flash 로 동시에 파싱되는 위키 언어 만든답시고 삽질 하고, 컴포넌트 만든다고 삽질하고 하다보니 어느새 TLF 도 적당히 손에 익어가는 중입니다.
자세한 내용들을 쓰기엔 내용이 너무 방대하기 때문에 나중에 시간이 남으면 써보기로 하고... 작업 동안 경험했던 간단한 팁들을 안내해볼까 합니다.
1 . Font, Embed Font 의 표현
매우 필요했지만, 한글 폰트 자체의 용량 덕분에 쓰는 것이 주저되었던 Embed Font 의 사용환경이 TLF 에 들어서는 매우 좋아진 편입니다.
일단, Embed Font 의 용량자체가 상당히 줄었기 때문에 (이전에 약 7MB 짜리 폰트가 TLF 에서는 2MB 정도로 압축가능 하기 때문에) 독립적인 swf 로 분리해서 사이트 전체적으로 런타임 공유를 통해 사용한다면 크게 부담되지 않는 수준입니다.
다만, 여러개의 폰트들을 그룹으로 지정해서 1순위 폰트에 필드가 없을 경우, 다음 순위의 폰트에서 글자를 찾는 fontFamily 의 존재에도 불구하고 fontLookup 의 일방성 덕분인지 embedFont 에 없는 한자나 특수문자의 표현에는 무리가 있는 편이네요... embed font 에 없는 필드를 device font 로 대체할 수도 있지 않을까 싶긴 한데... 아직 방법은 찾지 못했습니다. (아니면, 테스트에 사용한 나눔고딕에 한자 필드가 아예 없는게 아니라, 공백으로 넣어뒀을 가능성도 있겠군요...)
2 . ITextLayoutFormat, TextLayoutFormat
TLF 에서 사용하는 TextLyaoutFormat 은 크게 paragraph (문단) 의 모양을 조절하는 기능과 font 의 모양을 조절하는 기능 (FTE 에서 FontDescription) 과 글의 모양을 조절하는 기능 (FTE 에서 ElementFormat) 과 그 외, 몇가지 추가적인 기능들이 짬뽕되어 있는 포맷 형식 입니다.
이전에 사용하던 TextFormat 보다는 상당히 디테일한 지원을 해줍니다. 딱히 정리해서 설명하긴 어렵고, TLF 를 사용할때 모든 모양에 대한 조절을 원한다면 이 flashx.textLayout.formats.ITextLayoutFormat 을 살펴보면 됩니다.
다만, 링크에 대한 서식설정은 FlowElement 에 존재하는 linkNormalFormat, linkHoverFormat, linkActiveFormat 을 사용해야 합니다.
3 . 마법의 InlineGraphicsElement
TextFlow 상에 여러 그래픽스 오브젝트를 넣는데는 InlineGraphicsElement 가 사용되어질 수 있습니다. 이게 단순히 그림만을 지원하는 것이 아니기 때문에 원한다면 DisplayObject 를 상속받은 모든 그래픽스 오브젝트들을 TextFlow 상에 집어넣을 수 있다는 이야기가 됩니다.
제 경우에는 TLF 에 없는 html 의 <hr> 기능이나 <ol>, <ul> 등의 기능을 이 InlineGraphicsElement 를 통해 구현시켰죠. 원한다면 <table> 과 같은 고급 서식 기능을 만드는 것도 불가능하지 않다는 이야기가 됩니다. 그리고, <video> 기능을 문서 흐름속에 포함시킬 수도 있다는 이야기가 되겠죠...
InlineGraphicsElement.source 는 크게 세가지 정도를 줄 수 있는데, "image.png" 와 같은 String 형태의 uri 와 DisplayObject 로 인스턴스가 생성되는 class, 마지막으로 아싸리 DisplayObject 자체를 집어넣을 수 있습니다.
이 기능은 아직 저차원적인 수준의 지원만을 해주는 TLF 를 보다 강력한 문서표현이 가능하도록 확장시킬 수 있는 기반이 되어줍니다. 사용하기에 따라서 여러가지 것을 만들 수 있을 것 같네요.
이미지 uri 의 경우, ContainerController 에 문서 구현을 시켜주면 자동으로 로드처리를 해주는데 이때, StatusChangeEvent.INLINE_GRAPHIC_STATUS_CHANGE 이벤트를 감지해서 container update 를 시켜줘야 합니다.
그리고, InlineGraphicElement 에는 좀 특이한 버그(인지 아닌건지 잘 모를 에러)가 있는데, InlineGraphicElement 중에서 source 가 uri 로 지정된 녀석이 하나라도 있으면 Selection 시에 문제가 없는데, 아예 자체적으로 생성된 DisplayObject 나 Class 로만 source 가 구성된 녀석들만 있으면 Selelction focus 가 들어가는 순간 모든 그래픽스들이 removeChild 되어서 사라져버립니다... (ㅡ ㄴ ㅡ;;;) 이건 버그인건지 뭔지 잘 모르겠는데... 그런 문제들이 지속적으로 발생한다면 더미로 uri 로드를 하는 녀석을 하나 박아넣으면 해결이 됩니다.
4 . TLFTextField, ContainerController, TextLineFactory 의 선택
TLF 의 텍스트 표현에는 크게 세가지 정도의 선택이 있습니다.
일단, Interaction 이 전혀 되지 않는 순수하게 그림을 그리는 용도로 사용할 수 있는 TextLineFactory 기반의 기능들이 있습니다. 글자마다 서식이 다른 복잡한 녀석이라면 TextFlowTextLineFactory 를 사용할 수 있고, 서식이 하나로 통일된 단순한 녀석이라면 StringTextLineFactory 를 사용할 수 있습니다. 이 Factory 방식은 인터렉션이 필요하지 않은 아주 디스플레이용 글을 표현할 경우에 매우 유용합니다. 그리고, 무엇보다 이 Factory 방식에서는 truncation 기능 (긴 글의 마지막을 ... 으로 줄여주는 기능) 을 사용할 수 있기 때문에 굉장히 유용합니다. 주의할 점으론 TextLine 을 사용하고 난 뒤에는 수동으로 TextLineRecycler 를 통해 풀에 다시 집어넣어줘야 한다는 점 정도가 있겠네요.
그리고, ContainerController 나 좀 더 단순화된 TextContainerManager 는 좀 더 디테일한 기능의 조절이 가능합니다. 말 그대로 TextFlow 를 컨트롤하는 원천이기 때문에 Interaction 이 가능한 글을 만들려 할때는 가장 베이스가 되는 녀석입니다. 다만... 원천인 녀석답게 단순하게 쓰는데는 매우 편리하고 가볍지만, 복잡한 "쓰기", "스크롤" 기능들을 만들때는 매우 해야할게 많습니다. 특히나 쓰기에서 displayAsPassword 나 restrict 기능들이 하나도 구현되지 않은 정말 저수준의 녀석이기 때문에 시간이 넘쳐 흐르지 않는 이상 이 것으로 "쓰기" 기능을 구현하지 않는 것이 정신건강에 좋습니다.
마지막으로 Flash 에 포함되어 있는 TLFTextField 나 Flex SDK 에 포함된 input component 들이 있는데 쓰기 기능들을 구현하는데는 그냥 만들어져 있는 이 기능들을 사용하는게 좋습니다. TLFTextField 의 경우엔 좀 Class 가 정체를 알 수 없는 느낌으로 TextField 적인 api 와 TLF 의 api 가 짬뽕된 녀석이라 좀 거시기하지만... 정신의 평온을 위해선 이걸 쓰는 것을 추천합니다.
결론을 이야기 하자면
걍 디스플레이 용도의 간단한 텍스트 = TextLineFactory 계열
자유롭게 커스텀 할 수 있는 간단한 용도 = Controller 계열
쓰기 등 복잡한 처리가 필요한 폼 형식 = TLFTextField 등의 컴포넌트 계열
을 사용하면 될 것 같습니다.
사용법이 각각 계열마다 상당히 큰 차이가 나므로 익혀야 하는 api 수가 TextField 보다 많지만, 이래저래 성능 고려하거나 합리적으로 만들려고 할때는 도움이 많이 됩니다.
5 . TextFlow 의 후가공 처리
TextFlow 에는 getElementByID 와 getElementsByStyleName 이라는 두가지 메서드를 통해서 각 Element 를 불러오는 것이 가능합니다. 이 기능은 CSS 라는 일괄 서식지정 기능이 없는 TLF 에 도움이 많이 되고, 특히나 위에서 이야기한 InlineGraphicsElement 등을 사용하는데 도움이 많이 되는 편입니다.
getElementByStyleName 을 통해서 같은 스타일의 Element 들을 일괄적으로 모은 뒤에 서식지정을 한다거나 하는데 도움이 많이 됩니다.
6 . TextConverter, ITextExporter, ITextImporter
TLF 가 기존 TextField 보다 좋아진 점 대표적으로 꼽을 만한 것은 XML 형태의 전용 마크업 언어가 있다는 것인데요... 이를 통해서 서식이 지정된 텍스트를 저장하거나 읽어들이는 작업이 가능합니다.
다만, 마크업 언어 자체가 아직까지는 단순 서식 문서 정도만 지원하기 때문에 복잡한 처리를 위해서는 필연적으로 위에서 언급한 InlineGraphicElement 를 통해 확장시킬 필요가 있습니다.
제 경우에는 복잡한 쓰기 기능은 그냥 TLFTextField 를 사용하기로 했기 때문에 주로 flashx.textLayout.container 와 flashx.textLayout.conversion, flashx.textLayout.elements, flashx.textLayout.factory, flashx.textLayout.formats 만 보고 있습니다. flashx.textLayout.operations 나 flashx.textLayout.edit, flashx.textLayout.undo 의 경우엔 만지기 시작하니깐 사람 상당히 피곤하게 만드는 경향이 있어서 작업하다가 아예 포기해버렸습니다. 뭐... 혹시나 플래시로 위지윅 에디터 만들려는 사람들 아니라면 딱히 만질일이 별로 없는 부분이기도 합니다. 쓰기 부분을 피해서 알아보면 의외로 분량이 그다지 많지 않은 편입니다. 텍스트 엔진을 TLF 베이스로 바꾸고 싶으신 분들에겐 조금 참고가 되지 않을까 하네요...
그럼 이만~ 앙뇽~
