1. Ajax를 사용하는 주요 이유
1. 적절한 Ajax 애플리케이션을 통해 더 나은 사용자 경험을 달성하기 위해
2. 서버가 부담하는 이전 작업 중 일부를 클라이언트로 전송하여 클라이언트의 유휴 처리 능력에 도움이 되고 서버를 줄이기 위해 및 대역폭 부담을 줄여 ISP의 공간 및 대역폭 임대 비용을 절감한다는 목적을 달성합니다.
2. 인용문
Ajax 개념의 최초 제안자인 Jesse James Garrett은 Ajax가 Asynchronous JavaScript 및 XML의 약어라고 믿습니다. Ajax는 새로운 언어나 기술이 아닙니다. 실제로는 공통 공동 작업에서 각각의 역할을 수행하기 위해 여러 기술이 결합되어 있습니다.
· XHTML 및 CSS를 사용하여 프레젠테이션 표준화 ·
동적 디스플레이 및 상호 작용 실현;
·데이터 교환 및 처리를 위해 XML 및 XSLT를 사용합니다.
·비동기 데이터 읽기를 위해 XMLHttpRequest를 사용합니다.
·마지막으로 모든 데이터를 바인딩하고 처리하기 위해 JavaScript를 사용합니다.
Ajax의 작동 원리는 사용자 작업을 비동기적으로 만들기 위해 생성됩니다. 서버 응답은 비동기식입니다. 모든 사용자 요청이 서버에 제출되는 것은 아닙니다. 일부 데이터 확인 및 데이터 처리는 Ajax 엔진 자체에 맡겨집니다. 서버에서 새 데이터를 읽어야 한다고 판단되는 경우에만 Ajax 엔진이 서버에 요청을 제출합니다. 그것을 대신하여.
3. 개요
Garrent는 Ajax 구성 기술 7가지를 나열했지만 개인적으로 소위 Ajax의 핵심은 JavaScript, XMLHTTPRequest, DOM뿐이라고 생각합니다. 사용하는 데이터 형식이 XML이라면 XML도 추가할 수 있습니다(Ajax는 서버 측에서 시작). 데이터는 XML 형식이거나 텍스트와 같은 다른 형식일 수 있습니다.
이전 상호 작용 방법에서는 사용자가 서버에 대한 HTTP 요청을 트리거하고 서버는 이를 처리한 다음 서버가 클라이언트가 제출한 요청을 처리할 때마다 클라이언트에 유휴 상태만 기다릴 수 있습니다. 그리고 비록 작은 상호작용이고 서버에서 간단한 데이터 조각만 가져오면 완전한 HTML 페이지가 반환되어야 하고 사용자는 매번 전체 페이지를 다시 읽으느라 시간과 대역폭을 낭비해야 합니다. .
Ajax를 사용한 후 사용자는 페이지 새로고침(흰색 화면)을 기다리지 않고 거의 모든 작업이 빠르게 응답한다고 느낍니다.
1. XMLHTTPRequest
Ajax의 가장 큰 기능 중 하나는 페이지를 새로 고치지 않고(새로 고침 없이 페이지를 업데이트라고도 함) 서버에 데이터를 전송하거나 읽고 쓸 수 있다는 것입니다. 이 기능은 주로 XMLHTTP 구성 요소인 XMLHTTPRequest 객체의 이점을 활용합니다. 이런 방식으로 데스크탑 애플리케이션은 매번 인터페이스를 새로 고치거나 매번 데이터 처리 작업을 서버에 제출할 필요 없이 서버와 데이터만 교환할 수 있습니다. 이는 서버의 부하를 줄일 뿐만 아니라 처리 시간도 단축시킵니다. .응답속도가 빨라지고 사용자 대기시간이 단축됩니다.
Microsoft는 XMLHTTP를 최초로 적용했습니다. IE(IE5 이상)는 개발자가 웹 페이지 내에서 XMLHTTP ActiveX 구성 요소를 사용할 수 있도록 하여 기능을 확장합니다. 개발자는 현재 웹 페이지에서 탐색하지 않고도 서버에서 직접 데이터를 전송하거나 서버에서 데이터를 검색할 수 있습니다. . 이 기능은 상태 비저장 연결의 고통을 줄이는 데 도움이 되고 중복 HTML을 다운로드할 필요성을 제거하여 프로세스 속도를 높일 수 있기 때문에 중요합니다. Mozilla(Mozilla 1.0 이상 및 NetScape 7 이상)는 상속된 자체 XML 프록시 클래스인 XMLHttpRequest 클래스를 생성하여 응답했습니다. Konqueror(및 KHTML 기반 브라우저인 Safari v1.2)도 XMLHttpRequest 개체를 지원하며 Opera는 v7.6x+ 및 이후 버전에서도 XMLHttpRequest 개체를 지원합니다. 대부분의 경우 XMLHttpRequest 객체는 XMLHTTP 구성 요소와 매우 유사하며 소수의 속성이 지원되지 않는다는 점을 제외하면 메서드와 속성도 유사합니다.
XMLHttpRequest 적용:
·JS에서 XMLHttpRequest 객체 적용
var xmlhttp = new XMLHttpRequest()
·JS에서 Microsoft의 XMLHTTP 구성 요소 적용
var xmlhttp = new ActiveXObject(Microsoft.XMLHTTP)
var xmlhttp = new ActiveXObject(Msxml2.XMLHTTP);
XMLHttpRequest 객체 메서드
/**
* 크로스 브라우저 XMLHttpRequest 인스턴스화.
*/
if (typeof XMLHttpRequest == 'undefine') {
XMLHttpRequest = function () {
var msxmls = ['MSXML3', 'MSXML2', 'Microsoft']
for ( var i=0; i < msxmls.length; i++) {
try {
return new ActiveXObject(msxmls[i]+'.XMLHTTP')
} catch (e) { }
}
throw new Error("XML 구성 요소가 설치되지 않았습니다!")
}
}
function createXMLHttpRequest() {
try {
// "Mozilla 방식"으로 생성하려고 시도합니다.
if (window.XMLHttpRequest) {
return new XMLHttpRequest()
}
// 추측컨대 - 이제는 IE 방식입니다.
if (window.ActiveXObject ) {
return new ActiveXObject(getXMLPrefix() + ".XmlHttp")
}
}
catch (ex) {}
return false
};
XMLHttpRequest 객체 메서드
| 메서드 | 설명 |
| abort() | 현재 요청을 중단합니다. |
| getAllResponseHeaders() | 전체 헤더를 문자열로 반환합니다. |
| getResponseHeader("headerLabel") | 단일 헤더 레이블을 문자열로 반환합니다. |
| open("method","URL"[,asyncFlag[ , "userName"[, "password"]]]) | 대기 중인 요청의 대상 URL, 메소드 및 기타 매개변수 설정 |
| send(content) | 요청 보내기 |
| setRequestHeader("label", "value") | 헤더 설정하여 함께 보내기 요청 |
XMLHttpRequest 객체 속성
| 속성 | 설명 |
| 상태 변경을 | 위한 |
| ReadyState를 | |
| 개체 상태(정수): 0 = 초기화되지 않음 1 = 읽기 2 = 읽기 3 = 상호작용 4 = | |
| responseText 서버 프로세스가 반환한 데이터의 텍스트 버전을 | 완성합니다. |
| responseXML | 서버 프로세스가 반환한 DOM 호환 XML 문서 개체입니다 | .
| 예 | : 404 = "파일을 찾을 수 없음", 200 = |
| statusText | 서버에서 반환된|
| "성공" |
2. JavaScript
JavaScript는 브라우저에서 널리 사용되는 프로그래밍 언어로 과거에는 나쁜 언어로 폄하되었으며(실제로 사용하기 지루함) 일부 언어에서는 자주 사용됩니다. 화려한 장치와 장난 또는 지루한 양식 확인을 위한 것입니다. 그러나 사실은 이것이 실제 프로그래밍 언어이고 자체 표준을 갖고 있으며 다양한 브라우저에서 널리 지원된다는 것입니다.
3. DOM
문서 개체 모델.
DOM은 HTML 및 XML 파일용 API 세트입니다. 파일의 구조적 표현을 제공하여 내용과 가시성을 변경할 수 있습니다. 그 본질은 웹 페이지와 스크립트 또는 프로그래밍 언어 사이에 통신 브리지를 구축하는 것입니다.
웹 개발자가 조작하고 파일을 생성할 수 있는 모든 속성, 메소드 및 이벤트는 객체로 표시됩니다(예: 문서는 "파일 자체" 객체를 나타내고, 테이블 객체는 HTML 테이블 객체를 나타냅니다). 이러한 개체는 오늘날 대부분의 브라우저에서 스크립트를 통해 액세스할 수 있습니다.
HTML 또는 XHTML로 구축된 웹 페이지는 구조화된 데이터 집합으로 간주될 수도 있습니다. 이 데이터는 DOM(Document Object Model)에 포함되어 있으며 웹 페이지의 다양한 개체를 읽고 쓸 수 있도록 지원합니다.
4. XML
Jesse James Garrett이 언급한 Ajax 엔진은 실제로 사용자 요청을 처리하고, 서버를 읽고 쓰고, DOM 콘텐츠를 변경하는 데 사용되는 비교적 복잡한 JavaScript 애플리케이션입니다.
JavaScript의 Ajax 엔진은 정보를 읽고 대화식으로 DOM을 다시 작성합니다. 이를 통해 웹 페이지를 원활하게 재구성할 수 있습니다. 즉, 페이지가 다운로드된 후 페이지 내용을 변경할 수 있습니다. 그러나 웹 페이지를 정말로 동적으로 만들려면 내부 상호 작용뿐만 아니라 외부로부터의 데이터 수집도 필요합니다. 과거에는 사용자가 DOM을 통해 데이터를 입력하고 웹 페이지의 내용을 변경할 수 있었지만 이제는 XMLHTTPRequest가 허용됩니다. 페이지를 다시 로드하지 않고도 서버에서 데이터를 읽고 쓸 수 있어 사용자 입력이 최소화됩니다.
XML 기반 네트워크 통신은 새로운 것이 아닙니다. 실제로 FLASH와 JAVA 애플릿 모두 좋은 성능을 발휘했습니다. 이제 이러한 종류의 풍부한 상호 작용은 표준화되고 널리 지원되는 기술을 기반으로 하며 플러그인이 필요하지 않습니다. 또는 플러그인을 다운로드하세요.
Ajax는 전통적인 웹 애플리케이션을 변형한 것입니다. 과거에는 서버가 매번 HTML 페이지를 생성하여 클라이언트(브라우저)에 반환했습니다. 대부분의 웹사이트에서는 구조, 형식, 머리글, 바닥글, 광고 등과 같은 많은 페이지의 최소 90%가 동일합니다. 유일한 차이점은 콘텐츠의 작은 부분이지만 서버가 모든 반환을 생성할 때마다 클라이언트에게 페이지는 사용자의 시간이든, 대역폭이든, CPU 소비이든, ISP가 높은 가격에 임대한 대역폭과 공간이든 눈에 보이지 않는 낭비입니다. 페이지 단위로 계산하면 몇 K, 수십 K만 있어도 별로 인상적이지 않을 수 있지만, 매일 수백만 페이지를 생성하는 SINA 같은 대형 ISP의 경우 엄청난 손실이라고 할 수 있다. AJAX는 클라이언트와 서버 사이의 중간 계층 역할을 하여 클라이언트의 요청을 처리하고 필요에 따라 서버에 요청을 보낼 수 있으므로 사용량과 사용량을 알 수 있으므로 중복성 및 데이터 낭비가 없습니다. ., 다운로드되는 전체 데이터 양이 줄어들고, 페이지를 업데이트할 때 전체 콘텐츠를 다시 로드할 필요가 없습니다. 업데이트가 필요한 부분만 업데이트할 수 있습니다. 표준화되고 널리 지원되는 기술을 기반으로 하며, 플러그인이나 다운로드된 애플릿이 필요하지 않아 시간이 단축되고 리소스 낭비가 최소화되므로 Ajax는 사용자와 ISP 모두에게 win-win입니다.
Ajax는 WEB에서 인터페이스와 애플리케이션을 분리합니다. (데이터와 프리젠테이션을 분리했다고도 할 수 있습니다.) 과거에는 둘 사이에 명확한 경계가 없었습니다. 비기술 인력이 페이지와 상호 작용할 필요성이 줄어들고 수정으로 인해 WEB 응용 프로그램 오류가 발생하고 효율성이 향상되며 현재 게시 시스템에 더 적합합니다. 또한 서버에서 부담했던 이전 작업 중 일부를 클라이언트로 전송할 수도 있는데, 이는 클라이언트의 유휴 처리 능력에 도움이 됩니다.
4.
Ajax 개념 적용의 등장은 새로고침 없이 페이지를 업데이트하는 시대의 서막을 열었고, 전통적인 웹 개발에서 폼(form) 제출의 사용을 웹페이지 업데이트를 위해 대체하는 경향이 있다고 볼 수 있다. 이정표로. 하지만 Ajax는 모든 곳에 적용 가능한 것은 아니며, 특성에 따라 적용 범위가 결정됩니다.
애플리케이션 예제는 계단식 메뉴를 위한 Ajax 애플리케이션입니다.
기존의 계단식 메뉴 처리는 다음과 같았습니다.
메뉴의 각 작업으로 인해 페이지가 다시 로드되는 것을 방지하기 위해 매번 배경을 호출하는 방법을 사용하지 않고 계단식 메뉴의 모든 데이터를 한 번에 읽어 들였습니다. 배열에 기록한 다음 JavaScript를 사용하여 사용자 작업에 따라 항목 하위 집합의 표시를 제어합니다. 이렇게 하면 페이지를 다시 로드하지 않고 서버에 대한 빈번한 요청을 피하면서 작업 응답 속도 문제를 해결할 수 있습니다. 사용자가 메뉴에 반응하지 않거나 메뉴의 일부만 조작하면 읽은 데이터 중 일부가 중복된 데이터가 되어 사용자의 자원을 낭비하게 되며, 특히 메뉴 구조가 복잡하고 데이터의 양이 많은 경우에는 더욱 그렇습니다. 예를 들어 메뉴에는 레벨이 많고 각 레벨에는 수백 개의 항목이 있습니다.) 이러한 단점은 더욱 두드러집니다.
이 경우 Ajax를 적용하면 결과가 향상됩니다.
페이지를 초기화할 때 첫 번째 수준의 모든 데이터만 읽어서 표시합니다. 사용자가 첫 번째 수준 메뉴 항목 중 하나를 조작하면 결과가 표시됩니다. 백그라운드에서는 현재 1단계 항목이 속한 2단계 하위 메뉴의 모든 데이터를 요청합니다. 이미 표시된 2단계 메뉴의 항목을 계속 요청하면 모든 항목을 요청합니다. 조작된 2차 메뉴 항목에 해당하는 모든 3차 메뉴의 데이터 등... 이렇게 하면 필요한 만큼 얻을 수 있으며 중복이나 낭비가 없습니다. 전체 데이터 다운로드량을 줄이고, 페이지 업데이트 시 전체 내용을 다시 로드할 필요 없이 업데이트가 필요한 부분만 업데이트하면 됩니다. 백그라운드 처리 및 다시 로드에 비해 사용자의 대기 시간이 단축됩니다. 그리고 자원 낭비를 최소화합니다.
또한 Ajax는 외부 데이터를 호출할 수 있기 때문에 Microsoft가 3월 15일에 출시한 온라인 RSS 리더의 베타 버전과 같이 데이터 집계 기능(물론 해당 인증 포함)도 실현할 수 있습니다. 일부 공개 데이터 개발 Amazon의 데이터를 사용하는 일부 새로운 도서 검색 애플리케이션과 같은 자체 애플리케이션 중 일부입니다.
간단히 말해서, Ajax는 상호 작용이 많고, 데이터를 자주 읽고, 데이터 분류가 잘 되는 WEB 애플리케이션에 적합합니다.
1. 서버의 부담을 줄여줍니다. Ajax의 기본 개념은 "요청 시 데이터 가져오기"이므로 중복 요청으로 인한 부담과 서버에 미치는 영향을 최대한 줄일 수 있습니다.
2. 새로 고침 없이 페이지를 업데이트하여 사용자의 실제 및 심리적 대기 시간을 줄입니다.
먼저, "를 누르십시오. "데이터 필수" 모드는 실제로 읽혀지는 데이터의 양을 줄입니다. 매우 생생한 비유를 하자면, 오버로딩 방법이 한 끝점에서 원점으로 되돌아간 다음 다른 끝점으로 돌아가는 것이라면 Ajax는
두번째로
, 상대적으로 큰 데이터를 읽으려는 경우에도 Ajax는 XMLHTTP를 사용하여 서버 응답 데이터를 다시 로드하지 않고 요청을 보내기 때문에 RELOAD와 같은 흰색 화면이 필요하지 않습니다. 전체 페이지에서 Javascript를 사용하여 DOM을 작동하고 최종적으로 페이지를 업데이트하므로 데이터를 읽는 동안 사용자는 흰색 화면이 아닌 원래 페이지 상태를 보게 됩니다(또는 LOADING 프롬프트 상자를 추가하여 사용자는 데이터 읽기 프로세스 상태를 이해합니다) 모든 데이터가 수신된 경우에만 콘텐츠의 해당 부분이 업데이트되며 이 업데이트도 즉각적이고 사용자가 거의 감지할 수 없습니다. 한마디로 사용자는 매우 예민한 존재이기 때문에 즉각적인 결과를 얻을 수는 없지만 사용자의 마음속에는 웹사이트에 대한 의존도가 조금씩 쌓이게 됩니다.
3. 더 나은 사용자 경험.
4. 또한 서버가 부담한 이전 작업 중 일부를 클라이언트로 전송할 수 있으며, 이를 클라이언트의 유휴 처리 능력으로 사용할 수 있어 서버와 대역폭에 대한 부담을 줄이고 공간과 대역폭을 절약할 수 있습니다.
5, Ajax는 외부 데이터를 호출할 수 있습니다.
6.
표준화되고 널리 지원되는 기술을 기반으로 하며 플러그인이나 다운로드된 애플릿이 필요하지 않습니다.
7. Ajax는 웹에서 인터페이스와 애플리케이션을 분리합니다. 데이터와 프리젠테이션을 분리한다고 함)
8. 사용자와 ISP 모두에게 win-win 상황입니다.
6. Ajax의 문제점
1. 일부 휴대용 장치(휴대폰, PDA 등)는 아직 Ajax를 제대로 지원하지 않습니다.
2. JavaScript, JavaScript 호환성 및 DeBugs로 만들어진 Ajax 엔진은 골칫거리입니다.
3. Ajax는 새로 고침되지 않습니다. 새로 고침: 페이지 변경 사항이 새로 고침 새로 고침만큼 명확하지 않기 때문에 사용자에게 문제를 일으키기 쉽습니다. 사용자는 현재 데이터가 새로운 것인지 또는 업데이트되었는지 확실하지 않습니다. 기존 솔루션에는 다음이 포함됩니다. 관련 위치 프롬프트 및 데이터 업데이트 영역은 더욱 명확하게 설계되었으며 데이터 업데이트 후 사용자에게 메시지가 표시됩니다.
4. 스트리밍 미디어에 대한 지원은 FLASH 및 Java Applet만큼 좋지 않습니다.