Archive for the ‘Ajax’ category

Newer Entries »

Bài 5: Các công nghệ trong AJAX - DOM - Tìm kiếm & Tạo DOM Node.

March 23rd, 2008

Tìm kiếm một DOM Node

Yêu cầu đầu tiên để làm việc trên DOM với JavaScript là đi tìm kiếm một phần tử để thay đổi. Trước hết cần bắt đầu tham chiếu qua nút gốc - root node, nút này thể hiện qua biến toàn cục document.

Mỗi nút trong DOM là một nút con (hoặc nút con cấp hai, ba…) của document, nhưng cứ đi dần vào cây DOM, sẽ thấy một tài liệu phức tạp được biểu diễn bởi DOM, và việc tìm kiếm là rất khó khăn.

Vì thế có các cách sau để tìm kiếm một nút nhanh chóng hơn. Mỗi phần tử HTML có một thuộc tính ID, ví dụ như,

Quote:

<p id=’hello’>

hay

Quote:

<div id=’empty’></div>

Mỗi một nút DOM có thể có một ID gán cho nó, và ID này có thể được dùng để tham chiếu tới nút qua hàm :

Quote:

var hello=document.getElementById(’hello’);


Trong một số trường hợp, cần duyệt qua cấu trúc cây từng bước một, mỗi nút DOM có một nút cha và nhiều nút con. Chúng có thể được truy cập bởi các thuộc tính parentNode và childNodes, thuộc tính parentNode trả về một đối tượng DOM node khác, trong khi childNodes trả về một mảng javascript:

Quote:

var children=empty.childNodes;
for (var i=0;i<children.length;i++){
…
}


Một cách khác để tìm kiếm là dựa trên loại thẻ HTML, dùng phương thức getElementsByTagName(). Ví dụ, document.getElementsByTagName("UL") sẽ trả về chuỗi tất cả các thẻ <UL> trong tài liệu.

 

 

Tạo DOM Node

Trong nhiều trường hợp cần tạo các nút mới và thêm nó vào tài liệu. JavaScript cung cấp một số phương thức để làm điều đó. Các phương thức chuẩn để tạo nút mới là document.createElement() và document.createTextNode(), phương thức createElement() có thể được dùng để tạo ra bất kỳ phần tử HTML nào, tham số là kiểu của loại thẻ HTML;
var childEl=document.createElement("div");
createTextNode() tạo một nút thể hiện qua một đoạn text, thường được tìm thấy trong các thẻ về heading, div, paragraph, và list item.
var txtNode=document.createTextNode("some text");

Chuẩn DOM coi các text node tách rời khỏi biểu diễn HTML. Chúng không có các stye để áp đặt cho trực tiếp và vì thế chúng yêu cầu ít bộ nhớ hơn.
Một nút khi được tạo ra phải được gắn vào tài liệu trước khi hiển thị trên trình duyệt, phương thức appendChild() được dùng để thực hiện điều này el.appendChild(childEl);
Ba phương thức createElement(), createTextNode(), và appendChild() cho phép thực hiện hầu hết các thao tác để thêm một nút vào tài liệu.

No comments »

Posted in Ajax

Bài 4 (tiếp): Các công nghệ trong AJAX - DOM - Làm việc với DOM bằng JavaScript.

March 23rd, 2008

Làm việc với DOM bằng JavaScript.

Trong một ứng dụng bất kỳ, nếu muốn thay đổi giao diện người dùng khi họ đang làm việc, thì phải cung cấp các phản hồi lại khi người dùng gửi các yêu cầu.

Để hiểu rõ cơ chế làm việc với DOM bằng JavaScript, chúng ta cùng xét một ví dụ về một trang HTML đơn giản.

Quote:

 

<html>
<head>
<link rel=’stylesheet’ type=’text/css’ href=’hello.css’ />
<script type=’text/javascript’ src=’hello.js’></script>
</head>
<body>
<p id=’hello’>hello</p>
<div id=’empty’></div>
</body>

</html>


Ta đã thêm vào các tham chiếu đến các file hello.css (dùng Cascading Style Sheet) và một file chứa mã nguồnJavaScript là hello.js. Ở đây cũng đồng thời khai báo một thẻ <div> với một ID.

Còn đây là file hello.css chứa stylesheet để áp dụng cho các mục trong file HTML:

Quote:

.declared{
color: red;
font-family: arial;
font-weight: normal;
font-size: 16px;
}
.programmed{
color: blue;
font-family: helvetica;
font-weight: bold;
font-size: 10px;
}


Chúng ta định nghĩa hai style, để mô tả gốc của các nút DOM (tên của các style là tùy chọn). Các style này không dược dùng trong file HTML, nhưng chúng sẽ được áp dụng qua file JavaScript.

Quote:

window.onload=function(){
var hello=document.getElementById(’hello’);
hello.className=’declared’;
var empty=document.getElementById(’empty’);
addNode(empty,"reader of");
addNode(empty,"Ajax in Action!");
var children=empty.childNodes;
for (var i=0;i<children.length;i++){
children[i].className=’programmed’;
}
empty.style.border=’solid green 2px’;
empty.style.width="200px";
}
function addNode(el,text){
var childEl=document.createElement("div");
el.appendChild(childEl);
var txtNode=document.createTextNode(text);
childEl.appendChild(txtNode);
}


Hàm window.onload() sẽ được gọi khi trang web được nạp. Tại thời điểm này, cấu trúc cây DOM sẽ được thiết lập.

Trong bài 5 anh em ta sẽ học về: Tìm kiếm một DOM Node, Tạo DOM Node.

No comments »

Posted in Ajax

