Portlet và Spring Portlet MVC

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ọ.

Hình H.1 : Ví dụ điển hình cho portal là iGoogle.

Đế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.
Hình H.2: Không có MVC framework, một portlet sẽ gánh thêm trách nhiệm chuyển request.

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ý.
Hình H. 3: Có MVC framework sẽ giúp ta điều hướng request dễ dàng.

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).
Hình H.4: DispatcherPortlet chuyển portlet request đến controller và view, dựa vào handler mapping và view resolver.

Đâ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.

Đọc tiếp >>

Cao Trong Hien

,

Khám phá Java: biến static trong inner class

Hôm nay tình cờ đọc một bài về một lỗi khó hiểu của Java. Có thể nó sẽ làm bạn đau đầu đây, cùng tôi khám phá nhé.

Click vô hình để phóng to


Ta có thể nhìn thấy 2 biến được khai báo, nhưng khác kiểu. Theo bạn thì ta đang gặp vấn đề gì vậy

Gợi ý nhé:
1.Nó sẽ đúng khi ta khai báo Object là String, nhưng array thì không.
2. Bạn sẽ bị báo lỗi sau khi dùng Eclipse:
The field OBJECT_CONST cannot be declared static; static fields can only be declared in static or top level types

Báo kiểu này chỉ làm ta rối mắt thêm thôi, vì biến integer dùng được mà.

Comment nhé. :-)

Đọc tiếp >>

Cao Trong Hien

Bill Gates ra đi: Chấm dứt một “đế chế” - p5


Là một cây gai trong mắt nhiều người, nhưng Gates một sức mạnh có thể tấn công nhiều cái đầu trong giới công nghệ, và đem họ đến với Microsoft.


Mộ nhân tài


Tim Paterson, người tạo ra QDOS, đến với Microsoft; Dave Cutler đến từ Digital Equipment Corp. dẫn đầu nhóm phát triển Windows NT; Jim Allchin, một kiến trúc sư cho công nghệ ảo, người làm ra hệ điều hành Banyan VINES, đến với Microsoft dẫn đầu sự phát triển; và khi Gates đang tìm kiếm một người nối nghiệp giám đốc phát triển phần mềm, ông thuyết phục Ray Ozzie, người đầu não trong Lotus Notes, vào vị trí đó.

Và trong khi Microsoft có rất nhiều địch thủ, chìa khóa thành công của công ty là một môi trường thân thiện cho nhân viên, và các chế độ khuyến khích nhân viên trong năm. Dường như sự giới hạn những thứ được cài đặt trong Windows đã đảm bảo các ứng dụng nhỏ, có thể lớn lên, và thu lợi nhuận, từ việc bán nó. Họ đã thu hút hơn 640,000 đối tác giải pháp toàn cầu, 4.3 triệu người có chứng chỉ công nghệ của Microsoft.

Dù gì thì Gates cũng đã ra đi: một sự tích hợp chưa từng có giữa tư duy công nghệ và đầu óc kinh doanh.

Nhưng đó là một công ty cần tìm một hướng đi mới, bất chấp sự dàn trải. Họ đang tìm đường để lấy lại thế cân bằng trong lĩnh vực Web 2.0 với Google –bằng việc thôn tính Yahoo – đã thất bại trước đó. Họ cũng đang hoàn thiện hệ điều hành tai tiếng Windows Vista, và đi đến cái mà họ gọi là Windows 7.

Nhưng nếu người nối nghiệp Gates, Steve Ballmer, đã học mọi thứ từ các mối quan hệ của Bill, mang một tính cách kiên trì và mạo hiểm, mọi thứ sẽ khác chăng?

Đọc tiếp >>

Cao Trong Hien

,

Bill Gates ra đi: Chấm dứt một “đế chế” - p4


Internet bắt đầu chỉ là sự liên hệ giữa một máy desktop và hệ thống server, Gates đã phát hiện và ưu tiên số một cho hệ thống này trong chuỗi từ “Internet Tidal Wave”, đưa ra năm 1995, và yêu cầu nó phải đi sâu vào mọi hoạt động của công ty.


Độc quyền


Đi trên con đường mà Gates và Microsoft gần như đánh mất. Vì vậy, sự thi hành có vè không ổn, và nhiều lỗi. Và một lần nữa, Gates đi vào thị trường khi mà mình không phải là người tiên phong, chỉ phát triển vì thương hiệu, và tránh bị chi phối.

Trong khi đó, Gates đang nắmg giữ cái mà Brynjolfsson gọi là “kinh tế thông tin” rất tốt mà sự độc quyền của Windows là một minh chứng, một cuộc điều tra bắt đầu.

