Hiendt's Weblog

Và khi portal ra đời. Không theo chuẩn xây dựng website đang có, nó có thể thấy nhiều ứng dụng chỉ trong một trang portal. Không những thế, portal còn phục vụ cho sở thích, quyền hạn của người dùng. Nghĩa là mỗi người dùng sẽ có một phiên bản khác, được thiết kế cho riêng họ.

Lịch sử hình thành Portlet

“Thinks outsite the box” – Hãy suy nghĩ ra khỏi giới hạn

Mặc cho lời khuyên này, chúng ta vẫn thường xuyên “suy nghĩ trong giới hạn”. Hollywood Square, bưu điện, niên giám của các trường đại học, game sodoku là những thứ mà ta có thể thấy được về vấn đề “suy nghĩ trong giới hạn”. Vậy chúng ta mong chờ gì về việc này khi mà chúng ta thường xuyên đối diện với các giới hạn này?

Việc suy nghĩ này ta gặp thường xuyên nhất là với các hệ điều hành như Microsoft Windows hay Mac OS. Hãy nhớ lại những ngày mới ra MS-DOS, ta chỉ có thể chạy một ứng dụng tại một thời điểm. Nhưng các thế hệ của nó sau này, không những có thể chạy nhiều ứng dụng một lúc, mà ta còn có thể nhìn thấy chúng cùng lúc.

Một ứng dụng web cũng như một ứng dụng chạy trên MS-DOS, chỉ có thể tương tác trên một ứng dụng tại một thời điểm. Nếu muốn muốn dùng một ứng dụng web khác, bạn phải dừng ứng dụng này, và truy cập đến ứng dụng đó, trên một cửa sổ mới(hay tab mới).

Và khi portal ra đời. Không theo chuẩn xây dựng website đang có, nó có thể thấy nhiều ứng dụng chỉ trong một trang portal. Không những thế, portal còn phục vụ cho sở thích, quyền hạn của người dùng. Nghĩa là mỗi người dùng sẽ có một phiên bản khác, được thiết kế cho riêng họ.


Đến khi Sun công bố Java Portlet Specification (JSR 168), là lúc bắt đầu một xu hướng xây dựng portlet. Đó là một tiêu chuẩn dể xây dựng, và phát triển portlet với java. Nói một cách ngắn gọn, nó định nghĩa các quy ước giữa những portlet, và cách nó tương tác với portal server.

Trong bài viết này, chúng ta sẽ có một cái nhìn đầu tiên về Spring Portlet MVC, một công cụ giúp ta xây dựng ứng dụng dựa trên chuẩn của Java Portlet API.

Mặc dù Spring Portlet MVC là một thành phần riêng biệt với Spring MVC, nhưng chúng chia sẽ những tính năng tương tự nhau. Thực tế, khi làm việc với nó, bạn sẽ thấy rằng chúng có một sự tương đồng, và Spring Portlet MVC còn dùng lại một số class trong Spring MVC. Vì vậy, sẽ rất dễ dàng nếu như bạn có một kiến thức nhất định về Spring MVC.

Bạn cần một kiến thức cơ bản về Java Portlet Specification và biết cách xây dựng một portlet đơn giản. Nếu bạn mới đến với Java Portlet , hay đơn giản là chỉ muốn tìm một cái gì mới, tôi nghĩ bạn nên đọc quyển Portlets and Apache Portals (Manning, 2005) hay Building Portals with the Java Portlet API (Apress, 2004).

Suy nghĩ trong giới hạn

Có nhiều điểm tương đồng giữa Portlet và Servlet. Ta có thể thấy ngay như sau:
Một Servlet được viết bằng cách implements javax.servlet.Servlet hay thông dụng hơn là extends từ javax.servlet.http.HttpServlet. Tương tự, một portlet cũng được viết bằng cách implement javax.portlet.Portlet hay extends từ javax.portlet.GenericPortlet.
Khi implement từ javax.servlet.Servlet , phương thức cần implement là service(). Khi implements từ javax.portlet.Portlet , có 2 phương thức cần implement là processAction() , và render().
Nếu bạn chọn mở rộng từ javax.servlet.http.HttpServlet , bạn cần implement doGet(), doPost(), doPut(), hay doDelete() để xử lý request. Với javax.portlet.GenericPortlet bạn cần implement doView(), doEdit(), hay doHelp() để xử lý portlet request.