Bài 3: Các công nghệ trong AJAX - CSS - Cú pháp & thuộc tính CSS Style.

March 23rd, 2008

Cú pháp cơ bản của CSS
Cú pháp của CSS gồm ba thành phấn:

  • Thành phần lựa chọn (thường là một thẻ HTML) (Selector)
  • Thuộc tính (Property)
  • Giá trị (Value)


Thể hiện của cú pháp CSS

Code:

 

Selector {

   Property1: Value1;

   Property2: Value2;

}


Selector có thể là các thẻ/nhóm thẻ HTML, các lớp khai báo, hay bằng định danh duy nhất của phần tử.
Khi chèn các đoạn mã CSS vào trang web, trình duyệt sẽ hiển thị trang web theo cách CSS đã qui định cho nó, có ba cách để chèn CSS vào trang web.

a. External Style Sheet (sử dụng file CSS được định nghĩa thành trong file riêng)
Mỗi trang web sử dụng file CSS ngoài này đều phải sử dụng thẻ <LINK>. Thẻ <LINK> được đặt bên trong thẻ <HEAD>.

Code:

 

<head>

<link rel="stylesheet" type="text/css"

           href="mystyle.css" />

</head>


b. Internal Style Sheet (định nghĩa các style sheet ngay trong trang web)
Trong trường hợp mỗi trang web của sử dụng các định dạng khác nhau, dùng Internal Style Sheet. Để định nghĩa Internal Style Sheet, sử dụng thẻ <STYLE> đặt bên trong thẻ <HEAD>.

Code:

 

<head>

<style type="text/css">

hr {color: sienna}

p {margin-left: 20px}

body {background-image: url("images/back40.gif")}

</style>

</head>


c. Internal Style Sheet (style được qui định ngay trong mỗi thẻ HTML)
Đây là phương pháp kém hiệu quả nhất, không nên sử dụng phương pháp này vì đã làm mất các ưu điểm của CSS.

Code:

 

<p style="color: sienna; margin-left: 20px">

This is a paragraph

</p>


Các thuộc tính của CSS Style

Mỗi phần tử trong trang HTML có thể được qui định theo nhiều kiểu. Một phần text của một phần tử có thể được quy định theo các thuộc tính color, font size, độ đậm của phông, và kiểu chữ sử dụng. Có rất nhiều tùy chọn được áp dụng cho thuộc tính trên. Ví dụ để qui định cho một paragraph:

Code:

 

.robotic{

font-size: 14pt;

font-family: courier new, courier, monospace;

font-weight: bold;

color: gray;

}

 

ngocha85(Updatesofts.com)

No comments »

Posted in Ajax

Bài 2: Các công nghệ trong AJAX - CSS - Giới thiệu.

March 23rd, 2008

Từ bài này, chúng ta sẽ tìm hiểu các công nghệ trong AJAX và mối liên hệ giữa chúng.

AJAX là một tập hợp các công nghệ bổ sung lẫn nhau. JavaScript có vai trò chất keo kết dính các ứng dụng lại với nhau. Giao diện người dùng được tạo và tái nạp bằng cách dùng JavaScript để điều khiển Document Object Model, tạo và tổ chức biểu diễn dữ liệu cho người dùng, đồng thời xử lí các tương tác trên chuột và bàn phím.

Cascading Style Sheets (CSS) cung cấp một sự nhất quán trên cảm quan “look and feel” cho ứng dụng và khả năng thao tác mạnh mẽ với DOM. Đối tượng XMLHttpRequest (hay một cơ chế tương đương nào đó) được dùng để liên lạc một cách bất đồng bộ với server, đảm bảo việc gửi yêu cầu người dùng và tái nạp dữ liệu trong khi người dùng vẫn làm việc.

Cascading Style Sheet – CSS

Phần này khá là dài, tớ sẽ viết cố gắng thật dễ hiểu.

Cascading Style Sheet – tạm dịch là bảng kiểu xếp chồng - là một phần không thể thiếu trong thiết kế Web, nó được dùng rất nhiều trong các ứng dụng Web truyền thống cũng như trong Ajax. Một stylesheet đưa ra cách kiểm soát các loại định dạng trực quan, nó có thể được áp dụng cho các thành phần riêng lẻ trên các trang.

Hơn nữa, cho các thành phần định dạng trực quan như màu sắc, lề, hình nền, tính trong suốt, kích cỡ, stylesheet có thể xác định cách mà các phần tử được bố trí quan hệ với các phần tử khác và tương tác với người dùng, cho phép các hiệu ứng khá mạnh mẽ.

Trong ứng dụng Web truyền thống, stylesheet cung cấp một cách hiệu quả để xác định cách thể hiện vị trí và có thể được dùng lại trong nhiều trang web khác nữa.Với AJAX, stylesheet cung cấp một “kho chứa” các giao diện xác định trước có thể áp dụng cho các phần tử động với độ dài các đoạn mã nguồn là nhỏ nhất.

CSS định dạng một trang web theo ba cách :

  1. Sử dụng trực tiếp kèm với các thẻ HTML (Inline Style Sheet)
  2. Định nghĩa trong một trang web (Internal Style Sheet).
  3. Định nghĩa thành một file CSS riêng (External Style Sheet). Trang web của chúng ta sẽ tham chiếu đến file CSS này.


Một quy tắc định dạng và bố trí gồm có hai phần: thành phần lựa chọn - selector và phần khai báo - style declaration. Selector đặc tả các phần tử được định dạng và bố trí, và style declaration khai báo các thuộc tính định dạng sẽ được áp dụng. Giả sử muốn tạo ra các dòng text trong level-1 heading trong tài liệu (đó là đoạn nằm trong thẻ <H1>) có màu đỏ.
Có thể khai báo thuộc tính CSS như sau:

