III. Bức tranh toàn cảnh: Thiết kế server thông dụng
3.3.3 Các t−ơng tác script-centric
Khi ta gửi một file JavaScript từ web server tới trình duyệt, file này thực hiện trong trình duyệt cho chúng ta. Nếu ta tạo ra JavaScript mà ta sẽ gửi từ một ch−ơng trình, chúng ta sẽ thiết lập đ−ợc một hệ thống phức tạp hơn. Theo
truyền thống, các ch−ơng trình client/server trao đổi dữ liệu với nhau và nhờ việc trao đổi thông tin qua mạng này đã tạo ra sự linh hoạt.
Trong một ứng dụng web cơ bản, một đoạn JavaScript và HTML của nó đ−ợc chuyển chung với nhau, và kịch bản chỉ làm việc với một trang cụ thể. Sử dụng Ajax, ta có thể tải các kịch bản và các trang độc lập với nhau, nhờ đó ta có thể dễ dàng thay đổi một trang nào đó theo nhiều cách khác nhau, phụ thuộc vào đoạn kịch bản mà ta load về. Mã tạo thành ứng dụng client của ta có thể đ−ợc mở rộng khi thực hiện. Điều này tạo ra thách thức cũng nh− cơ hội lớn.
- Thứ nhất hoạt động mạng đ−ợc tách khỏi background, nhờ đó bỏ qua đ−ợc cảm giác nhấp nháy.
Trạng thái tự nhiên của kịch bản mà ta tạo ra sẽ phụ thuộc vào các hook mà ta phát triển ở client
Có 2 vấn đề cần xử lý khi áp dụng mô hình này. Thứ nhất với việc thay đổi mã ở server và client có thể gây ra đổ vỡi giữa chúng. Các nguyên tắc thiết kế theo kiểu module có thể loại bỏ vấn đề này, thông qua việc cung cấp mô hình Facade.
Vấn đề thứ hai cần quan tâm đó là luồng JavaScript đ−ợc thiết kế đăc biệt cho client này, và nó không t−ơng thích khi sử dụng cho nội dung khác.
* Tải các kịch bản vào IFrame
Nếu ta tải một JavaScript bằng một tag<script> HTML, script sẽ tự động thực hiện nhờ bộ biên dịch. Nếu ta sử dụng một IFrame không nhìn thấy đ−ợc để tải kịch bản của ta, ta cần tập trung vào việc tạo ra kịch bản, do tất cả các t−ơng tác khác đã đ−ợc tạo ra cho chúng ta
* Vấn đề và giới hạn
Khi ta tải một kịch bản trực tiếp từ server, chúng ta truyền đi một bản tin, và làm giảm băng thông trong một vài phạm vi nào đó. Ta cũng tách tính logic khỏi thể hiện.
Hình 2.18: Kiến trúc Script – centric cho một ứng dụng Ajax.