Và cũng có nhiều điểm khác nhau :
Servlet có đầu ra là một trang web, và chiếm hết diện tích của trình duyệt. Portlet thì ngược lại, nó phải chia sẽ trang với các portlet khác.
Một portlet có thể có nhiều modes. Phần lớn những chức năng của portlet đều nằm trên view mode. Nhưng một portlet có thể cung cấp edit mode để cấu hình portlet, help mode cung cấp thông tin trợ giúp người dùng. Ngược lại, servlet không có khái niệm modes, mà chỉ có view mode.
Vòng đời của portlet request phức tạp hơn servlet. Trong khi servlet chỉ xử lý một kiểu request, portlet xử lý cả ActionRequests và RenderRequests.

Tại sao Portlet cần MVC?

Dùng MVC Frameworks (Struts hay Spring MVC) cho ta một cách tương tác tốt khi phát triển một ứng dụng web với servlet, nhưng ta cũng có thể xây dựng mà không dùng chúng. Vì một ứng dụng servlet có thể dễ dàng chuyển trang, hay gọi một chức năng khác. Nhưng khi một ứng dụng chỉ muốn một servlet có thể điều khiển tất cả các tính năng, thì không thể xây dựng bằng servlet được.
Một ứng dụng portlet thì khác. Nó có thể có nhiều portlet chỉ chứa trong 1 portal view. Nó chỉ có thể render trong space mà nó đang quản lý, còn việc dùng một portlet khác trong space của nó thì không thể.
Nếu bạn đang xây dựng một portlet đơn giản, như dự báo thời tiết, RSS view hay một portlet chỉ có 1 đến 2 view, thì bạn chẳng cần một MVC.
Nhưng nếu không dùng MVC, viết một ứng dụng hướng tính năng thì có thể làm bạn nản. Như bạn thấy trong hình H.2, phương thức processAction() và render() có thể trở thành một mớ những if/else để có thể điều hướng các thao tác trên portlet.

Khi có MVC, bạn có thể thấy trong hình H.3, một controller portlet có thể điều khiển các reequest đó, và gởi chúng đến một controller thích hợp để xử lý.

Một cách ngắn gọn, ứng dụng portlet cần MVC framework để điều khiển những tính năng phức tạp. Nhưng chúng ta tìm chúng ở đâu?

Spring Portlet MVC

Nhận thức được sự cần thiết của Portlet MVC Framework, Spring đã đưa Spring Portlet MVC (SPMVC) vào Spring 2. SPMVC được viết dựa trên Spring MVC Framework để xây dựng ứng dụng portlet. Dùng SPMVC, chúng ta có thể xây dựng một ứng dụng web hướng tính năng, chỉ chạy trên space của portlet mà portal cung cấp.

Về vòng đời của portlet request trong SPMVC thì không khác gì so với Spring MVC. Như bạn thấy trong hình H.4, trạm dừng đầu tiên của một portlet request là DispatcherPortlet(1). DispatcherPortlet làm việc gần giống như DispatcherServlet, là chuyển quyền thực hiện đến controller.

Handler Mapping(2) cho biết controller nào sẽ chịu trách nhiệm xử lý request này. Portlet Handler Mapping cũng tương tự như Spring MVC Handler Mapping, thay URL bằng Map Portlet Modes trong controller.

Một controller thích hợp được chọn, DispatcherPortlet gởi request thẳng đến controller đó để xử lý (3).

Đây là nơi mà vòng đời của portlet request bắt đầu. Nhớ rằng có 2 kiểu của request là action request và render request. Nếu là 1 action request, vòng đời của nó được chuyển qua controller để xử lý. Nhưng nếu là render request, thì cần một số trạm xử lý khác.

Để xử lý một render request, controller sẽ trả về một đối tượng(object) ModelAndView cho DispatcherPortlet. Nó sẽ dùng cùng một ModelAndView với Spring MVC controller. Nó sẽ chứa tên của view được trả về cùng với một số dữ liệu cần để view.

Tại đây, DispatcherPortlet đã có tất cả những thứ cần để thể hiện lên portpet. Nhưng đầu tiên, nó cần tìm trang thể hiện bằng cách gọi đến view resolver(5).

Bước cuối cùng cho một render request trang view(có thể là JSP). View sẽ dùng dữ liệu trong request để view trong portlet space, của portal page.

Với những kiến thức trên, bạn đã có thể làm một ứng dụng portlet đầu tiên dùng SPMVC.