Code:

h1 {color: red}

 

 

Chúng ta cũng nên phân tích:
Các ưu điểm của CSS trong thiết kế web

a. CSS giúp tiết kiệm được rất nhiều thời gian và công sức cho việc thiết kế web.
Style trong phiên bản HTML 4.0 qui định cách thức thể hiện các thẻ. Style thường được lưu trong các file nằm ngoài trang web. Chúng giúp thay đổi cách thức định dạng và cách bố trí các trang web chỉ bằng cách thay đổi riêng file CSS.

b. CSS cho phép điều khiển cách định dạng và cách bố trí của cùng lúc nhiều trang web với chỉ duy nhất một lần thay đổi tại một vị trí.

c. Có thể định nghĩa nhiều style vào một thẻ HTML .
CSS cho phép đưa các thông tin định nghĩa thẻ thông qua nhiều con đường khác nhau. Style có thể được qui định ở trong chỉ một thẻ HTML, được qui định trong một trang web hoặc ở trong một file CSS bên ngoài.

d. Thứ tự áp dụng các định dạng
Như trên đã nói, có thể sử dụng nhiều cách khác nhau để làm CSS. Điều gì sẽ xảy ra nếu áp dụng nhiều cách định dạng cho một thẻ HTML? Theo một cách chung nhất ra có thể nói các style sẽ được "xếp tầng" (cascade). Việc xếp tầng này tuân theo thứ tự ưu tiên giảm dần như sau:

  • Inline Style (Style được qui định trong một thẻ HTML cụ thể)
  • Internal Style (Style được qui định trong phần <HEAD> của một trang HTML)
  • External Style (style được qui định trong file CSS ngoài)
  • Browser Default (thiết lập mặc định của trình duyệt)


Bài sau chúng ta sẽ đi vào: Cú pháp cơ bản của CSS.

 

ngocha85(Updatesofts.com)

2 comments »

Posted in Ajax

Công nghệ Web thế hệ thứ hai – Web 2.0

March 23rd, 2008

Được xem là một cuộc cách mạng trên thế giới mạng, thế hệ web mới có những thay đổi quan trọng không chỉ ở nền tảng công nghệ mà còn cả ở cách thức sử dụng - hình thành nên môi trường cộng đồng, ở đó mọi người cùng tham gia đóng góp cho xã hội "ảo" chứ không chỉ "duyệt và xem".

Web 2.0 là gì? Làm sao phân biệt đâu là Web 1.0 đâu là Web 2.0? Thuật ngữ "Web 2.0" đang trở nên thịnh hành. Thực chất, Web 2.0 có nghĩa là sử dụng web đúng với bản chất và khả năng của nó.

Mục tiêu đầu tiên của những người tiên phong xây dựng Internet là nhằm kết nối các nhà nghiên cứu và các máy tính của họ với nhau để có thể chia sẻ thông tin hiệu quả. Khi bổ sung World Wide Web (năm 1990), Tim Berners-Lee cũng nhằm mục tiêu tạo phương tiện cho phép người dùng tự do đưa thông tin lên Internet và dễ dàng chia sẻ với mọi người (trình duyệt web đầu tiên do Berners-Lee viết bao gồm cả công cụ soạn thảo trang web). Tuy nhiên, sau đó web đã phát triển theo hướng hơi khác mục tiêu ban đầu.

Tuy có một số ngoại lệ nhưng thế giới Web 1.0 (thế hệ web trước Web 2.0) chủ yếu gồm các website "đóng" của các hãng thông tấn hay các công ty nhằm mục đích tiếp cận độc giả hay khách hàng hiệu quả hơn. Nó là phương tiện phát tin hơn là phương tiện chia sẻ thông tin. Chỉ đến gần đây, với sự xuất hiện của nhiều kỹ thuật mới như blog (hay weblog), wiki… web mới trở nên có tính cộng đồng (và cộng tác) hơn và trở nên gần hơn với sự kỳ vọng và khả năng thực sự của nó.

Khái niệm Web 2.0 đầu tiên được Dale Dougherty, phó chủ tịch của O’Reilly Media, đưa ra tại hội thảo Web 2.0 lần thứ nhất do O’Reilly Media và MediaLive International tổ chức vào tháng 10/2004. Dougherty không đưa ra định nghĩa mà chỉ dùng các ví dụ so sánh phân biệt Web 1.0 và Web 2.0: "DoubleClick là Web 1.0; Google AdSense là Web 2.0. Ofoto là Web 1.0; Flickr là Web 2.0. Britannica Online là Web 1.0; Wikipedia là Web 2.0. v.v…".

Sau đó Tim O’Reilly, chủ tịch kiêm giám đốc điều hành O’Reilly Media, đã đúc kết lại 7 đặc tính của Web 2.0:

1.    Web có vai trò nền tảng, có thể chạy mọi ứng dụng

2.    Tập hợp trí tuệ cộng đồng

3.    Dữ liệu có vai trò then chốt

4.    Phần mềm được cung cấp ở dạng dịch vụ web và được cập nhật không ngừng

5.    Phát triển ứng dụng dễ dàng và nhanh chóng

6.    Phần mềm có thể chạy trên nhiều thiết bị

7.    Giao diện ứng dụng phong phú

Thoạt đầu, Web 2.0 được chú trọng tới yếu tố công nghệ, nhấn mạnh tới vai trò nền tảng ứng dụng. Nhưng đến hội thảo Web 2.0 lần 2 tổ chức vào tháng 10/2005, Web 2.0 được nhấn mạnh đến tính chất sâu xa hơn – yếu tố cộng đồng.

 

 

