Khi JavaServlet lần đầu tiên xuất hiện, nhiều nhà phát triển đã tin tường vào nó bởi năng lực mạnh mẽ, khả chuyển và khả năng mở rộng vượt xa chuẩn CGI truyền thống.
Tuy nhiên, việc viết các đoạn mã hiển thị H TM L bằng phương thức print của Servlet là một điều chán nản và trở thành một bài toán đặt rạ Câu trả lời là Java Server Page (JSP). Với JSP, lập trình viên có thề dễ dàng trộn lẫn các thè HTM L với các đoạn mã Java mà vẫn có đầy đủ các tính chất của Servlet.
Để bẳt đầu với một trang JSP, lập trình viên có thể bắt đầu viết một trang HTM L và sau đó thêm các tính chất động bàng cách đưa vào các mã lệnh Java hoặc dùng các thư viện thẻ có sằn cùa JSP. Tuy nhiên, người phát triển có thể tự xây dựng các thẻ để sử dụng cùng với JSP, các thẻ này được gọi là C ustom er Taglib. Bên cạnh đó có rất nhiều các thư viện như vậy cũng được nhiều hãng phát triển, chúng được gọi là các thư viện thè JSP chuẩn gọi tắt là JSTL (Java Server Page Standard Tag Lib).
M ột thư viện nữa xuất hiện là Java Server Facẹ Kỳ thuật Java Server Face (JSF) làin đơn giản hóa việc xây dựng giao diện cho các ứng dụng web và cả ứng dụng desktop. Tuy nhiên, JSF còn đang trong quá trình phát triển và hiện tại đã có một thư viện thẻ JSF dùng cho Struts là Struts-Faces.
1.5.11. Các message-resource
Các tiêu đề, thông báo, thông báo lỗi được lưu chung vào trong các
file được gọi là các file tài nguyên thông điệp (message-resource). Các m essage-resource giúp việc thay đổi ngôn ngừ trình bày trên các giao diện cùa ứng dụng một cách dễ dàng. Ví dụ, để định nghĩa một thông báo “ Xin chào” bằng tiếng Việt Nam thì trong file m essage-resource ta thêm vào dòng “prom t.hello = Xin chào”, đề chuyển thông báo này sang tiếng Anh thì ta thay dòng đó bang “ prom t.hello = Hello” . M ặt khác, chúng ta có thê hỗ trợ đồng thời nhiều ngôn ngữ khác nhau trong một ứng dụng bằng cách tạo tương ứng một file m essage-resource cho mồi ngôn ngừ hồ trợ và tùy vào vị trí địa lý hiện tại của người sử dụng mà chương trình sẽ tự động hiển thị ngôn ngữ phù hợp hoặc người dùng tự thay đồị
CHƯƠNG II
ÁP DỤNG MVC TRONG THIÉT K É GIAO DIỆN ĐỒ HỌA 11.1. Giới thiệu
N hư đã trình bày trong các chương m ục trước, M odel - View - Controller ban đầu được áp dụng trong lập trình giao diện đồ họa của ngôn ngừ lập trình Sm allT alk-80 từ năm 1978. Sau này, M V C được áp dụng nhiều trong các GUI Fram ework như: N eXTSTEP, O PEN STEP, Cocoa, M icrosoft Foundtion Class (M PC ) hay trong thư viện đồ hoạ của Java Swing. M VC đã được đánh giá là m ột trong những phương pháp thiết kế hướng đối tượng thành công nhất hiện naỵ
Trong chương này, chúng ta sẽ tìm hiểu đôi nét về việc áp dụng M V C để xây dựng các thành phần giao diện trong ngôn ngữ lập trình SmallTalk và trong thư viện Java Swing.
11.2. Áp dụng MVC trong ngôn ngữ lập trình Sm allTalk
11.2.1. Giới thiêuỉ
M ột trong những đóng góp của Xerox PA R C cho thế giới lập trình là giao diện tương tác đa cừa sổ trong ngôn ngữ lập trình SmallTalk-80. Trong các giao diện này, đầu vào chủ yếu là các sự kiện chuột, bàn phím và đầu ra chủ yếu là các văn bản và các hình ảnh tương ứng. Khái niệm trung tâm phía sau giao diện người dùng của SmallTalk-80 là kiến trúc M odel - View - Controller. [15]
Khi chạy một ứng dụng đồ họa, ví dụ chương trình Paint, người dùng sẽ muốn các hình được vẽ ra sẽ nằm trong một cửa sổ của chương trình và trong một không gian nhất định nào đó thay vì các hình vẽ sẽ nằm trực tiếp trên màn hình và chồng chéo lên các thành phần giao diện khác. Vậy thì sự khác nhau cơ bản của hai trường hợp này là gi ? Câu trà lời đỏ là: Có áp dụng
hay không áp dụng mầu thiết kế M VC trong việc xây dựng các thành phần giao diện đồ họạ C ác chương trình áp dụng M V C sẽ có hành vi thân thiện và được mong đợi hơn trong khi các ứng dụng không áp dụng M VC sẽ có các hành vi mà đa số người sử dụng không mong muốn.
Ngôn ngữ lập trình SmallTalk-80 là dự án tiên phong trong việc áp dụng M VC để xây dựng các thành phần giao diện đồ họạ Trong đó, một chương trình được chia thành các thành phần M odel, View, Controller và việc liên kết giữa các thành phần đó sẽ tạo nên một ứng dụng hoàn chinh.
11.2.2. Thành phần Model
Thông thường, thành phần Model nắm giữ dừ liệu của chương trình, xử lý các yêu cầu của người dùng và trà về kết quả và thông báo cho phần hiển thị. Tuy vậy, trong một số trường hợp đặc biệt, M odel có thể bị bò quạ Tức là M odel không thể hiện rõ vai trò là nắm giữ các thay đổi của dữ liệu và thông báo cho View khi có các thay đổi xảy rạ Các trường hợp như vậy được gọi là “khuyết M odel” (passive model).
M ột ví dụ dễ thấy là trình soạn thào W Y SIW Y G (W hat You See Is W hat You Get - nhìn thấy nó thế nào thì nó là thế ấy). Thành phần M odel ở đây là chuỗi văn bản (String), View chịu trách nhiệm hiển thị nội dung của String lên màn hình, Controller nhận các sự kiện từ bàn phím. Thông thường, khi có tác động của người dùng lên bàn phím, C ontroller sẽ nhận các sự kiện đó và chuyển đến cho M odel xử lý chúng, tiếp đến M odel sẽ thông báo các thay đổi của hệ thống cho View biết để cập nhật những thay đổị Tuy nhiên, trong ví dụ này, mỗi khi người dùng nhập vào một chừ cái thì sẽ tương ứng với một thay đổi trong M odel và View cần phải cập nhật lại phần hiển thị. Bởi vậy, View không cần chờ thông báo của M odel mà sẽ thực hiện việc cập nhật lại màn hình hiển thị ngay sau khi Controller nhận một sự kiện người dùng.
Tuy nhiên, “khuyết M odel” là ít xảy rạ Trong ví dụ trên, già sử cần chèn một đoạn văn bán khác vào sau đoạn văn bản hiện tạị Do chỉ có M odel mới nắm giữ toàn bộ thông tin về dữ liệu của hệ thống nên M odel phải thông báo cho View biết là đã có sự thay đổi trong dữ liệụ Trong Sm allTalk-80, có hai phương pháp để Model có thể thông báo cho View biết về các thay đổi diễn ra trong dừ liệụ
- Cách 1: Sừ dụng một đối tượng toàn cục lưu tất cả các liên kết giữa các M odel và View trong hệ thống bàng cách sử dựng đối tượng
IndentityD icíionary gọi đến đối tượng D ependentF ields, đổi tượng này lưu tất cả các phụ thuộc của View với Model. Các khóa của từ điển là tất cà các đối tượng đã đăng ký phụ thuộc; giá trị ứng với mồi khóa là danh sách các đối tượng đã đăng ký phụ thuộc vào khóa đó.
- C ách 2: K hai báo các đối tượng cấu thành M odel là con của lớp xây dựng sẵn Model. Các lớp M odel lưu giữ các phụ thuộc trong một biến là
dependents. Biến này có giá là nil nếu nó là một đổi tượng độc lập hay m ột là một thể hiện của m ột tập các phụ thuộc - D ependentsC olleclion. Các View dựa vào cơ chế phụ thuộc này để cập nhật lại trình diễn khi có bất kỳ sự thay đổi nào trong Model.
Phương thức hỗ trợ việc liên kết phụ thuộc của View và Model là thủ tục “updating” của lớp Object. Một thông báo “ changed” sẽ báo cho tất cả các phụ thuộc biết là đã có một sự thay đổi trong đối tượng đó. Các đối tượng phụ thuộc nhận thông báo đó về và gừi tiếp một thông báo “update: s e lf ’ cho tất các thành phần trong nó chịu ảnh hưởng của thay đổi đó. N hư vậy, M odel có thể gửi thông báo cho tất các View phụ thuộc nó rằng đã có một thay đồi đơn giàn bằng cách gửi m ột thông báo là “ self changed” . Các View nhận thông báo “ update: “ với tham số là M odel mà nó phụ thuộc. (Cũng có các thông
báo dạng change:w ith: cho phép chuyển các thông số đến các đối tượng độc lập). Phương thức m ặc định cho thông báo update: là không làm gì cả. Tuy nhiên, hầu hết các View đều có phương thức tự trình diễn lại khi nhận được thông báo “ update:” . C ơ chế changed/update được sử dụng như một kênh liên kết qua đó các View có thể được thông báo về sự thay đồi trong Model.
Tại m ột thời điểm, m ột đối tượng có thể đóng vai trò là M odel cho nhiều kiến trúc M V C. Nói cách khác là có thể có nhiều View có một Model cụ thể. Giả sử mô hình kiến trúc của một tòa nhà - bỏ qua kiến trúc của thành phần Model. Có thể có các View cho các tầng khác nhau của toà nhà, các View toàn cảnh hay các View về sơ đồ cung cấp điện... Mồi View có một C ontroller tương ứng. Khi M odel thay đồi, tất cả các View phụ thuộc sẽ được thông báọ N ếu chi m ột số trong các View cần phải thay đồi, Model có thể truyền thêm một tham số cho biết loại thay đổi nào đã xảy ra để báo cho các View quan tâm đến loại thay đổi đó. Điều này được thực hiện bằng thông báo “changed:”. M ồi m ột View sẽ nhận các thông báo đó, kiểm tra các giá trị tham số kèm theo để thực hiện những thay đồi tương ứng.
11.2.3. Thành phần View
Không giống như M odel có thể liên kết tới nhiều thành phần M V C, mỗi View chỉ liên kết được với duy nhất m ột C ontroller và ngược lạị Mồi thành phần V iew và C ontroller đều lưu giữ một biến đến các thành phần tương ứng. View lưu giừ biến controller chỉ đến Controller của nó và tương tự Controller lưu giữ biến view chỉ đến View.
Vì V iew và C ontroller đều phải liên kết với M odel nên chúng cũng có một biến là m odel chi đến đối tượng M odel cần theo dõị Vì vậy, M odel giao tiếp với các thành phần khác bằng các thông báo s e l f changed: và cả View và Controller đều cỏ thể gửi trực tiếp các thông báo đến nhau và đến Model,
View là thành phần bẩt đầu một chu trình tương tác giữa các thành phần của M VC. Khi View nhận thông báo modeịcorttroller:, nó tự đăng ký làm m ột phụ thuộc cùa M odel, thiết lập biến controller trô đến Controller và gửi thông báo v iew :self tới Controller để Controller có thể thiết lập biến view.
Đồng thời, View cũng là thành phần bắt đầu kết thúc quá trình tương tác giừa các thành phần của MVC. View giải phóng sự phụ thuộc vào M odel, gìri thông báo release đến Controller, sau đó gửi thông báo release đến các View thành phần.
Mỗi View có thể chứa các View hơn. Thông thường, mỗi cửa sổ được cấu thành từ ít nhất là 2 View. Các View lớn bên ngoài được gọi là topView, các View nhỏ bên trong được gọi là các su b v iew . Trong ngôn ngữ lập trình Smalltalk, topV iew là một thể hiện hoặc lớp con của StandardSystem View.
StandardSystem View quản lý tập các nhãn của các cửa sổ. Nó kết hợp với C ontroller quản lý việc di chuyển, tạo khung, phóng to, thu nhò hay đóng màn hình. Bên trong to p v ie w là các su b v iew , bên trong các subV iew lại có thể là
các subV iew khác (quan hệ subV iew /supperV iew ). Mối quan hệ
subV iew /superV iew được ghi lại bằng hai biến trong mỗi View là superView (trỏ đến View chứa nó) và O rderedCollection (trỏ đến danh sách các subView của nó). Trong một cửa sổ, dựa vào quan hệ này có thể dễ dàng tìm được các superVievv và subV iew. Các cửa sổ không sử dụng StandardSystem View làm top View thì có thể sử dụng đối tượng View để thay thế.
Dưới đây là m ột ví dụ đơn giản hiển thị danh sách các phương thức của m ột trình duyệt tên là m ethodListBrowser. Mỗi khi một phương thức được lựa chọn, đoạn m ã nguồn sẽ được hiển thị trong subV iew cùa nó.
openListBrowserOn: aCollection label: labeistring initialSelection: set 'Tạo và liệt kê danh sách các phương thức đặt trong aCollection"
Ị topView aBrowser I
1. aBrowser := MethodListBrowser new on: aCollection.
2. topView := BrowserView new.
3. topView model: aBrowser; controller: StandardSystemController new; 4. label: labeistring asString; minimumSize: 300@100.
5. topView ađSubView:
6. (SelectionlnListView on: aBrowser printltems: false oneltem: false
7. aspect: #methodMenu change: #methodName lisfcmethodList
8. menu: #methodMenu initialSelection: #methodName)
9. in: (0@0.25 extent: 1@0.751 borderWith: 1. 10. topView ađSubView:
11. (CodeView on: aBrowser aspect: #text change: #acceptText:from
12. Menu: #textMenu initialSelection: sel)
13. in: (0@0.25 extent: l@0.75i borderWith: 1. 14. topView controller open.
Trong ví dụ trên, các hành động tuần tự là: K hởi tạo M odel [1], tạo to p v ie w [2], mô tả M odel và C ontroller [3] của topV iew và các thông số của nó [4], Thêm các s u b v ie w vào topV iew [5, 10] với các thông số được đặc tả trong [6-9, 11-13]. Cuối cùng là khởi động C ontroller của topV iew . Ở đây, các subVievv được xem là các plugable View.
11.2.4. Thành phần Controller
Trong m ột chương trình sẽ có nhiều C ontroller tương tác với nhiều View. Tuy nhiên, tại một thòi điểm chỉ cho phép m ột C ontroller được thực hiện. Để làm được điều này, Sm alltalk-80 bố trí các C ontroller theo kiến trúc hình câỵ Gốc của cây là đối tượng toàn cục S ch ed u led C o n tro llers. Nó là một C ontrollerM anager của toàn bộ ứng dụng. T iếp đến, S cheduledC ontrollers
được tách ra thành các mức C ontroller nhỏ hơn là topLevel (C ontroller của các cửa sổ) và các C ontroller cùa các subV iew . V iệc điều khiển của chương trình được thực hiện như sau: C ontrollerM anager xác định các C ontroller của
topVievv (topL evel) bằng cách sử d ụ n g phương thức
searchF orA ctiveC ontroller để gửi các thông điệp isC ontrolW anted đến tất các scheduledC ontrollers. Khi nó tìm thấy C ontroller của topLevel thích hợp, nó gửi thông báo sta rtu p . N ó gửi ba loại thông báo sau: s e l f controlllnitialize,
s e i f conirolLoop, s e i f controlTerminatẹ Phương thức controlLoop điều khiển luồng C ontroller như sau:
[seif iS ControlActive] whileTrue: [Processor yield. seif controiActivity]
s e if controlA ctivity chi ra: s e if controlT oN extLevel. Đ iều khiển được chuyền qua V ie w như sau:
aView := View subViewWantingControl. aView nil ifTrue: [aView Controller startUp]
N ó hỏi xem c ó su b V iew nào muốn điều khiển, nếu có Controller sè
được chuyển đến cho Controller cùa su b V iew đó. Phương thức
isC ontrolW anted đơn giàn trà về thông báo s e i f view H asC ursor tiếp đến là
view containsPoint: sensor cursorPoint. C uối cùng, C ontroller m ong muốn chính là C ontroller của subVievv chứa con trỏ chuột.
M od el và V ie w sẽ không thể liên kết với nhau nếu thiếu Controller. Tuy nhiên, trong m ột số trường hợp, chúng ta c ó thể m ong muốn một tập các su b V iew đư ợc điều khiển chung bởi một C ontroller tổn g hợp chứ không phải một C ontroller đ ộc lập cho m ồi sub V iew . T rong Sm allTalk có một Controller đặc biệt như vậy là N oC ontroller, lớp này đư ợ c đặc tả để bò đi Controller.
Trong trường hợp này, phương thức isC ontrolW anted của N oC ontroller luôn
trả về giá trị là falsẹ
11.2.4. Phối hợp các thành phần trong MVC
C ác thành phần M odel, V iew , C ontroller phải tương tác với nhau để tạo thành m ột ứng dụng hoàn chỉnh. Liên kết giữa V iew và Controller là trực tiếp vì V ie w và C ontroller được thiết kế để làm v iệ c vớ i nhaụ Trong khi đó, M odel c ó tính chất tương đối độc lập hơn. V iệ c phối hợp các thành phần trong M V C là rất quan trọng, do đó ngôn ngữ lập trình Sm allT alk-80 cung cấp sẵn m ột cô n g cụ gọi là “M V C Inspector” . C ôn g cụ này giúp người phát triển c ó thể kiểm tra và theo dõi hoạt động cùa từng thành phần trong M V C
cũng như v iệ c phối hợp giừa các thành phần đó.
11.3. Áp dụng MVC trong thiết kế các thành phàn Ja va Swing
11.3.1. Giới thiệu
Rất nhiều giao diện người dùng và các c ô n g cụ hồ trợ giao diện đồ họa sử dụng kiến trúc M V C làm mẫu thiết kế chinh để trình diễn, lưu trừ và duy