Portlet Development Coding Guidelines Portlet Development Best Practices and Coding Guidelines WebSphere Portal V5.1 Marshall Lamb Software Architect, IBM WebSphere Portal April 2006 1
Portlet Development Coding Guidelines Revision History April 24, 2006: Updated section G with more options for sharing data between applications. 2
Portlet Development Coding Guidelines Overview The portlet architecture is an extension to the Java Servlet architecture. Therefore, many aspects of portlet development are common to typical Web application development. However, the unique aspects of a portal add complexity to the application model, such as multiple portlets per Web page, portlet URL addressing, portlet page flow control, user interface rendering restrictions, and inter-portlet communication. Careful consideration needs to be given to the design of a portlet to take advantage of portal features instead of falling prey to its complexity. This document is a collection of best practices for portlet development, divided into major categories. It is intended to be used as coding guidelines when designing and developing portlets for IBM WebSphere Portal using the IBM Portlet API. It is not a primer for portlet developers as it does not address the fundamentals of portlet programming, nor does it treat any JSR 168 guidelines. Instead, use it as a checklist during design and code reviews to help promote consistent and quality portlet implementations. Be sure to refer to the WebSphere Portal InfoCenter and the Portlet Development Guide for more information on developing portlets. See Additional Information for links to these resources. Also see the paper entitled “Best practices: Developing portlets using JSR 168 and WebSphere Portal” for best practices and coding guidelines for JSR 168 portlets. Portlet Design Principles The correct portlet design is broken down into three distinct parts: the model, the view, and the controller (MVC). This design follows classical object oriented design patterns where each part is self-contained and modular, easing maintenance, extensions, and advancements. The model is the data to which the portlet provides an interface. Common data models are XML documents, database tables, and even other Web applications. The Java classes accessing the data model should have no knowledge of the form that the data is in, the idea being that the model can be changed without affecting the rest of the portlet application. The view is the interface to the data model, presenting it in some usable format. The view accesses the data to be rendered through the model interfaces and thus should not care what format the model takes. It should also not understand the relationships between data models or represent any of the business logic for manipulating the data. Like the data model, the view should be independent and interchangeable, allowing other views to be substituted without affecting the business logic or the model. The typical embodiment of the view is through series
You've reached the end of your free preview.
Want to read all 20 pages?
- Summer '19
- JavaServer Pages, IBM WebSphere