Thực tế, ứng dụng trên web là thành phần rất quan trọng của Web 2.0. Hàng loạt công nghệ mới được phát triển nhằm làm cho ứng dụng trên web mạnh hơn, nhanh hơn và dễ sử dụng hơn, được xem là nền tảng của Web 2.0.
Kiến trúc công nghệ của Web 2.0 hiện vẫn đang phát triển nhưng cơ bản bao gồm: phần mềm máy chủ, cơ chế cung cấp nội dung, giao thức truyền thông, trình duyệt và ứng dụng.

Cung cấp nội dung
Bước phát triển đầu tiên và quan trọng nhất hướng đến Web 2.0 đó là cơ chế cung cấp nội dung, sử dụng các giao thức chuẩn hoá để cho phép người dùng sử dụng thông tin theo cách của mình (nghĩa là có khả năng tùy biến thông tin). Có nhiều giao thức được phát triển để cung cấp nội dung như RSS, RDF và Atom, tất cả đều dựa trên XML. Ngoài ra còn có các giao thức đặc biệt như FOAF và XFN dùng để mở rộng tính năng của website hay cho phép người dùng tương tác.

Dịch vụ web
Các giao thức truyền thông 2 chiều là một trong những thành phần then chốt của kiến trúc Web 2.0. Có hai loại giao thức chính là REST và SOAP. REST (Representation State Transfer) là dạng yêu cầu dịch vụ web mà máy khách truyền đi trạng thái của tất cả giao dịch; còn SOAP (Simple Object Access Protocol) thì phụ thuộc máy chủ trong việc duy trì thông tin trạng thái. Với cả hai loại, dịch vụ web đều được gọi qua API. Ngôn ngữ chung của dịch vụ web là XML, nhưng có thể có ngoại lệ.

Một ví dụ điển hình của giao thức truyền thông thế hệ mới là Object Properties Broadcasting Protocol do Chris Dockree phát triển. Giao thức này cho phép các đối tượng ảo (tồn tại trên web) tự biết chúng "là gì và có thể làm gì”, nhờ vậy có thể tự liên lạc với nhau khi cần.

Phần mềm máy chủ
Web 2.0 được xây dựng trên kiến trúc web thế hệ trước nhưng chú trọng hơn đến phần mềm làm việc ở background. Cơ chế cung cấp nội dung chỉ khác phương thức cấp phát nội dung động (của Web 1.0) về danh nghĩa, tuy nhiên dịch vụ web yêu cầu tiến trình làm việc và dữ liệu chặt chẽ hơn.

Các giải pháp phát triển theo hướng Web 2.0 hiện nay có thể phân làm hai loại: hoặc xây dựng hầu hết tính năng trên một nền tảng máy chủ duy nhất; hoặc xây dựng ứng dụng "gắn thêm" cho máy chủ web, có sử dụng giao tiếp API.

 

 

AJAX là gì ?

Sau đây là định nghĩa của Garrett về Ajax:
AJAX là tập hợp của nhiều công nghệ với thế mạnh của riêng mình để tạo thành một sức mạnh mới. AJAX bao gồm:

  • Thể hiện web theo tiêu chuẩn XHTML và CSS, các chuẩn của W3C, được Firefox (Mozilla), Safari (Apple), Opera, Netscape 8.0 (nhân Firefox) hỗ trợ rất tốt.
  • Nâng cao tính năng động và phản hồi bằng DOM (Document Object Model); một chuẩn của W3C
  • Trao đổi và xử lý dữ liệu bằng XML và XSLT; cũng là một chuẩn của W3C
  • Truy cập dữ liệu theo kiểu bất đồng bộ (asynchronous) bằng XMLHttpRequest
  • Và tất cả các công nghệ trên được liên kết lại với nhau bằng JavaScript.

Trong bài sau, chúng ta sẽ tìm hiểu các thế mạnh của công nghệ AJAX.
Thật ra tớ cũng cần nói thêm, việc ra đời của công nghệ này, là một quá tronhf lâu dài và nếu nói chi tiết ra đây thì cũng thật là không cần thiết lắm. Anh em ta học công nghệ là chính

 

 

Các vấn đề nảy sinh và sự ra đời của AJAX

Trước khi tìm hiểu tại sao Ajax lại được xem là "cứu tinh" của các ứng dụng Web, hãy thử phân tích những giới hạn của các ứng dụng web hiện tại khiến nó chưa thể thay thế cho các phần mềm phía client truyền thống.

Chỉ cách đây vài năm, khi mà các dịch vụ web bùng nổ, người ta đã nghĩ đến một lúc nào đó tất cả các ứng dụng mà ta sử dụng sẽ là các ứng dụng Web thay vì các phần mềm chạy độc lập trên các máy tính đơn lẻ. Quả thật, với sự phát triển chóng mặt của mạng Internet cùng với những ưu điểm của các ứng dụng Web (truy cập tại mọi nơi, không cần nâng cấp,…), tương lai của các phần mềm chắc chắn sẽ gắn chặt với các ứng dụng Web, nếu không muốn nói là có thể sẽ bị thay thế. Tuy nhiên, cho đến giờ, giấc mơ đó vẫn chưa thành sự thật và người ta bắt đầu nghĩ rằng, có lẽ nó sẽ không bao giờ trở thành sự thật.

Tại sao vậy? Bởi vì một trong những giới hạn quan trọng của các ứng dụng Web hiện tại là cách thức nó tương tác với người dùng. Khác với các phần mềm chạy độc lập ở máy khách có những khả năng dường như vô tận trong cách thức tương tác với người dùng, các ứng dụng Web bị giới hạn bởi chính nguyên lý hoạt động của nó: tất cả các giao dịch phải thực hiện thông qua phương thức giao dịch HTTP (HyperText Transport Protocol - Giao thức truyền tải qua các siêu liên kết).

