The Portlet Deployment Descriptor editor opens. Select the Portlets tab, and then select the portlet from the Portlets list box. Then click on the section that contains the values you want to edit. Caching content helps improve the Portal response time for users. It also helps to reduce the load on servers. The Portlet Specification defines an expiration based caching mechanism.
|Published (Last):||10 September 2013|
|PDF File Size:||10.72 Mb|
|ePub File Size:||11.23 Mb|
|Price:||Free* [*Free Regsitration Required]|
With the emergence of an increasing number of enterprise portals, various vendors have created different APIs for portal components, called portlets. This variety of incompatible interfaces generates problems for application providers, portal customers, and portal server vendors. To overcome these problems, JSR Java Specification Request , the Portlet Specification, was started to provide interoperability between portlets and portals.
JSR defines portlets as Java-based Web components, managed by a portlet container, that process requests and generate dynamic content. Portals use portlets as pluggable user interface components that provide a presentation layer to information systems. The list of official supporters is even longer. In this article, we first define portals and portlets, then explain the concepts JSR introduces, including the API's basic objects. Next, we dive into the JSR's more advanced functions, such as user information, localization, and caching.
We then cover the extension points that allow portal vendors to extend the currently defined functionality in the portlet specification. The article concludes with the description of portlet application packaging and deployment. In this section, we explain the basic definitions used in the portlet specification, including a portal's basic architecture, the portlet container, and a portal page. A portal is a Web-based application that provides personalization, single sign-on, and content aggregation from different sources, and hosts the presentation layer of information systems.
Aggregation is the process of integrating content from different sources within a Webpage. A portal may have sophisticated personalization features to provide customized content to users.
Portal pages may have different sets of portlets creating content for different users. Figure 1 depicts a portal's basic architecture. The portal Web application processes the client request, retrieves the portlets on the user's current page, and then calls the portlet container to retrieve each portlet's content.
The portlet container provides the runtime environment for the portlets and calls the portlets via the Portlet API. Figure 2 depicts the basic portal page components. The portal page itself represents a complete markup document and aggregates several portlet windows.
In addition to the portlets, the page may also consist of navigation areas and banners. A portlet window consists of a title bar with the portlet's title, decorations, and the content produced by the portlet. The decorations can include buttons to change the portlet's window state and mode we explain these concepts later. As mentioned above, a portlet is a Java-based Web component that processes requests and generates dynamic content. The content generated by a portlet is called a fragment, a piece of markup e.
A fragment can be aggregated with other fragments to form a complete document, as shown in Figure 3. A portlet's content normally aggregates with the content of other portlets to form the portal page. A portlet container manages a portlet's life cycle. Usually, users interact with content produced by portlets by, for example, following links or submitting forms, resulting in portlet actions being received by the portal, which then forward to the portlets targeted by the user's interactions.
The content generated by a portlet may vary from one user to another depending on the portlet's user configuration. A portlet container runs portlets and provides them with the required runtime environment. A portlet container contains portlets and manages their life cycles.
It also provides persistent storage mechanisms for the portlet preferences. A portlet container receives requests from the portal to execute requests on the portlets hosted by it. A portlet container is not responsible for aggregating the content produced by the portlets; the portal itself handles aggregation.
A portal and a portlet container can be built together as a single component of an application suite or as two separate components of a portal application. This section explains the basic programming concepts in JSR , such as a portlet's life cycle, interface, and modes and window states, as well as session access, persistent storage access, and how to include servlets and JSP pages.
The portlet container manages the portlet life cycle and calls the corresponding methods on the portlet interface. Every portlet must implement the portlet interface, or extend a class that implements the portlet interface. The portlet interface consists of the following methods:.
A portlet mode indicates the function a portlet performs. Usually, portlets execute different tasks and create different content depending on the functions they currently perform. A portlet mode advises the portlet what task it should perform and what content it should generate. When invoking a portlet, the portlet container provides the current portlet mode to the portlet.
Portlets can programmatically change their mode when processing an action request. A window state indicates the amount of portal page space that will be assigned to the content generated by a portlet. When invoking a portlet, the portlet container provides the current window state to the portlet. The portlet may use the window state to decide how much information it should render.
Portlets can programmatically change their window state when processing an action request. In addition to these window states, JSR allows the portal to define vendor-specific window states. A portlet can be called in any of these three window states, but is free to produce the same markup for all three states.
The portlet can store persistent data for a specific user by using the PortletPreferences object. Preferences can be read and written in the action phase, and read in the render phase. The preferred mode to write preferences is the Edit mode, which provides the user with a customization screen.
The preferences can be either strings or string array values associated with a key of type string. Preferences can be preset with default values in the deployment descriptor. Preferences and the portlet's definition in the deployment descriptor together define a portlet, sometimes called a portlet entity. As portlet applications are Web applications, they use the same session as servlets.
To allow portlets to store temporary data private to a portlet, the default session scope is the portlet scope. In this scope, the portlet can store information needed across user requests and specific to a portlet entity. Attributes stored with this scope are prefixed in the session by the portlet container to avoid two portlets or two entities of the same portlet definition overwriting each other's settings.
In addition to the portlet session scope, JSR supports the Web application session scope. In this scope, every component of the Web application can access the information. The information can be used to share transient state among different components of the same Web application e.
To support the Model-View-Controller pattern, the portlet must be able to include content generated from servlets and JSP pages. This way, the portlet can act as controller, fill a bean with data, and include a JSP page to render the output. Via the portlet context, a request dispatcher is retrieved for a given path; the include method is then called on this request-dispatcher object:. WSRP services are presentation-oriented, user-facing Web services that plug and play with portals or other applications.
They let businesses provide content or applications without requiring any manual content- or application-specific adaptation by consuming portals; portals can easily aggregate WSRP services without programming effort.
The following list overviews how much the major concepts have been aligned between both standards:. Currently, JSR is in public review and the final version is planned for September Read the whole series on the Portlet Specification:. Inheritance versus composition: How to choose. Get started with lambda expressions in Java. Tutorial series: Android Studio for beginners. What is JPA?
Introducing the Portlet Specification, Part 1
We will then refactor and extend the Portlet to see how some of the patterns of Servlet development might be used. It is assumed that the reader is familiar with Java, Web applications, and Maven. We will be building a Portlet which will display random quotes by random authors. Maven 2. Note that the CSS class definitions would be provided by the Portal.
Using the Sample JSR 168 MicroStrategy Portlet "As Is"
The Java Portlet Specification defines a contract between the portlet container and portlets and provides a convenient programming model for Java portlet developers. Portlets are pluggable user interface software components that are managed and displayed in a web portal , for example an enterprise portal or a web CMS. A portlet can aggregate integrate and personalize content from different sources within a web page. A portlet responds to requests from a web client with and generates dynamic content. Typically, following the desktop metaphor , a portal page is displayed as a collection of non-overlapping portlet windows, where each portlet window displays a portlet. Hence a portlet or collection of portlets resembles a web-based application that is hosted in a portal.
When to use JSR 286 vs JSR 168 for portlets
With the emergence of an increasing number of enterprise portals, various vendors have created different APIs for portal components, called portlets. This variety of incompatible interfaces generates problems for application providers, portal customers, and portal server vendors. To overcome these problems, JSR Java Specification Request , the Portlet Specification, was started to provide interoperability between portlets and portals. JSR defines portlets as Java-based Web components, managed by a portlet container, that process requests and generate dynamic content.
JSR-168: The Portlet Specification
Some confusion exists in the portlet development community, because many vendors tout their compliance with JSR standards and less rarely talk about JSR compatibility. I think this is mostly due to the fact that prior to JSR becoming mainstream, the standards were loose and vendors built to their own specifications. So becoming compliant with JSR was and still is a big deal. In addition, while the JSR spec has been out since , it took the Portal vendors some time to update their Portal Servers to support the new standard.