JavaScript/Default2010. 5. 28. 11:25

스크립의 작성 위치는 기본적으로 <head>역역과 <body>영역에 작성할 수 있습니다.
<head>영역에 적성할 경우 문서가 로딩되기 전에 스크립트 코드가 전달 되기 때문에 문서의 로딩과 동시에 스크립트 실행이 가능합니다. 하지만 <body>영역에 스크립트 코드가 작성되어 있다면 로딩 되면서 스크립트 코드가 실행 됩니다.

이 부분은 스크립트의 실행에도 중요한 부분을 차지 하지만 스크립트 파일을 불러올 경우 head와 body역영의 위치에 따라 불러오는 차이도 있습니다.

무슨말인가 하면 head에 스크립트 파일이 위치 한다면 화면상 내용이 렌더링이 안되고 있다는 말입니다. 이 렌더링 부분은 브라우저 마다 약간의 차이는 있지만 보통 body 안의 내용을 순차적으로 보여줍니다.

근데 만약 head에 무거운 자바파일이 존재 할 경우(처음 파일을 받기전) body의 렌더링은 head안의 스크립트가 모두 전달 된 후 시작 된다는 말입니다.

즉 당장 렌더링 되는 과정에 필요한 함수가 있다면 또는 렌더링 되는 과정에 인벤트를 발생 할 필요가 있다면 그 함수는 head에 넣어 두는게 좋으며, 그 외의 스크립트는 body 하단 부분에 두는게 렌더링 측면에서 효과가 있을 것입니다.

Posted by Jake Kim
HTML/CSS2010. 5. 4. 09:11

적당히 아는게 참 무서운거다... 적당히 그런게 있어라고만 알고 있었는데.. 이 참에 좀 적어놔야 겠다.

지금까지 일반적으로 Javascript를 웹 문서에 올려 놓을때 MIME TYPE으로 대충 다음의 것들을 사용했다.

* text/javascript
* text/ecmascript
* application/x-javascript (javascript 앞에 x가 붙은 것은 표준이 아닌, 실험적인 것임을 뜻함)
* text/javascript1.5 (요새 브라우저들은 버전 숫자를 그냥 무시해 버림)
* language="JavaScript" (HTML 4부터는 지원하지 않음)

그래서 이런 혼란스런 상황을 막으려고 2006년 4월에 Javascript(ECMAScirpt)를 위한 MIME type의 표준(RFC4329)이 마련되었지만, 여러 브라우저들의 표준 JavaScript MIME type 지원은 아직 요원한 상황이다.
(확인해 본 바로는, 지금까지 오직 Firefox 1.5+, Opera 9+, Camino 만이 지원하고 있다.)

Javascript 프로그램은 그 성격상 text 문서로 지정하는 것은 적절치 않으며, 대신 application/javascript 혹은 application/ecmascript(이것을 사용하면 좀 더 엄격한 적용 규칙이 주어진다)를 대신 사용할 것을 권장하고 있지만, 이는 대부분의 웹 브라우저들이 지원하지 않는 한 그 실제 적용은 아직 이를 것이다.

Posted by Jake Kim
프로그램2010. 4. 21. 10:46

파이어폭스를 쓴다면... 파이어버그를 쓴다면 좋겠지만...

http://www.fiddler2.com/fiddler2/

Posted by Jake Kim
기술정보2010. 4. 19. 12:37

-vmargs
-Xms256m
-Xmx512m
-XX:MaxPermSize=128m

메모리 변경....
Posted by Jake Kim
HTML/CSS2010. 4. 2. 23:29




object 제어 요소
  offsetLeft, offsetTop, offsetWidth, offsetHeight,
  clientLeft, clientTop, clientWidth, clientHeight,
  scrollLeft, scrollTop, scrollWidth, scrollHeight
 
style 제어 요소
 margin, padding, border

Posted by Jake Kim
.NET2010. 3. 30. 09:46