Để hiểu tại sao tính chất này lại trở thành một rào cản của các ứng dụng web, hãy phân tích cách thức hoạt động của các dịch vụ web hiện tại xử lý một tác vụ đơn giản như xóa email trong YahooMail. Ta đang duyệt qua hòm thư “Inbox” của Yahoo!Mail. Khi chọn một số email và nhấn nút Delete để xóa chúng (chuyển vào thùng rác). Yahoo!Mail trước hết sẽ lấy danh sách các email được chọn (quá trình này chạy trên máy local), sau đó gửi danh sách này cùng với mã lệnh qua một siêu liên kết đến server của Yahoo, yêu cầu server thực hiện tác vụ xóa đối với các email đó và gửi lại trang web Yahoo!Mail với nội dung mới, rồi cập nhật để trình duyệt hiển thị. Việc gửi nhận yêu cầu này mất một khoảng thời gian trễ, nếu ta sử dụng ADSL thì thời gian này cũng không quá lâu, còn nếu dùng dịch vụ dial-up thì thời gian chờ đợi là rất lớn. Ta cũng sẽ phải trải qua một quá trình tương tự đối với các tác vụ khác, ví dụ như chuyển từ thư mục “Inbox”(hòm thư đến) sang “Sent” (hòm thư đi).

Ta sẽ không bao giờ phải trải qua việc chờ đợi trên khi sử dụng các phần mềm chạy trên máy tính đơn lẻ: không bao giờ thấy phần mềm một khi đã được mở ra lại phải “vô hiệu” trong vài giây để cập nhật dù chỉ là một tác vụ đơn giản nhất, và ngay cả khi phần mềm cần thời gian xử lý một tác vụ nào đó thì ta vẫn thấy nó vẫn tương tác với người dùng. Nếu xét về khía cạnh khả năng ứng dụng trong các tác vụ hàng ngày thì hạn chế trên của các ứng dụng web là không thể chấp nhận được.

Tất nhiên, bên cạnh rào cản về cách thức tương tác, các ứng dụng Web còn vấp phải nhiều giới hạn khác (ví dụ như bản thân việc phải hoạt động dựa trên các trình duyệt đã là một rào cản quan trọng) nhưng một khi chưa giải quyết được vấn đề trên thì các ứng dụng web sẽ không bao giờ có thể thay thể cho các phần mềm độc lập.

Ajax ra đời là một giải pháp cho các ứng dụng Web hiện nay, và như ta nói, nó là một trong số các công nghệ Web thế hệ thứ hai.

 

ngocha85(Updatesofts.com)

2 comments »

Posted in Ajax

Bài 0: Quá trình phát triển công nghệ Web - Nguyên nhân xuất hiện công nghệ AJAX.

March 23rd, 2008

Trước khi tìm hiểu về Ajax, chúng ta cùng xem xét quá trình phát triển các công nghệ Web, nguyên nhân và hoàn cảnh xuất hiện công nghệ Ajax.

Quá trình phát triển các công nghệ trong ứng dụng Web

Ban đầu, các trang Web là tĩnh; người dùng gửi yêu cầu một tài nguyên nào đó, và server sẽ trả về tài nguyên đó. Các trang Web không có gì hơn là một văn bản được định dạng và phân tán. Đối với các trình duyệt, thì các trang Web tĩnh không phải là các vấn đề khó khăn, và trang Web lúc đầu chỉ để thông tin về các sự kiện, địa chỉ, hay lịch làm việc qua Internet mà thôi, chưa có sự tương tác qua các trang Web. Năm 1990, Tim Berners-Lee, tại CERN, đã sáng chế ra HTML (Hyper Text Markup Language), ngôn ngữ đánh dấu siêu văn bản. HTML rất đơn giản và dễ dùng, và nó trở thành một ngôn ngữ rất phổ biến và cơ bản.

Tuy nhiên, không lâu sau đó, nhu cầu về các trang Web động, có sự tương tác ngày một tăng, chính vì thế sự ra đời các công nghệ Web động là một điều tất yếu. Sau đây là một số công nghệ Web động cơ bản:

1. CGI
Giải pháp đầu tiên để làm các trang Web động là Common Gateway Interface (CGI). CGI cho phép tạo các chương trình chạy khi người dùng gửi các yêu cầu. Giả sử khi cần hiển thị các các mục để bán trên Web site – với một CGI script ta có thể truy nhập cơ sở dữ liệu sản phẩm và hiển thị kết quả. Sử dụng các form HTML đơn giản và các CGI script, có thể tạo các “cửa hàng” ảo cho phép bán sản phẩm cho khách hàng qua một trình duyệt. CGI script có thể được viết bằng một số ngôn ngữ từ Perl cho đến Visual Basic.
Tuy nhiên, CGI không phải là cách an toàn cho các trang Web động. Với CGI, người khác có thể chạy chương trình trên hệ thống. Vì thế có thể chạy các chương trình không mong muốn gây tổn hại hệ thống. Nhưng dù vậy, cho đến hôm nay thì CGI vẫn còn được sử dụng.

2. Applet
Tháng 5/1995, John Gage của hãng Sun và Andressen (nay thuộc Netscape Communications Corporation) đã công bố một ngôn ngữ lập trình mới có tên Java. Netscape Navigator đã hỗ trợ ngôn ngữ mới này, và một con đường mới cho các trang Web động được mở ra, kỷ nguyên của applet bắt đầu.

