'Javascript'에 해당되는 글 112건

  1. 2014.01.25 책 "DOM을 깨우치다" 정리노트 :: Node 개요
  2. 2013.09.10 JS 객체 설계 시 This를 반환하는 이유.
  3. 2013.05.27 JavaScript로 구현한 MVC 패턴
  4. 2013.05.27 JavaScript로 구현한 MV 패턴 2
  5. 2013.05.09 얼마 전 그룹에 올라온 글을 보고...
  6. 2013.05.07 보수(음수 표현 방법)에 대한 포스트를 읽고...
  7. 2013.04.20 카카오 톡 / 카카오 스토리 API 활용하기(모바일웹 기준) 1
  8. 2013.03.05 jQuery .HTML() 메서드 구현
  9. 2013.02.25 Hash List 모듈 사용 방법
  10. 2012.11.12 Javascript NonBlocking I/O

책 "DOM을 깨우치다" 정리노트 :: Node 개요





DOM 정의:


- Dom(Document Object Model)은 웹 서버를 통해 내려받은 "HTML" 코드를 브라우저가 해석 후 JavaScript 객체를 통해 계층화한 구조체(의미상(트리 구조))를 의미한다.



구조체란?: http://ko.wikipedia.org/wiki/Struct





DOM 목적:


- JavaScript를 통해 문서(HTML, XHTML, XML 등)의 각 요소들을 핸들링하기 위한, 프로그래밍 인터페이스를 제공한다.






DOM 트리:


- HTML 문서의 각 요소들은 가장 오른쪽 패널에서와 같이 브라우저에 의해 해석된 후, Javascript 객체(Object, Node 등)를 통해 계층화된 트리 구조로 변환된다.









또한, 브라우저를 통해 생성(해석 후)된 DOM에 대한 JavaScript 객체 상속 관계는 아래와 같다.





츨처: http://www.stanford.edu/class/cs98si/slides/the-document-object-model.html






DOM 상속 관계:



- 아래 그림의 상속 관계는 html 엘리먼트의 상속 관계를 나열한 것이며, 객체 상속의 시작은 최상위 조상인 Object.prototype 객체로 부터 참조가 시작된다.



1. EventTarget.prototype 객체는 Object 객체를 상속받아 확장한다.





2. Node 객체는 EventTarget 객체를 상속받아 확장한다.


3. DocumentType 객체는 Node 객체를 상속받아 확장한다.


정리하면, 아래와 같은 상속 관계가 만들어지며, DOM 상의 모든 ElementNode들은 아래 나열한 객체들을 상속받아 확장하게되는 것이다.


Object < EventTarget < Node < DocumentType < <!DOCTYPE html>(ElementNode)





또 다른 예로, html 요소를 클릭 시 아래 그림과 같은 상속 관계를 확인할 수 있다.




Object < EventTarget < Node < Element < HtmlElement < HtmlhtmlElement < html(ElementNode)