DB에 에서 데이타를 가져온다면... DataSet이나 DataReader를 사용해 봤을 것이다.(DataTable은 DataSet과 동일하다.)

이때... 기본적으로 DataReader가 DataSet보단 성능상 잇점이 많다고 한다. 하지만 개발을 하다 보면.. DataSet이나 DataTable이 필요할 때가 있다. 그리고 사용하기도 편하다.

아무튼.. 이런 경우 어느때 이 둘을 나눠서 사용 해야 할지 고민해 볼 필요가 있다.

그래서.. 이런 글을 준비했다.^^;

아래 내용은 인터넷 어디선가... 퍼온 글이다... 출처를 모르겠다.

Use DataReader objects instead of DataSet when ever you need to display data. DataReader is the most efficient means of data retrieval!! as they are read and forward only. DataSet are disconnected and in-memory therefore uses valuable server resources. Only use them when you need the same data more then once or want to do some processing on the data.

Last but certainly not the least follow the best coding, design and deployment patterns and practices. Here are few more usefull links that can be very helpful in performance optimization of you ASP.NET application

http://msdn.microsoft.com/en-us/library/ms973838.aspx
http://msdn.microsoft.com/en-us/library/ms998569.aspx
http://msdn.microsoft.com/en-us/magazine/cc500561.aspx
http://msdn.microsoft.com/en-us/library/ms998549.aspx
http://msdn.microsoft.com/en-us/library/ms973839.aspx

번역을 위해 준비한 글이 아니기 때문에 간략이 직역을 해보자면

데이타를 화면에 출력할 필요가 있을 경우 DataSet대신 DataReader객체를 사용하란다. DataReader가 데이타를 읽고 수신하는데 훨씬 효과적이란다.  DataSet은 비연결 방식으로 데이타를 서버 메모리에 저장하기 때문에 서버 자원을 사용하기 때문에 안좋단다. 아무튼 이런 이유로 DataSet은 같은 데이타를 한번 이상 사용하거나 데이타 가공이 필요한 경우에 사용하란다.

물론 가장 확실한 방법은 코딩과, 설계, 패턴 등에 따르라고 하는데... (ㅡ.ㅡ; 왠지 낚인기분인데...) 아무튼 링크된 곳을 참고하기 바란다.

Posted by Jake Kim
프로그램2010. 3. 5. 10:04

PPT를 각각의 독립된 창으로 열수 있도록 하는 파일입니다.


첨부파일 압축을 풀면 PPCORE.DLL 파일이 보이는데 이 DLL 파일을
C:\Program Files\Microsoft Office\Office12 에 덮어쓰기 하시면 PPT를 두개이상 띄워서 사용이 가능합니다. 듀얼모니터를 사용하시면 더욱 편하게 사용하실 수 있을 것 같습니다.

단, 이 DLL은 오피스 2007 버전에서만 사용이 가능합니다.

오피스 2003 버전에서도 다중으로 창의 띄워 사용하고 싶으시면 http://www.virgo81.net/26<- 여기를 참고하세요.