Applet cho phép các nhà phát triển viết các ứng dụng nhỏ nhúng vào trang Web. Khi người dùng sử dụng một trình duyệt hỗ trợ Java, họ có thể chạy các applet trong trình duyệt trên nền máy ảo Java Virtual Machine (JVM). Dù rằng applet làm được nhiều điều song nó cũng có một số nhược điểm: thường bị chặn bởi việc đọc và ghi các file hệ thống, không thể tải các thư viện, hoặc đôi khi không thể thực thi trên phía client. Bù lại những hạn chế trên, applet được chạy trên một mô hình bảo mật kiểu sandbox bảo vệ người dùng khỏi các đoạn mã nguy hiểm.

Có những lúc applet được sử dụng rất nhiều, nhưng nó cũng có những vấn đề nảy sinh: đó là sự phụ thuộc vào máy ảo Java JVM, các applet chỉ thực thi khi có môi trường thích hợp được cài đặt phía client, hơn nữa tốc độ của các applet là tương đối chậm vì thế applet không phải là giải pháp tối ưu cho Web động.

3. JavaScript
Cùng thời gian này, Netscape đã tạo ra một ngôn ngữ kịch bản gọi là JavaScript. JavaScript được thiết kế để việc phát triển dễ dàng hơn cho các nhà thiết kế Web và các lập trình viên không thành thạo Java. (Microsoft cũng có một ngôn ngữ kịch bản gọi là VBScript). JavaScript ngay lập tức trở thành một phương pháp hiệu quả để tạo ra các trang Web động.
Việc người ta coi các trang như là một đối tượng đã làm nảy sinh một khái niệm mới gọi là Document Object Model (DOM). Lúc đầu thì JavaScript và DOM có một sự kết hợp chặt chẽ nhưng sau đó chúng được phân tách. DOM hoàn toàn là cách biểu diễn hướng đối tượng của trang Web và nó có thể được sửa đổi với các ngôn ngữ kịch bản bất kỳ như JavaScript hay VBScript.
Tổ chức World Wide Web Consortium (W3C) đã chuẩn hóa DOM, trong khi European Computer Manufacturers Association (ECMA) phê duyệt JavaScript dưới dạng đặc tả ECMAScript.

4. JSP/Servlet, ASP và PHP
Cùng với Java, Sun đồng thời đưa ra một công nghệ mới gọi là servlet. Các đoạn mã Java sẽ không chạy phía client như với applet; chúng sẽ được chạy trên một ứng dụng phía server. Servlet cũng đồng thời phục vụ các CGI script. Servlet là một bước tiến lớn, nó đưa ra một thư viện hàm API trên Java và một thư viện hoàn chỉnh để thao tác trên giao thức HTTP.
JavaServer Page (JSP) là một công nghệ lập trình Web của Sun, cùng với nó là một công nghệ khác của Microsoft - Active Server Pages (ASP), JSP là công nghệ đòi hỏi một trình chủ hiểu được Java.
Microsoft đã nghiên cứu các nhược điểm của servlet và tạo ra ASP dễ dàng hơn để thiết kế các trang web động. Microsoft thêm các bộ công cụ rất mạnh và sự tích hợp rất hoàn hảo với các Web server. JSP và ASP có những nét tương đương vì chúng đều được thiết kế để phân tách qua trình xử lí khỏi quá trình biểu diễn. Có sự khác biệt về kỹ thuật, song cả hai đều cho phép các nhà thiết kế Web tập trung vào cách bố trí (layout) trong khi các nhà phát triển phần mềm thì tập trung vào các kỹ thuật lập trình logic.
Tất nhiên Microsoft và Sun không độc quyền ở các giải pháp phía server. Còn có các công nghệ khác, trong đó phải kể đến là PHP (Hypertext Preprocessor) cho tới Cold Fusion. Các công nghệ này cung cấp các bộ công cụ rất mạnh cho các nhà phát triển.

5. Flash
Năm 1996, FutureWave đã đưa ra sản phẩm FutureSplash Animator. Sau đó FutureWave thuộc sở hữu của Macromedia, và công ty này đưa ra sản phẩm Flash. Flash cho phép các nhà thiết kế tạo các ứng dụng hoạt họa và linh động. Flash không đòi hỏi các kỹ năng lập trình cao cấp và rất dễ học. Cũng giống như các nhiều giải pháp khác Flash yêu cầu phần mềm phía client. Chẳng hạn như gói Shockwave Player plug-in có thể được tích hợp trong một số hệ điều hành hay trình duyệt.

6. DHTML
Khi Microsoft và Netscape đưa ra các version 4 của các trình duyệt của họ, thì các nhà phát triển Web có một lựa chọn mới: Dynamic HTML (DHTML). DHTML không phải là một chuẩn của W3C; nó giống một bộ công cụ thương mại hơn. Trong thực tế nó là một tập hợp gồm HTML, Cascading Style Sheets (CSS), JavaScript, và DOM. Tập hợp các công nghệ trên cho phép các nhà pháp triển sửa đổi nội dung và cấu trúc của một trang Web một cách nhanh chóng. Tuy nhiên, DHTML yêu cầu sự hỗ trợ từ các trình duyệt. Mặc dù cả Internet Explorer và Netscape hỗ trợ DHTML, nhưng các thể hiện của chúng là khác nhau, các nhà phát triển cần phải biết được loại trình duyệt nào mà phía client dùng. DHTML thật sự là một bước tiến mới, nhưng nó vẫn cần một sự qui chuẩn để phát triển. Hiện nay DHTML vẫn đang trên con đường phát triển mạnh.