- 결국 아래 코드와 같이 html ElementNode상속(Object, EventTarget, Node, Element, HtmlElement, HTMLhtmlElement받은 모든 객체의 속성 및 메서드들을 사용할 수 있게되는 것이다.



특히, 상속받는 객체 중 하나인 Node 객체는 DOM을 조작, 조사, 탐색하는 기준이 되는 많은 속성 및 메서드들을 정의하고 있다.




결과:







JS 객체 설계 시 This를 반환하는 이유.



보통 JS 객체 설계 시 특정 함수의 반환 값으로 this 를 반환하는 경우는, 말그대로 현재 Context 유지하기 위함이다.


즉, JS 패턴 중 하나인 "Method Chaining" 패턴을 구현하기 위해 쓰인다.


그러므로 인스턴스를 생성하기 위한 a, b Class 함수 상 에는 구지 필요하지 않지만,(들어가도 크게 상관은 없다.) "Method Chaining" 패턴을 구현하기 위해선, a.setName 메서드 상에 반드시 현재 Context를 반환하기 위한 코드인 "return this" 필요하다.




- 위 코드의 결과는 아래와 같다.


1. a Class 함수 a.setName 메서드 상에 현재 Context를 반환하기 위한 코드인 "return this" 가 없으므로 Method Chaining 이 구현되지 않았다.(그로인해 getName 메서드 호출 시 메서드가 정의 되지 않았다는(undefined) 오류가 발생하게 된다.)

2. b Class 함수 b.setName 메서드 상에 현재 Context를 반환하기 위한 코드인 "return this" 가 존재 하므로 "Method Chaining" 구현 되었다.(그로인해 getName 메서드 호출 시 오류가 발생하지 않고 해당 Function을 반환하게 된다.)




JavaScript로 구현한 MVC 패턴




1. MVC 패턴이란?



MVC 패턴이란 하나의 어플리케이션을 크게 Model, View, Controller이라는 세 영역으로 구분하고 각 영역간의 코드 결합도를 최소화 시키는 개발 패턴 중 하나이다.


- 다시말해 패턴의 주요 목적은 Model과 View 영역간의 코드 결합도를 최소화 시키는데 있다고 볼 수 있다.







2. 영역간의 역활 정의



Model: 어플리케이션에 비지니스 로직과 사용되는 데이터를 다루는 영역이다.


- 보통 비지니스 로직에 필요한 데이터는 해당 DB에 의해 관리되고, 그 데이터를 다루는 연산은 SQL 문법을 통해 구현된다.


View: 최종 사용자에게 보여줄 프리젠테이션 로직을 담당하는 영역이다.


- 웹으로 말하자면 정적 리소스로는 HTML, 동적 리소스로는 ASP, PHP, JSP 등의 파일로 나뉠 수 있다.


Controller: 기존 MV 패턴에서 View가 맡아하던 Model 영역과의 일부 로직들을 Controller 영역으로 대체하여, Model과 View 영역간의 코드 결합도를 줄여주는 영역이다.(결국 패턴의 궁극적인 목적을 이루기 위한 가장 중요한 영역이라고 볼 수 있다.)








3. 영역간의 진행 순서







사진출처: http://cheucheu.tistory.com/48





- 이전 MV 패턴과는 상대적으로 복잡한 구조를 지닌 것을 것을 볼 수 있으며, 패턴에 대한 진행 순서은 아래와 같다.




1. Client(최종 사용자)가 특정 Controller 영역을 호출한다.


2. 요청받은 Contoller 영역은 특정 Model 영역의 비지니스 로직을 호출해 그에 대한 수행 결과(보통 DB 연동을 통한 데이터들의 집합이다)를 반환받는다.


3. Controller는 Model 영역을 통해 반환받은 데이터들의 집합을, 특정 View를 호출해 클라이언트에게 응답(제공)할 UI를 만들도록 한다.




- 패턴 진행 순서: Controller >> Model >> Controller >> View





- 장점: 


1. 어플리케이션 유지보수 시 비지니스 로직에 대한 변경 사항이 많은 경우 추가되는 개발 비용이 현저히 내려간다.(Contoller 영역을 통해 Model과 View 영역간의 코드 결합도를 현저히 낮춤으로써 Model 영역의 비지니스 로직 변경 시 해당하는 View 영역의 변경 사항이 줄어든다.(하지만 이는 아래 단점에서도 볼 수 있듯이 Controller 영역을 어떻게 설계하느냐에 따라 크게 달라질 수 있는 부분이기도 하다.))



2. Contoller 영역을 통해 전체 어플리케이션 코드 관리가 용이해진다.(이는 위 장점과 마찬가지로 유지보수 시에 대한 또 다른 장점이며, 결국 이 또한 Model과 View 영역간의 코드 결합도를 낮춤으로써 나타나는 결과이다.)




- 단점: 


1. 이전 MV 패턴과는 달리 좀더 복잡한 개발 구조를 통해 초기 개발 비용이 올라간다.(단순히 생각해도 이전에 없었던 Contoller 영역의 추가로 인해 초기 개발 비용이 상승하는것은 너무도 당연한 일이다.  다시말해 영역들간의 좀더 세밀한 역활 분기로 인해 설계 및 작성해야 할 코드량이 많아진다는 것이다.)



2. 앞서 말했듯이 MVC 패턴의 복잡한 아키텍처로 인해 각 영역에 대한 재 사용성은 이전 MV 패턴에 비해 많은 부분 좋아졌지만, 그 만큼 새롭게 추가되는 Contoller 영역의 역활이 중요해졌으며, 만약 개발이 잘 못 되었을 경우 어플리케이션 전체에 미치는 악 영향이 매우 커질 수 있다.








4. JavaScript로 구현한 MVC 패턴의 예



- 화면 UI는 이전 MV 패턴과 동일하며, 아래 작성된 패턴에 대한 설명은 코드 상 주석으로 표기하였다.








참고 사이트:


MVC(Model / View / Controler) 패턴:

http://blog.naver.com/yellobox62?Redirect=Log&logNo=80048634644





JavaScript로 구현한 MV 패턴





1. MVC 패턴이란?


MVC 패턴이란 하나의 어플리케이션을 크게 Model, View, Controller이라는 세 영역으로 구분하고 각 영역간의 코드 결합도를 최소화 시키는 개발 패턴 중 하나이다.


- 다시말해 패턴의 주요 목적은 Model과 View 영역간의 코드 결합도를 최소화 시키는데 있다고 볼 수 있다.






2. 영역간의 역활 정의



Model: 어플리케이션에 비지니스 로직과 사용되는 데이터를 다루는 영역이다.


- 보통 비지니스 로직에 필요한 데이터는 해당 DB에 의해 관리되고, 그 데이터를 다루는 연산은 SQL 문법을 통해 구현된다.


View: 최종 사용자에게 보여줄 프리젠테이션 로직을 담당하는 영역이다.


- 웹으로 말하자면 정적 리소스로는 HTML, 동적 리소스로는 ASP, PHP, JSP 등의 파일로 나뉠 수 있다.


Controller: 이 포스트에서 다루는 코드들은 MV 패턴으로만 구현할 것이기에 이번 포스트에서는 Controller 영역은 설명하지 않겠다.






3. 영역간의 진행 순서




사진출처: http://cheucheu.tistory.com/48




- 위 그림은 초기 웹 개발 시(하지만 현재도 많이 사용되고 있는 개발 패턴 중 하나이다) 많이 사용되던 패턴이며, 패턴에 대한 진행 순서은 아래와 같다.




1. Client(최종 사용자)가 특정 View(HTML, ASP, PHP, JSP) 영역을 호출한다.


2. 요청받은 View 영역은 특정 Model 영역의 비지니스 로직을 호출해 그에 대한 수행 결과(보통 DB 연동을 통한 데이터들의 집합이다)를 반환받는다.


3. Model 영역을 통해 반환받은 데이터를 가공하여, 클라이언트에게 응답(제공)할 UI를 생성한다.



패턴 진행 순서: View >> Model >> View




- 장점: 프로젝트 유지보수 시 비지니스 로직에 대한 변경 사항이 많지 않은 경우 개발 비용이 상대적으로 적게든다.(사실 아무리 작은 프로젝트라 하더라도 이런 경우는 흔하지 않다.)


- 이 말은 View에 대한 특정 컨트롤을 따로 작성할 필요가 없으므로 상대적인 개발 비용이 적게 든다는 말과 같다.(단 이는 MVC 패턴에 대한 상대적 예라는 것을 염두해야 한다.)

 


- 단점: View와 Model 영역간의 결합도가 상당히 높아 View 영역의 재활용성이 떨어진다.(Model 상의 비지니스 로직 변경 시(프로그램 설계 변경/추가/삭제 시) 그것들을 호출하는 각 View의 프리젠테이션 로직들을 전부 수정해야한다.)






4. JavaScript로 구현한 MV 패턴의 예


- 아래 작성된 패턴에 대한 설명은 코드 상 주석으로 표기하였다.






참고 사이트:


MVC 패턴이란?


http://cheucheu.tistory.com/48


http://blog.loveciel.kr/58





얼마 전 그룹에 올라온 글을 보고...




얼마 전 활동 중인 그룹(undefinedD)에 새롭게 올라온 글을 본 후 JS 생성 패턴에 대해 나름 다시한번 정리해 보는 시간을 가졌다.





먼저 아래는 그룹에 올라온 글에 대한 전문이다.








1. JQuery 객체 생성 패턴



- 아래는 실제 JQuery 코드 상에서 사용되고 있는 객체 생성 패턴의 예이다. 하지만 이와 같은 생성 패턴은 JS Prototype 순환 참조로 인해 포함되지 않아야 할 메서드($.init(name))가 포함되는 문제가 존재한다.



var $ = (function(){


    var $ = function(name){

        return new $.fn.init(name);
    }


    $.fn = $.prototype = {

        init: function(name){
            
            name = name || '';

            this.name = name;

            return this;
        },
        getName: function(){
            return this.name;
        }

    }

    $.fn.init.prototype = $.prototype;

    return $;

}());


console.log('A: ' + $('mohwa').init); // init function
console.log('A: ' + $('mohwa').getName()); // mohwa






2. 수정된 객체 생성 패턴 


- 아래 생성 패턴은 위 JQuery 생성 패턴문제($.init(name) 메서드가 포함되는) 해결하였다.


var $ = (function(){


    var $ = function(name){

        return new init(name);
    }


    function init(name){

        name = name || '';

        this.name = name;

        return this;
    }

    init.prototype.getName = function(){

        return this.name;
    }



    return $;

}());


console.log('B: ' + $('mohwa') === $('mohwa')); // false
console.log('B: ' + $('mohwa').init); // undefined(이전 패턴과 달리 $.init(name) 메서드가 존재하지 않는다.)
console.log('B: ' + $('mohwa').getName()); // mohwa





3. 생성자 + 싱글톤 패턴


- 위 생성자 패턴에 싱글톤 패턴을 추가 하였다.



var $ = (function(){

    // 싱글톤을 위한 인스턴스 private 변수

    var instance = null;

    var $ = function(name){

        return new init(name);
    }


    function init(name){

        name = name || '';

        this.name = name;

        // 싱글톤 패턴
        return instance = instance ? instance : this;
    }

    init.prototype.getName = function(){

        return this.name;
    }



    return $;

}());


console.log('C: ' + $('mohwa') === $('mohwa')); // true
console.log('C: ' + $('mohwa').getName());





4. 객체 생성자(Class)를 강제 시킨다.


instanceof 연산자를 통해 객체 생성자 함수($(name))를 강제 시키는 코드를 추가시킨 패턴이다.




var $ = function(name){

    name = name || '';

    var _this;
    if (!(this instanceof $)) _this = new $(name);
    else _this = this;

    _this.name = name;

    return _this;

};

var $$ = function(){

}

console.log('D: ' + $.call(new $$(), 'mohwa').name); // fn.call(context, arguments) 메서드를 사용해 호출한다.
console.log('D: ' + new $('mohwa').name);


보수(음수 표현 방법)에 대한 포스트를 읽고...


몇일 전 트위터에 피드된 보수에 대한 글을 읽고, 짧게 나마 정리 한번하고 넘어가자는 마음으로 이 포스트를 작성한다.




지금까지 적지않은 세월동안 프로그램을 작성하면서, 근간이 되는 내용(프로그램 상의 뺄샘 처리 과정)임에도 불구하고, 한번도 생각해 보지 않았던 내용이었기에, 작성된 포스트 글만 가지고는 쉽게 이해가 잘 가지않아, 아래 따로 첨부된 여러 자료들을 찾아보며, 이해한 내용을 아래와 같이 JavaScript 코드로 구현해 보았다.







참고 사이트:


보수란?

http://211.228.163.31/30stair/complement/complement.php?pname=complementrms


JavaScript 보수 계산기(간간히 오류가 존재한다.)

http://www.iwiz.pe.kr/bbs/view/webdev/article_51.html


N진법의 보수1

http://cms.kut.ac.kr/user/yjjang/dig12/ch02_radix.pdf


N진법의 보수2

http://www.havetop.com/xe/index.php?mid=publecture&page=7&sort_index=readed_count&order_type=asc&document_srl=2874




카카오 톡 / 카카오 스토리 API 활용하기(모바일웹 기준)




아래는 @카카오에서 서비스 중카카오 톡 / 카카오 스토리를 활용할 수 있도록 제공하는, API에 대한 소스 및 그에 대한 결과 이미지이다.






1. 카카오 톡



- URL 링크 전달 소스:



KAKAO.Talk.link('테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!', 'http://mohwa.org', 'APP Name');













- APP 링크 전달 소스:



var metainfo = { metainfo: [{ os: "android", devicetype: "phone", installurl: "market://details?id=kr.co.mobicle.SpecialForce2&feature=nav_result#?t=W10", executeurl: "kakaoagit://testtest" }, { os: "ios", devicetype: "phone", installurl: "items://itunes.apple.com/kr/app/seupesyeolposeudipenseu/id433594154?mt=8", executeurl: "kakaoagit://testtest"}] };

KAKAO.Talk.link('테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!', 'http://mohwa.org', 'APP Name', metainfo);














2. 카카오 스토리



- 텍스트 URL 포스팅 소스:



var urlinfo = { title: "(광해) 실제 역사적 진실은?", desc: "(광해 왕이 된 남자)의 역사성 부족을 논하다.", imageurl: ["http://m1.daumcdn.net/photo-media/201209/27/ohmynews/R_430x0_20120927141307222.jpg"], type: "article" 
}

KAKAO.Story.link('http://dfl.co.kr테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!', 'APP Name', urlinfo);









PS: 현재 모바일웹에서는 IOS, Android(네이티브 APP)에서 지원하는 이미지 포스팅은 지원하지 않는다.








3. API 가공 소스 코드









4. 참고 사이트:


카카오톡 API 테스트 페이지:

http://mohwa.org/html/kakao/kakao.html


카카오톡 API URL:

http://www.kakao.com/link/ko/api?tab=mobile


카카오 스토리 API URL:

http://www.kakao.com/link/ko/api_story?tab=mobile



jQuery .HTML() 메서드 구현




최근 작성 중인 JS에서 DB Call(Ajax)을 통해 받아온 데이터를 HTML과 함께 가공하여, 사용자로부터 전달된 특정 Element에 할당하는 로직을 구현해야 하는 일이 있었다.



해당 로직을 구현하기 위해 지금까지 DOM Manipulation(조작)을 위해 자주 사용해오던 속성인 innerHTML 속성을 사용해 구현하던 중 오랜만에 "멘붕"을 겪은 경험이 있어 아래와 같이 정리해보았다.





"멘붕"과 관련된 자세한 설명은 간단한 검색을 통해 많은 정보를 얻을 수 있으며, 아래 포스트를 참조하길 바란다.



1. tbody.innerHTML 안된다고?

http://findfun.tistory.com/entry/TIP-tbodyinnerHTML-%EC%9D%B4-%EC%95%88%EB%90%9C%EB%8B%A4%EA%B3%A0


2. Javascript Snippet - Tables and innerHTML

http://tech.pro/tutorial/1087/javascript-snippet-tables-and-innerhtml


3. DWR과 IE와 TBODY와 innerHTML과 협공

http://blog.iolo.kr/102





위 내용들을 간단히 정리하면, IE 브라우저타 브라우저(표준 브라우저(파폭, 사파리, 크롬))와 달리, 몇 가지 Element(Tbody, Table, HTML, COL 등)들의 메커니즘이 읽기 전용으로 되어있으며, 

그 엘리먼트들은 다른 엘리먼트와 달리 innerHTML 속성을 통해 사용자가 할당하려는 특정 HTMLString이 할당되지 않는다는 말이다.(하지만 jQuery.html(HTMLString) 메서드 사용 시 (IE / 비IE) 모두 완벽히 처리된다.)


하지만 현재 작성 중인 JS가 JQuery 라이브러리를 사용하지 않는 범위로 제작되고 있기에, 별도의 Html() 메서드를 따로 작성해야 했다.




아래는 별도로 작성된 Html() 메서드 소스이다.







Hash List 모듈 사용 방법



hlist.JS(Hash List) 적용 소스






1. 동작 원리




가장 먼저, 작성된 모듈의 기본이 되는 기능에 대해 설명하자면, 기존 URI의 #(해시) 기능인 앵커(anchor)를 응용한 기능이며, 보편적으로 아래와 같은 경우에 사용된다.




1.1 앵커 태그의 href 속성에 "#here" 문자열을 할당 시킨다.


1.2. 특정 태그(div)의 id 속성에 위 앵커 태그에 할당한 문자열을 동일하게 할당 시킨다.


1.3. 이와 같은 문서 환경이 구성되어 있는 경우, 해당 앵커의 기본 이벤트 발생 시 동일한 문자열로 할당된 특정 태그를 찾아 그 위치로 이동 시키는 기능을 사용할 수 있으며, 보통 사이트 가이드 문서의 목차 내용을 이동 시키는데 사용된다.




해당 기능은 아래 코드와 같이 구현된다.




<div id="here">there 영역!!</div>

<a href="#here">there 영역으로 가기!!!</a>



작성된 모듈(Hlist.js) 또한 데모 페이지에서 확인할 수 있듯이 위에서 설명한 #(해시) 기능을 응용한 방법이다.


- 제공되는 URI 형식이 아래와 같이 작성되는 이유는 기존 시멘틱한 URI 작성 방식을 최대한 손실시키지 않기 위함이다.



제공되는 URI 작성법:


http://mohwa.org/aspx/hlist/hlist.aspx?#list/page/5


: #(해시)list(proc)/page/5(parameters)








2. 적용에 따른 장 / 단점





장점: 


1. 페이지에 포함된 전체 리소스(정적 / 동적) 갱신없이(no reflash) 특정 영역의 데이터를 받아와 업데이트 하는 방식(+ajax)으로, 그에 따라 성능(네트웍 트래픽 감소, no reflash에 따른 페이지 로드 시간 감소 등..) 및 사용자 접근성이 향상 된다.



2. 방식 변경 후에도 사이트 기본 기능(북마크, 링크 공유, 검색엔진 인덱싱, 페이지 히스토리) 그대로 사용 가능하다.


즉 #(해시) 기능을 사용하는 가장 큰 이유는 전통적인 웹 사이트의 레가시(유산)를 깨뜨리지 않으려는 최소한의 절충한이라고 볼 수 있다.(HTML5 API의 pushState(Ajax History 관리) 기능은 아직까지 모든 브라우저에서 지원하지 않으므로(최신 표준 브라우저에서만 사용 가능) 기술 도입에 적당하지 않다.)



3. Cache 기능으로 정의된 CacheTimeout 안에는 DB Call을 하지않고 미리 적재된 캐쉬 데이터를 불러와 사용게 된다.






단점: 


1. 전체적으로 JS 기반인 기술이므로 JS 미 지원 브라우저에서는 동작하지 않는다



즉 그와 관련한 사용자 접근성 치명적인 단점이 존재한다. 


하지만 이를 대응하기 위한 방법이 존재하지 않는것은 아니다. 단, 개발 초입 시 이를 충분히 고려한 설계를 통해 미 지원 브라우저를 처리해야하며, 그에 따라 늘어나는 개발 비용은 충분히 고려해야할 부분이다.(기존 Form 태그의 Submit을 JS(form.submit())만을 이용한 설계(JS 미지원 브라우저에서는 동작하지 않는 설계)가 아닌 Submit(type="submit", type="image") 타입의 버튼 형식 및 Form 태그의 Onsubmit 이벤트를 통해 사용하는 방법을 떠올리면 이해가 빠를 듯 하다.)



또 다른 분기 처리 방법으로는 사이트 이원화를 생각해 볼 수 있다.

즉 JS 지원 여부에 따라 순수 HTML만으로도 동작하는 사이트로 리디렉션 해주는 방법이다.



2. JS 기반인 기술이므로 코드 상 작은 실수(JSON에서 콤마(,)를 찍지않는 작은 실수)로 인해 전체 웹 사이트가 망가질 리스크가 적지 않다.



3. 각종 "검색엔진"이 해당 사이트의 내용을 알기 위해 컨텐츠를 긁어가는 봇인 "크롤러"는 JS를 실행시키지 않으므로 #(해시) 기능으로 생성되는 사이트의 컨텐츠를 가져갈 수 없다.(비동기(ajax)를 사용한 컨텐츠 업데이트를 사용할 수 없기 때문)


즉 크롤러가 수집하는 페이지는 내용 없는 빈 페이지라는 얘기이다.







3. 적용 예제











4.  관련 사이트:



메뉴얼:

http://mohwa.org/doc/hlist/index.html


소스 페이지:

http://mohwa.org/aspx/hlist/hlist.js


데모 페이지(루리웹 페이지를 이용한 예제이며, 현재 페이징 기능 까지 구현되어 있다.)

http://mohwa.org/aspx/hlist/hlist.aspx?#list


URI(텀즈):

http://www.terms.co.kr/URI.htm


URL과 URI의 의미와 차이점: 

https://lael.be/480



Javascript NonBlocking I/O




Javascript Non-Blocking I/O




I/O란?


terms:

http://terms.co.kr/IO.htm


wiki:

http://ko.wikipedia.org/wiki/%EC%9E%85%EC%B6%9C%EB%A0%A5





Blocking I/O(동기 I/O): 요청한 I/O(DB, 파일, 네트웍 등..)가 완료될때까지 해당 Thread(Single, Multi)를 "대기 모드"로 돌렸다가 I/O 완료 후 유저 코드를 실행시킨다.



var ret1 = $.post('http://mohwa.org/html/defaultTest.html?type=DB');
	
// I/O가 완료된 후 대기중이었던 유저 코드(새로운 요청)가 실행된다.
var ret2 = $.post('http://mohwa.org/html/defaultTest.html?type=File');




NonBlocking I/O(비동기 I/O): 요청한 I/O의 완료 여부와 관계없이 바로 리턴해서 유저 코드가 계속 실행되도록 한다. 이때 유저 코드는 요청한 I/O가 완료(HTTP 응답 등과 같은...)될때까지 다른 사용자의 요청을 처리할 수 있다.



var ret1 = $.post('http://mohwa.org/html/defaultTest.html?type=DB', function(ret){
	// callback
	console.log('NonBlocking I/O callback pattern' + new Date().getTime());
});

// I/O 완료와 관계없이 바로 리턴되며, 유저 코드(새로운 요청)가 계속해서 실핸된다.
var ret2 = $.post('http://mohwa.org/html/defaultTest.html?type=File', function(ret){
	// callback
	console.log('NonBlocking I/O callback pattern' + new Date().getTime());
});



보통 "Single Thread" 방식 언어의 비동기 구현을 위해 Non-Blocking I/O 방식이 사용된다.(Node.js API 또한 이 방식으로 구현 되었다.)


하지만 이 방식을 사용(채택, 구현)하기 위해서는 기존 OS단에서 자동으로 처리되던 Thread 스위칭 작업일정 부분 유저 코드로 구현(비동기 처리)해야 한다는 부담이 존재한다.




* AJAX(XmlHttpRequest) API Node.js APINon-Blocking I/O 방식으로 구현되어 있다.






Non-Blocking I/O(비동기) 방식 도식화 이미지:







JQuery Ajax 관련 코드(Non-Blocking I/O 방식과 Callback Pattern 사용)


$.post('http://mohwa.org/html/defaultTest.html', function(ret){
console.log('NonBlocking I/O callback pattern' + new Date().getTime());
});




Non-Blocking I/O 방식이란?

http://drypot.tumblr.com/post/11175657085/node



prev 1 2 3 4 ··· 12 next