비정상 컴퍼넌트이거나, 아직 랜더링이 안된 경우입니다.
기초 모듈패턴에서도, return 이후에나 엘리먼트에 접근이 가능한데 전반부에 Ext.getCmp 등으로 컴퍼넌트를 가져올 수 는 있어도, 엘리먼트를 가져올 수 는 없습니다. 스토리는 이렇습니다.

- 스토리 -
버튼모양을 아래처럼 변경하기 위해, 직접 엘리먼트에 접근하기로 했습니다. 

참조소스가 ext2.X 대에서 제작된 것이긴 했는데, 아래와 같이 버튼을 재정의 하고 있었습니다.

this.fileList.on('render',function(){
			this.fileList.getBottomToolbar().add(this.progressBar);
			var tb = this.fileList.getTopToolbar();
			tb.add({
				text : '添加文件',
				iconCls : 'db-icn-add'
			});
			var em = this.fileList.getTopToolbar().items.first().el.child('em');
                        //객체접근 방법이 중요한게 아니라, 위에서 el 이 undefind 가 발생합니다. 
            var placeHolderId = Ext.id();
            em.setStyle({
                position: 'relative',
                display: 'block'
            });
            em.createChild({
                tag: 'div',
                id: placeHolderId
            });
위와 같이 리스트에 render 리스너를 달아, 리스트 랜더링이 끝난후, 툴바의 버튼을 가져와 스타일과 태그를 조작하고 있습니다만, el 이 널이거나 undefind 가 발생하게 됩니다. 하지만 이 소스는 ext 하위 버젼에선 잘 돌아가는 소스였습니다. 문제는 lazy rendering (xtype) 등으로 인해, 상위 리스트 컴퍼넌트가 랜더링 되었다고, 반드시 하위에 붙어있는 툴바의 버튼들이 랜더링이 완료되었다는 보장이 없습니다. renddered 속성을 보면 리스트는 true 이나, 버튼은 false 임을 알 수 있었습니다. 그래서 해당 버튼을 초기화하고, 버튼에 직접 리스너를 걸어주었더니 잘 되는군요.

        this._btnAdd = new Ext.Button({
            text: '파일추가',
            iconCls: 'db-icn-add'
        });
        this._btnAdd.on('render', function(){
            //랜더링은 언제하는거냐? 
            var em = this.fileList.getTopToolbar().items.first().el.child('em');
            var placeHolderId = Ext.id();
            em.setStyle({
                position: 'relative',
                display: 'block'
            });
            em.createChild({
                tag: 'div',
                id: placeHolderId,
				html: '<HR><BR>메롱'
            });
        }, this);
이거 때문에 정말 삽질 많이 했습니다. 포럼에 물어보기도 애매하고, 역시 기초가 중요하군요. 잘 생각해보면 어쩌면 당연한걸수도 있었습니다. ㅜ.ㅜ 
Posted by (김영근) naucika

오늘자로 RC3 가 올라왔습니다. 위에서 보시는대로 차주 월요일에 final 이 릴리즈 되는군요. 4일동안 final 이라니.. 어쨋든 IE 시리즈등에서 좀 문제가 있습니다. 이번에 fix 되었음 좋겠는데, final 이 얼마 안남았으니 좀더 기다려 볼렵니다. 
Posted by (김영근) naucika
TAG Extjs, RC3
extJS 를 보다보면 아래와 같은 유형의 로직이 많이 들어있습니다. (물론, 튜토리얼을 참조했다면 다 아는 내용이지만) 이것은 Eric Miraglia 씨의 JavaScript Module Pattern 입니다.
var o = function() {
    return {p1:11, p2:22};
}();
ExtJS에서는 아래와 같이 어플리케이션을 초기화 하는데, 주요 이유는 글로벌 변수를 최소화 하고, private/public 등으로 객체제어를 위한것 같습니다. 하지만, 디버깅이 쉽지않고, 구조가 조금 복잡해 집니다.

YAHOO.myProject.myModule = function () {

	//"private" variables:
	var myPrivateVar = "I can be accessed only from within YAHOO.myProject.myModule.";

	//"private" method:
	var myPrivateMethod = function () {
		YAHOO.log("I can be accessed only from within YAHOO.myProject.myModule");
	}

	return  {
		myPublicProperty: "I'm accessible as YAHOO.myProject.myModule.myPublicProperty."
		myPublicMethod: function () {
			YAHOO.log("I'm accessible as YAHOO.myProject.myModule.myPublicMethod.");

			//Within myProject, I can access "private" vars and methods:
			YAHOO.log(myPrivateVar);
			YAHOO.log(myPrivateMethod());

			//The native scope of myPublicMethod is myProject; we can
			//access public members using "this":
			YAHOO.log(this.myPublicProperty);
		}
	};

}(); // the parens here cause the anonymous function to execute and return

어쨋든 해당 구조는 모듈패턴을 기초로 하고 있습니다. 
세부내용은 모듈패턴을 참조하시기 바랍니다.
Posted by (김영근) naucika
 이번에 extJS 를 도입하면서, 컴퍼넌트 생성하고 활용하는데에 비교해 보면 기존 GWT 보다 뛰어난 점이 많이 있었습니다. 컴파일시간도 단축될 뿐더러, 객체 생성이나 접근도 훨씬 간결하고 수정하기도 좋습니다. 하지만 여전히 동일한 문제를 안고 있는것이 있습니다. 그것은 정작 제게 필요한 기능이 없을 경우입니다. 이 경우엔 해당 컴퍼넌트의 소스를 보고 작동원리를 이해하고, 기능을 추가/수정 (Modify) 혹은 재정의등을 하는수 밖에 없습니다. 가만히 생각해보면 늘상 문제는 여기에 있었습니다. 여태까지 개발해 오면서, 제공된 컴퍼넌트를 그대로 활용해서 사용해본 기억은 한번도 없었던 것 같습니다. GWT또한 마찬가지고, EXT도 마찬가지이고, Flex라고 다르지 않습니다. 저마다 툴킷들은 간단하게 사용하게 하기 위해 수많은 컴퍼넌트들을 제공하고, 그양과 질은 다를지언정 저에게 필요한 기능을 모두 갖추고 입맛에 맞는 것들은 찾기 어렵다는 것이죠. 

 오류 또한 마찬가지입니다. 거의 다 만들었는데, 한개의 오류때문에 시스템이 돌아가질 않고, UI는 조금만 더 사용하다보면 알 수 없는 오류를 뱉어냅니다. 정말 90% 이상 내가 다 만들었는데, 단지 10%의 오류를 해결하지 못해 좋은 평가를 받지 못한다는 것이 억울하다면, 다시한번 자신을 돌아봐야 합니다. 그건 10%의 오류가 아니라, 전체를 좌지하는 매우 중대한 이론이고, 아주 중요한걸 이해하지 못하고 있다는 것입니다. 다시말해 10% 어쩌면 단지 1% 때문에 실력이 판가름 나고 있다고 할 수도 있습니다. 1%를 이해하려면 전체를 다시 이해해야 할지도 모를일이고, 단지 1%만을 이해하고 코드를 작성하고 있을지도 모를일입니다. 

 이것을 판단하는 기준잣대는 아주 간단합니다. 내가 하고 있는일을 남들도 할수 있을까? 할 수 있다면 누가 할수 있을까? 를 생각해보면 쉬운일이죠. 1%라도 자신은 죽었다 깨어나도 못한다면, 반성해 봐야 할 일입니다. 개발에 있어선 한손은 거드는게 아니라, 어쩌면 전체를 좌지할 수 있는 "핵심 키" 일지도 모르겠습니다. 하지만 가장 큰 우를 범하는 것은 위에서 말한것처럼 "99% 를 다 했는데, 단지 1%를 거들었을 뿐이야" 라고 생각하는 자만심입니다. 여기서 99%나 70%나 60%는 큰 차이가 없을지도 모릅니다. 하지만 99% 와 1%의 차이는 하늘과 땅의 차이라 해도 과언이 아닙니다. 1%때문에 모든걸 다시 공부해야 할지도 모르니까.
Posted by (김영근) naucika
이번 컨셉은 가장 simple 하면서도, 본문읽기에 걸림돌이 없으면서도, 네비게이션이 편한..
흠.. 그냥 귀찮아서 단순한거로 골랐습니다. 이제 디자인 신경쓰기도 삐리리 하네요. 이젠 불여우나 크롬도 문제없습니다. 크롬 빨라서 너무 좋네요 ㅜ.ㅜ 본문 폰트도 눈에 확~ 들어오는것으로 고심해서 바꿧는데, 잘 들어오네요. 이쁜것도 좋지만, 가독성이 좋아야죠.

디자인 예기가 나와서 그런데, 엊그제 만들고 있던 프러덕의 디자인을 좀 바꿧습니다. 아이콘 이것저것 붙였다 뗫다 해보면서, 레이아웃 이리저리 바꾸면서, 에니메이션 조정하면서, 정말 많은 덧없는 시간을 보냈습니다. 물론 요즘은 포토샵을 띄워서 컨트롤까진 안하지만, 그냥 디자인 적용하는것도 힘이 들더군요. 뭐 그것까진 좋습니다. 그럴수도 있죠. 더 낳아질려고 조금이나마 발버둥 치는것이니까.. 하지만, 반응들이 영 시원찮았습니다. 직접적이진 않지만 이런식입니다. "아 왜 혼자 멋대로 바꿔서 멀쩡히 잘돌아가는 다른것들도 바꾸게 일을 만들어." (사실 멋대로 바꾸진 않았습니다. 매일매일 공유했는데, 관심이 없었을 뿐이지) "다 만든거 보니까, 대충 전것보단 조금 달라지긴 했네?" "미리 사전에 협의를 해야지" "디자인은 다른시간에 논의하지?"

흠.. 표준템플릿 변경하고, 새로운 언어 적용하는데 8일걸렸습니다. 8일동안 머리 줘 뜯어가면서 했더니, 아. 차라리 8일동안 PT나 만들고 다른사람 만들어보라고 시킬껄..하는 생각이 들더군요. 사람들이 싫은것보다, 돈을 덜주는것보다, 이럴때가 더 일하기 싫어집니다.목표를 잃어버릴때이죠. 내가 누구 좋자고, 이짖거리를 하고 잇을까..하고 생각이 들때이죠.

항상 개선과 변화와 발전은 고통이 동반됩니다. 누구나 아는 사실이죠. 아무도 기존에 잘 쓰고 있던걸, 좀더 낳은 장점이 있다고 바꾸려 들지 않습니다. 귀찮으니까..! 문제는 개선된 결과가 좋다면, 변화에 빠르게 적응하는 사람이 살아남습니다. 물론 개선된 결과가 안좋은경우까지 감당해 내면서 말이죠. 안그럼 고인물이 썩게되고, 자연 도태 되게 될테니까. DOS나 관공서의 한글처럼... 제 주변엔 이런 사람들이 많이 있었으면 했습니다. 새로운걸 시작하면서, 서로 이것저것 해보고, 시행착오를 같이 겪으면서 같은 목표를 바라보는 사람들. 돈만 벌고보자는 돈의 노예가 아닌사람들. 분명히 어디엔간 있을겝니다. 아무리 오래걸려도 제 일에 대한 자부심은 버리지 않을랍니다. 안그럼 정말 이짓 못할것 같습니다.
 
디자인은 역시 어렵습니다!
Posted by (김영근) naucika
TAG 디자인