7. XML
Kể từ khi ra đời vào giữa năm 1990, eXtensible Markup Language (XML) của W3C dẫn xuất của SGML đã trở nên rất phổ biến. XML có mặt ở khắp nơi, Microsoft Office 12 cũng sẽ hỗ trợ định dạng file XML.

Ngày nay chúng ta có rất nhiều dạng dẫn xuất của XML cho các ứng dụng Web (tất nhiên là có cả XHTML): XUL của Mozilla; XAMJ, một sản phẩm mã nguồn mở trên nền Java; MXML từ Macromedia; và XAML của Microsoft.

 

Tác giả : ngocha85(Updatesofts.com)

1 comment »

Posted in Ajax

Tags:

Một số ví dụ về Ajax

January 29th, 2008

Dưới đây là một số ví dụ về Ajax mình tổng hợp được trên internet nay upload lên đây chia sẻ cùng mọi người.Để download bạn click vào link download phía dưới đây:

Download code here

 

 

No comments »

Posted in Ajax

Tags:

When to Use Ajax and When Not To

January 29th, 2008

What to Do When You Get the "Ajax Call" from Your Boss

I admit it, I’ve never been a huge fan of JavaScript. I was always really glad that About had a JavaScript Guide so that I didn’t have to cover it on my site. I can read and write JavaScript, but until lately, I had very little interest in it. For whatever reason, my mind had a complete mental break when it came to writing JS scripts. I can write complicated C++ and Java applications and I can write Perl CGI scripts in my sleep, but JavaScript was always a struggle.

Ajax Made JavaScript More Fun

I think part of the reason I didn’t like JavaScript was because rollovers are boring. Sure, you can do more than that with JS, but 90% of the sites out there using it were doing either rollovers or form validation, and not much else. And once you’ve validated one form, you’ve validated them all.

Then Ajax came along and made it all new again.

 

Suddenly we had browsers that would support JavaScript doing something other than swaping images and we had XML and the DOM to connect data to our scripts. And all of this means that Ajax is intersting to me, so I want to build Ajax applications.

What’s the Stupidest Ajax Application You’ve Ever Built?

I think mine would have to be the email checker on an account that got almost no email. You would go to the Web page and it would say "You have 0 mail messages." The 0 would change if a message came in, but since that account got no mail, it would never change. I tested it by sending mail to the account, and it worked. But it was absolutely pointless. There were better mail checkers available five years ago, and I didn’t have to have Firefox or IE running to use them. When one of my co-workers saw it she said "What’s it do?" When I explained, she asked "Why?"

Before Building an Ajax Application Always Ask Why

Why Ajax?
If the only reason you’re building the application in Ajax is because "Ajax is cool" or "my boss told me to use Ajax," then you should seriously evaluate your technology choice. When you’re building any Web application you should be thinking of your customers first. What do they need this application to do? What will make it easier to use?

Why Not Something Else?
It can be very tempting to use Ajax simply because you can. On one site that my team was working on, there was a tabbed section of the page. All the content was stored in XML in a database and when you clicked on the tabs, Ajax was used to rebuild the page with the new tab data from the XML.

This seemed like a good use of Ajax, until you start thinking of some of the issues with it:

  • The tabs cannot be bookmarked. So customers can’t save the information they want.
  • Search engines don’t see the data that isn’t in the first tab, because they can’t access the Ajax.
  • Ajax is not accessible, so the content in the other tabs would not be visible to anyone using a screen reader, or even older browsers that don’t have good JavaScript support.
  • If one of the tabs had a lot of information, it could take a long time to load on a slow connection. And because Ajax doesn’t indicate anything is happening it looks like the page is broken.

The thing that was interesting, is that this Web site had similar pages in the past that didn’t use Ajax. They delivered the content either with hidden divs or separate HTML pages. There was no reason to use Ajax other than that Ajax was cool, and our boss had suggested we look for places to use it.

Ajax is for Action Not Content

If you’re going to put up an Ajax application, or just something Ajax-like on your Web site, first determine if the data you’re accessing changes. The point of the asynchronous request is that it makes requests to the server for information that has changed faster - because it’s happening while the reader is doing something else. Then when they click a link or button (or after a set amount of time - whatever your distinction is) the data shows up right away.

If your content or data never changes, then you shouldn’t use Ajax to access it.

If your content or data only rarely changes, then you probably shouldn’t use Ajax to access it.

 

No comments »

Posted in Ajax

Get or Post

January 29th, 2008

When you use Ajax to access the server without reloading the web page you have two choices on how to pass the information for the request to the server. These two options are to use GET or POST.

These are the same two options that you have when passing requests to the server to load a new page with two differences. The first difference is that you are only requesting a small piece of information instead of an entire web page. The second and most noticable difference is that since the Ajax request doesn’t appear in the address bar there is no noticable difference that your visitor will see on their screen when the request is made. Calls made using GET will not expose the fields and their values anythere that using POST does not also expose when the call is made from Ajax.

So how should we make the choice as to which of these two alternatives that we should use?

A mistake that some beginners might make is to use GET for most of their calls simply because it is the easier of the two to code.

 

The most noticable difference between GET and POST calls in Ajax is that GET calls still have the same limit on the amount of data that can be passed as applies when requesting a new page load. The only difference is that as you are only processing a small amount of data with an Ajax request (or at least that’s how you should use it) you are far less likely to run into this length limit from within Ajax to what you are with complete web page loads. A beginner may reserve using POST requests for the few instances where they do need to pass more information that the GET method allows.

The best solution when you have lots of data to pass like that is to make multiple Ajax calls passing a few pieces of information at a time. If you are going to pass huge amounts of data all in the one Ajax call then you would probably be better off simply reloading the entire page since there will be no significant difference in the processing time when huge amounts of data are involved.