Không chỉ bán nhiều sản phẩm trong một gói, họ còn tích hợp cả các chương trình ứng dụng (IE) vào Windows, là một bước đánh vào công ty đi đầu trong lĩnh vực này là Netscape Navigator. Đó cũng là lúc cuộc điều tra độc quyền bắt đầu giữa những năm 1990.

Kết quả là Microsoft bị kiềm chế trong suốt một năm.

Gates đã nhanh chóng biến những chàng David trở thành một đối thủ xứng tầm của Goliath của IBM, tạo ra một danh sách dài các đối thủ, bao gồm IBM, Lotus, Novell và Sun. Điều hành của các công ty này là các tác nhân mà Gates có các hành động mang tính sống còn. Dẫn đến cuộc điều tra độc quyền, mà người thực hiện là Thomas Penfield Jackson, người đã yêu cầu Gates và công ty ông ta để đối chất về các cáo buộc. Nhưng trớ trêu thay, sự thật bị đảo lộn, và vụ kiện này không có kết quả. Rồi kể từ đó Microsoft liên tục dính vào các vụ kiện chống độc quyền với Time Warner, Sun Microsystems, RealNetworks và Be...

"Các vụ xử độc quyền thường được giải quyết bằng hình phạt phân rã công ty.

Năm 1911, Công ty dầu Standard Oil bị buộc tội độc quyền khi mua các đối thủ và ép các công ty hỏa xa mua dầu của mình.

Ở thời điểm đó, Standard Oil của ông trùm John D. Rockefeller chiếm đến 90% thị phần Mỹ (gia sản Rockefeller năm 1911 là 900 triệu USD - hơn 2% GNP của Mỹ - trong khi ngân sách liên bang Mỹ năm đó chỉ có 750 triệu USD!).

Cuối cùng, Standard Oil bị chia thành 34 công ty con mà những kẻ sống sót nay đã trở thành các công ty dầu lớn nhất thế giới như Exxon, Mobil, Chevron và Amoco.

Năm 1911, Mỹ cũng xử tội độc quyền Công ty thuốc lá American Tobacco, chiếm 95% thị phần Mỹ.

Kết quả, American Tobacco biến thành 16 công ty mà hai kẻ sống sót hiện nay đã nổi danh là R.J. Reynolds và British American Tobacco."
Theo FIRST NEWS


Bài cuối: Mộ nhân tài

Đọc tiếp >>

Cao Trong Hien

Bill Gates ra đi: Chấm dứt một “đế chế”-p3


Với Windows, Gates đề nghị dùng Microsoft Office, một gói ứng dụng bao gồm Word, Excel và PowerPoint. Với chiến lược đó, Brynjolfsson cho rằng, là chìa khoá thành công trong CNTT của Microsoft.

Đưa ra phiên bản đầu tiên luôn khó khăn và tốn kém nhất, nhưng các phiên bản tiếp theo thì sẽ rất dể dàng. Một nhà cung cấp thường gia tăng lợi thế bằng cách cung cấp nhiều sản phẩm cùng nhau. Và chiến lược này chỉ làm việc tốt khi chúng có giao diện tương đồng,là một khối không thể tách rời, và đó là cách làm của các ứng dụng Microsoft.

“Việc bán từng sản phẩm tách rời thường không đem về lợi nhuận lớn, nhưng gộp chúng lại sẽ làm người mua cảm thấy thích thú hơn,” Brynjolfsson nói. “Nó đem đến cho Gates một lợi nhuận khổng lồ. Mặc dù có một sản phẩm tốt hơn, nhưng phần lớn mọi người thích một gói đồng nhất, và đó là lý do họ mua Microsoft Office.”

Cách làm này làm tăng thị phần một cách tốt nhất và đem lại lợi nhuận. “Giống như một bữa ăn của McDonald,” Brynjolfsson giải thích.

Kết quả: “Giá của các sản phẩm Microsoft thường thấp hơn các đối thủ với cùng một tính năng,” ông ta nói. “Tôi nghĩ đóng góp lớn nhất của Bill Gates là những kiến thức về kinh tế. Điều mà phần lớn đối thủ không có.”

Sự phát triển thần kỳ và lợi nhuận khổng lồ đã làm cho Microsoft trở thành một tổ chức có tài chính vững mạnh hơn tất cảc các đối thủ. Gates đấu tranh một cách tàn nhẩn, đảy nhiều công ty đến bờ phá sản.
Nhưng Gates đã không thấy trên lĩnh vực Internet, xuất hiện đầu những năm 1990, có thể làm thay đổi cả một ngành công nghệ phần mềm.

Bài 4: Độc quyền

Đọc tiếp >>

Cao Trong Hien