Posted by Jake Kim
JavaScript/Default2010. 2. 26. 11:08
출처: Advanced JavaScript(http://www.slideshare.net/stoyan/advanced-javascript-presentation) 프리젠테이션 36페이지 내용에서 인용했습니다.



   Use this    Not That
   var obj = {};    var obj = new Object();
   var arr = [];     var arr = new Array();
   var reg = /[a-z]/gmi;    var rec = new RegExp('[a-z]','gmi');
   var fnc = function(a,b){a+b}    var fnc = new Function('a,b','return a+b');


두가지 방법 모두 의미적으로는 동일합니다. 위 프리젠테이션에서 첫번째 방법을 선호한 이유는 일단 사용하기가 편하기 때문이죠.
초기 자바스크립트에선 객체를 구문적으로 엄밀히 구분할수 없어 두번째 방법으로 코딩 했으나... 지금은 첫번째 방법으로 코딩해도 객체를 구분으로 파악 할 수 있기 때문에 사용상 편한 첫 번째 방법을 권하고 있는것 같습니다.
Posted by Jake Kim
JavaScript/ExtJS2010. 2. 24. 15:27

기본적으로 Extjs의 NumberField를 사용하게 되면 숫자형식을 벋어난 값은 입력 받을 수 없게 만들어 준다.

허용된 값들은 0-9 . - 이다.

여기서는 좀더 효과적인 NumberField 를 사용하기 위해 몇가지를 수정 했다.

1. onkeyup를 통해서 숫자값 확인
2. 숫자에 콤마 붙이기
3. 음수 확인
4. 소숫점 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
Ext.onReady(function() {
ChageTextFieldToNumberField("textTest"); //이벤트에 적용할 필드명
//값이 여러개 일경우
//ChageTextFieldToNumberField("id1","id2","id3");
});
 
function toNumber(v) {
    var val;
    var n = (String(v).replace(/[^\d.]/g, ""));
    if (n.indexOf('.') >= 0) {
        val = Number(String(n.split('.')[0]).replace(/[^\d]/g, "")).toLocaleString().slice(0, -3)
            + "." +
            String(n.split('.')[1].replace(/[^\d]/g, ""));
    }
    else {
        val = Number(String(n).replace(/[^\d]/g, "")).toLocaleString().slice(0, -3);
    }
    //음수처리
    if (v.indexOf('-') >= 0) {
        val = "-" + val;
    }
    return val;
}
function onKeyUp_Event(field, e) {
    var v = field.getRawValue();
    field.setRawValue(toNumber(v));           
}
function ChageTextFieldToNumberField(){
    for(var i = 0 ; i < arguments.length ; i++)
    {
        var textField = arguments[i];
        if(document.getElementById(textField) != undefined)
        {
            var targetInput = document.getElementById(textField);
 
            var number = new Ext.form.NumberField({
                applyTo: targetInput,
                id: targetInput.id,
                allowBlank: true,
                allowNegative: true,
                selectOnFocus: true,
                enableKeyEvents: true,
                listeners: {
                    scope: this,
                    keyup: onKeyUp_Event
                }
            });
        }//end if
    }//end loop
} //end funtion
 
 
//Ext.form.NumberField 오버라이드를 통해 기본 메서드 변경
Ext.override(
    Ext.form.NumberField, {
        setValue: function(v) {
            v = v.replace(/,/g, "");//추가
            v = typeof v == 'number' ? v : parseFloat(String(v).replace(this.decimalSeparator, "."));
            v = isNaN(v) ? '' : String(v).replace(".", this.decimalSeparator);
 
            v = toNumber(v);//추가
            return Ext.form.NumberField.superclass.setValue.call(this, v);
        },
        validateValue: function(value) {
            value = value.replace(/,/g, "");//추가
 
            if (!Ext.form.NumberField.superclass.validateValue.call(this, value)) {
                return false;
            }
            if (value.length < 1) {
                return true;
            }
            value = String(value).replace(this.decimalSeparator, ".");
 
            if (isNaN(value)) {
                this.markInvalid(String.format(this.nanText, value));
                return false;
            }
            var num = this.parseValue(value);
            if (num < this.minValue) {
                this.markInvalid(String.format(this.minText, this.minValue));
                return false;
            }
            if (num > this.maxValue) {
                this.markInvalid(String.format(this.maxText, this.maxValue));
                return false;
            }
            return true;
        },
        beforeBlur: function() {
            //내용수정
            this.setValue(this.getRawValue());
        }
    }
);

1
2
3
...
<input id="textTest" name="textTest">
...


TIP.
DB에 저장 해야하는 값중 소숫점의 제한이 있는 경우, 예를 들자면 ORACLE에서 NUMBER(10,2)인 경우 아래 처럼 소스를 추가하자

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
function toPrecisionNumber(v, scale, precision) {
        if (scale < precision) {
            throw "scale과 precision값을 확인 해주세요. (scale-precision=은 음수가 될수 없음_";
        }
        var val;
        var n = (String(v).replace(/[^\d.]/g, ""));
        if (n.indexOf('.') >= 0) {
            val = Number(String(n.split('.')[0]).replace(/[^\d]/g, "").substring(0, scale - precision)).toLocaleString().slice(0, -3)
                + "." +
                String(n.split('.')[1].replace(/[^\d]/g, "").substring(0, precision));
        }
        else {
            val = Number(String(n).replace(/[^\d]/g, "").substring(0, scale - precision)).toLocaleString().slice(0, -3);
        }
 
        //음수처리
        if (v.indexOf('-') >= 0) {
            val = "-" + val;
        }
        return val;
    }
    function onKeyUp_Event(field, e) {
        var v = field.getRawValue();
         
        //DB상의 10, 2 같은 값 처리
        var tmpValue = (String(v).replace(/[^\d.]/g, ""));
        var scale = parseInt(field.getEl().getAttribute('scale'));
        var precision = parseInt(field.getEl().getAttribute('precision'));
         
        if (scale && tmpValue.length > 3) {
            if (!precision) {
                precision = "0";
            }
            scale = parseInt(scale);
            precision = parseInt(precision);
            v = toPrecisionNumber(v, scale, precision);
        }
        field.setRawValue(toNumber(v));           
    }

1
2
3
...
<input id="textTest" name="textTest" precision="2" scale="10">
...
Posted by Jake Kim
HTML/CSS2010. 2. 24. 14:59

tabindex라는 속성이 있습니다. 말 그대로 tab의 접근 순서를 인위적으로 변경할 수 있는 속성 입니다.
tabindex는 다음 요소에 적용할 수 있습니다.

a, area, button, input, object, select, textarea

이 요소들 이외의 요소에 tabindex 속성이 지정되면 문법적으로 유효하지 않습니다. 그러나 문법적으로 옳고 그름을 떠나 한 가지 질문을 던져 보겠습니다.

tabindex 속성을 왜 사용하시나요?

여러분은 아마도 아래 두 가지 경우중 하나의 대답을 선택할 것입니다.

1. 사용성을 높이기 위하여.
2. 접근 순서를 보완하기 위하여.

tabindex, 사용성을 높인 사례.

포털 초기화면에서 가장 많은 포커스를 가져가는 곳을 순서대로 정렬시켜 보면 어떨까요?

1. 검색 인풋
2. 아이디 인풋
3. 비밀번호 인풋
4. 로그인 버튼

맞나요? 객관적으로 제시할 근거 자료는 없지만 저는 거의 확신하고 있습니다. 국내 양대 포털인 DAUMNAVER에 가서 키보드만으로 웹 페이지를 탐색해 보세요. tab 키는 ‘검색 인풋-아이디 인풋-비밀번호 인풋-로그인 버튼’ 순으로 이동할 것입니다.
양대 포털은 누가 먼저랄 것도 없이 이 네 가지 요소에 tabindex를 적용 했습니다. 굳이 누가 먼저 했는지를 따지는 것은 의미는 없는 일입니다. 어느 한쪽이 뒤늦게 이것을 했다고 해서 따라했다는 소리를 들을 필요는 없다고 생각하니까요. 키보드만으로 웹 페이지를 탐색하는 사람들은 보통 장애인이거나 또는 숙련된 사람들 입니다. 이 사람들에게 포털에서 제공한 tabindex키는 분명 도움이 되었을 것입니다. 굳이 제공하지 않더라도 접근에 제한이 되는것은 아니지만 제공함으로써 효율적인 탐색이 가능하게 되었으니 사용성을 높였다고 평가할 수 있습니다. ‘검색 인풋-아이디 인풋-비밀번호 인풋-로그인 버튼’ 탐색이 끝나면 포커스는 페이지에서 가장 처음 등장하는 a, area, button, input, object, select, textarea 요소를 찾고 그 이후로는 순차적으로 웹 페이지를 탐색할 것입니다.

tabindex, 키보드 접근 순서를 보완한 사례.

tabindex가 접근성을 높여준다는 오해가 있는데 완전히 잘못된 상식입니다. 만약 여러분이 사용성을 높이기 위한 목적이 아니라 HTML의 접근 순서를 보완하기 위하여 tabindex를 사용했다면 그것은 여러분의 HTML이 논리적인 순서로 마크업 되지 않았다는 것을 반증하는 것입니다. HTML의 마크업 순서가 논리적으로 작성되었다면 tabindex 속성은 애시당초 필요하지 않습니다. 심지어 tabindex 속성은 HTML 스펙에서 사라지더라도 전혀 문제가 없는 속성이라고 생각합니다. 빈번하게 발견되는 예를 한번 들어 보겠습니다.

다음과 같이 table을 이용하여 로그인 서식을 배치하는 경우 키보드 접근 순서는 ‘아이디 인풋-로그인 버튼-비밀번호 인풋’이 됩니다. 이 순서는 HTML 마크업 순서에 따라 발생하는 순서로써 논리적이라고 보기 어려운 순서 입니다. 

HTML 코드를 보면 왜 이런 순서로 탐색이 되는지 알 수 있습니다.

<TABLE border=1>
     <TBODY>
          <TR>
               <TH scope=row><LABEL for=uid>아이디 :</LABEL></TH>
               <TD><INPUT id=uid></TD>
               <TD rowSpan=2><INPUT value=로그인 type=submit></TD>
          </TR>
          <TR>
               <TH scope=row><LABEL for=upw>비밀번호 :</LABEL></TH>
               <TD><INPUT id=upw value="" type=password></TD>
          </TR>
     </TBODY>
</TABLE>


로그인 버튼은 병합된 첫 번째 행의 세 번째 컬럼에 포함되기 때문에 아이디 인풋 다음으로 포커스를 받게 됩니다. 비밀번호를 작성하지 않은 상태로 로그인 하도록 유도하는 상황 입니다. 문제는 웹 페이지 저작자들이 이 문제를 해결하기 위하여 table을 걷어내지 않고 ‘아이디, 비밀번호, 로그인’ 콘트롤에 tabindex 속성을 사용한다는 데 있습니다. 여기서 tabindex를 사용하게 되면 tab키는 다른 어떤 항목보다 로그인 서식을 먼저 탐색하게 됩니다. 이것이 의도한 경우라면 문제가 되지 않지만 만약 ‘로그인’ 서식이 아니고 웹 페이지에서 가장 먼저 탐색이 되어야 하는 콘텐츠가 아니라면 어떨까요? 어설프게 tabindex를 사용한 다음 그 순서가 잘못 지정된 것을 바로잡지 않은 사례가 무척 많이 발견 됩니다. 또 그것을 그대로 복사해서 다른 곳에 아무 생각 없이 가져다 쓰는 사례도 많습니다. 이런 경우 tabindex가 접근성을 오히려 훼손하게 됩니다. 지금 당장 여러분이 제작한 웹 사이트를 찾아서 tabindex가 사용되었는지를 확인하고 접근 순서를 오히려 훼손하고 있지 않은지 테스트 해보세요.

tabindex 대신 HTML의 논리적인 구조를 바로잡아야.

테이블이 사용되지 않아야 할 곳에 테이블이 사용되었다면 테이블을 걷어내야 합니다. 위에서 예로 든 로그인 서식의 경우 적어도 th 요소가 있기 때문에 table이 의미에 맞지 않는다고 보기는 어렵습니다. 단지 논리적인 구조를 갖지 못할 뿐이죠. 그러나 table을 걷어낸다면 적어도 tabindex를 사용하지 않아도 될 것입니다. 매우 치밀하게 사용하고 관리하지 않는다면 tabindex를 사용하는 것은 여러분의 웹 사이트에 땜빵질을 하는 것과 같습니다. 땜빵하는 방법 대신 얼개를 바꾸기를 강력하게 권장 합니다

Posted by Jake Kim