So if the amount of data to be passed isn’t a good reason to use for choosing between GET and POST then what should we use to decide which to use? These two methods were in fact set up for entirely different purposes and the differences between how they work are in part due to the difference in what they are intended to be used for. This not only applies to using GET and POST from Ajax but applies to these methods where ever they are used.

The purpose of GET is as its name implies - to GET information. It is intended to be used when you are reading information to display on the page. Browsers will cache the result from a GET request and if the same GET request is made again then they will display the cached result rather than rerunning the entire request. This is not a flaw in the browser processing but is deliberately designed to work that way so as to make GET calls more efficient when the calls are used for their intended purpose. A GET call is retrieving data to display in the page and data is not expected to be changed on the server by such a call and so re-requesting the same data should be expected to obtain the same result.

The POST method is intended to be used where you are updating information on the server. Such a call is expected to make changes to the data stored on the server and the results returned from two identical POST calls may very well be completely different from one another since the initial values before the second POST call will be differentfrom the initial values before the first call because the first call will have updated at least some of those values. A POST call will therefore always obtain the response from the server rather than keeping a chached copy of the prior response.

So rather than choosing between GET and POST based on the amount of data that you are passing in your Ajax call, you should select between them based on what the Ajax call is actually doing. If the call is to retrieve data from the server then use GET. If the value to be retrieved is expected to vary over time as a result of other processes updating it then add a current time parameter to what you are passing in your GET call so that the later calls will not use an earlier cached copy of the result that is no longer correct. If your call is going to write any data at all to the server then use POST.

In fact you should not only use this criteria for selecting between GET and POST for your Ajax calls. You should use this as the criteria for choosing whether to use GET or POST when processing forms on your web page as well.

No comments »

Posted in Ajax

Ajax- Asynchronous or Synchronous

January 29th, 2008

One of the biggest advantages that Ajax has in web pages is that it can access information on the server without having to reload the web page. This means that to retrieve or update one small piece of information only that information needs to be passed to and from the server instead of having to redownload the entire web page.

There are two ways that Ajax can access the server. These are synchronous (wnere the script stops and waits for the server to send back a reply before continuing) and asynchronous (where the script allows the page to continue to be processed and will handle the reply if and when it arrives).

Processing your request synchronously is a bit like reloading the page but with only the requested information having t0o be downloaded instead of the entire page.

 

This method os therefore somewhat faster than not using Ajax since the information to be downloaded should be significantly smaller and hence faster to retrieve than downloading the entire page over again. It does however still require that your visitor wait for the download to occur. While your visitors are used to having to wait for entire web pages to download, they are not used to having to wait while interacting with a web page for any significant time and so unless the information you are requesting is particularly small so that it can be downloaded extremely quickly you run the risk of alienating visitors who may have been quite happy with a longer wait to download the entire page.

Processing asynchronously avoids the delay while the retrieval from the server is taking place because your visitor can continue to interact with the web page and the requested information will be processed with the response updating the page as and when it arrives. For larger requests where the response will have a noticable delay that delay possibly will not be noticed by your visitors because they are occupied interecting with fields further down the page. For responses that are nearly instantaneous your visitors will not even be aware that a request to the server was made.

The preferred way to use Ajax therefore is to use asynchronous calls where ever possible so as to enhance your visitors experience with the web page and to avoid having the Ajax interfer with the operation of the page. Using Ajax asynchronously is so obviously the right way that Ajax should be used that the A in Ajax is actually considered by those who consider AJAX to be an acronym to stand for Asynchronous (although the originator of the term claims that it is not an acronym and the letrters therefore don’t stand for anything).

If asynchronous calls are so much better for your visitor’s experience of the page than synchronous calls, why does Ajax provide a way to make synchronous calls at all? While asynchronous calls will work 99.9% of the time, there are rare situations where it just doesn’t make any sense at all to allow your visitor to continue interacting with the web page until a particular server side process completes. In many of these cases it may be better to not use Ajax at all and instead just reload the entire page. The synchronous option in Ajax is there for the small number of situations where you can’t use an asynchronous call and reloading the entire page is also inappropriate. There are not many such situations but they do exist and so Ajax provides for them.

A trap that many beginners may fall into is to use synchronous Ajax calls where asynchronous calls are more appropriate (as they are most of the time). The reason for this is that synchronous calls are easier to understand how the processing works. The thing is that asynchronous calls actually work exactly the same way except for the processing not waiting for the response but instead just handling the response when it arrives.

The only difference when using asynchronous calls is that you can actually set up multiple Ajax calls that overlap with a second call being made before the first has responded. This is where asynchronous Ajax does become slightly more complicated than synchronous Ajax because you need to make sure that each Ajax request uses a separate Ajax object rather than reusing the same object for all your Ajax requests. If you use the same object for multiple asynchronous Ajax calls then the response handler will only handle the first response that it receives and will disregard any subsequent responses. With overlapping Ajax calls with the same object you have no real way to tell whether the response that gets processed is a response to the first call or the second. By using separate objects for each Ajax call you will have a separate response handler for each request that will handle toe response from the request made by that object.

Using Ajax asynchronously is the better choice for most situations. If you are only making the one Ajax call from the page then it is no different in the way you code it to what you would use for a synchronous call except for the one parameter that identifies how the call is to be processed. With multiple Ajax calls on the same page, the only additional complication is that you need to create a separate Ajax object for each request. As the various Ajax libraries will all do this for you anyway the only time that coding your Ajax to use asynchronous calls will be any different from what you could get away with for synchronous calls is if you are coding all of the JavaScript for the Ajax calls yourself instead of using a library to do it for you.

1 comment »

Posted in Ajax