Portlets are not the solution to every design challenge. Here are a few things that portlets do not do well:
* Complex user interfaces do not translate well to portlets. The markup languages like HTML and WML simply cannot describe some interfaces. Try to imagine implementing an integrated development environment (IDE) like Eclipse or Visual Basic in HTML and you'll have the idea. Native applications and Java applications work better for this. (If you have a complex user interface and still want to take advantage of the benefits of portlets, WebSphere Portal does support Struts, which can be very helpful.)
* User interfaces with data that must be constantly updated are also not portlet material. When you update one portlet, all portlets on the entire page must be re-drawn, so it is generally not a good practice to have your portlets automatically reload themselves with new data. On the other hand, you can have "refresh" option in the portlet so your users can choose when to reload the page. You cannot be sure how often users will choose to refresh the page, so if your data must not be out-of-date, use a native application or a Java application instead of a Web application.
* Highly interactive user interfaces do not translate well to Web applications in general, or portlets in particular. If you want your interface to change automatically when a user takes some action, like selecting an entry in a drop-down list, you can either submit the form and reload the entire page (annoying), or use a scripting language to re-draw the portlet (very difficult). If you use a scripting language, you will need to make sure it works for all of the devices you want to support, and you will also need to make sure your portlet still works if scripts are disabled by some of your users. For mobile devices, you will probably need to have alternate JSP pages that do not use scripts. Native applications or Java applications are easier to make highly interactive than are Web applications.
* Portlets need to live "within their box." Be careful if you have a link in a portlet that takes you to a Web page outside of the portal server environment, because it is difficult to get back to the portal after that. Frames are not allowed (Internal frames are allowed, but only Microsoft Internet Explorer users can see them). Pop-up windows and scripts usually cannot be used for mobile devices. If you can't make your application fit into the portal framework, don't make it into a poorly-behaved portlet.
* If you will want to provide services to other applications, consider writing a Web service first. Once you implement a Web service, you can write a portlet to use it, and you can publish the Web service to share it with other applications. The stock portlet is a good example: the stock quote service should be a Web service that the stock quote portlet and other applications can use. In this case, you might also write a program that automatically sends users a text pager message when a stock reaches a certain price.
* If the company does not have a portal server yet, and does not plan to invest in one immediately, one can go ahead and implement the application as a servlet using JSP pages for the output. One can always convert it to a portlet later.
Filed in: WPS
Post a Comment