Portlet

from Wikipedia, the free encyclopedia
Portlet
Current  version : JSR-286   (July 2006)

Portlets are freely combinable components of a user interface that are displayed and managed by a portal server . They generate fragments of HTML code and insert themselves into a portal page. A portal page typically consists of many, non-overlapping portlet windows (“tiles”), in each of which a portlet is executed. Examples of portlets are e-mail , weather reports , discussion forums, or news .

concept

A portlet is an extension of the servlet , as the portlet container (eg. Pluto ) is an extension of the servlet container (eg. Tomcat ). On the client side, portlets form an easy-to-use interface within the browser (window with buttons for maximizing, minimizing, editing, help). Any application can now be located internally, i.e. on the server side, which forwards its display to the portlet. They thus correspond to a "view" within the framework of the MVC concept.

Standards

Portlets are usually written for a specific portal server and can then only run on this without any code changes. However, there are efforts to create a standard; the most important is the Java Portlet Specification JSR -168 . Portlets according to JSR-168 can be executed on all portal servers that support this standard.

Portlet Specification (JSR-168)

On January 29, 2002, the JSR-168 was submitted, which is to standardize an API for portal applications . The trial was led by Alejandro Abdelnur ( Sun ) and Stefan Hepper ( IBM ). The initial Expert Group consisted of the Apache Software Foundation , BEA , IBM and Sun Microsystems. Supporters of the JSR were originally Accenture , the Apache Software Foundation, BEA, Boeing , Borland , Bowstreet , Capgemini , Citrix , DaimlerChrysler , Documentum , Enformia Ltd , Epicentric , Hewlett-Packard , Interwoven , Macromedia , McDonald Bradley , Oracle , Plumtree , SAP , Silverstream , Sybase , Tarantella, Inc. and Vignette . Hewlett-Packard later left, but Novell was added and Martin Scott Nicklous took over the maintenance lead .

The Community Review took place from April 16 to June 23, 2003 after almost one and a half years. The Public Review began on July 17, 2003 and ended on August 16 and resulted in publication on October 27, 2003. The JSR 168 represents one of the most important milestones in the history of portals. It paved the way for portlets to be developed independently of the portal used. This gives customers the ability to write applications without being tied to a provider. Even if this idea is not consistently enforced by all portal manufacturers, the JSR-168 has meant that there are now many standard portlets that offer standardized functionality regardless of the portal used and that come onto the market from many third-party providers.

The Portlet API 1.0 documented in JSR-168 contains 12 classes and 14 interfaces. Of the 12 classes, eight are exceptions. The specification standardizes the interaction between portlet containers and portlets.

history

Portlet API (JSR-162)

With the Java Specification Request 162, IBM laid the foundation for a standardization of a portal API . The JSR 162 was handed over to the Java Community Process on January 8, 2002 . In the formulation of the request, a standard was required that should be based on the existing Java Servlet standard. This should be expanded so that the portlets are no longer seen as individual pages like servlets, but rather that pages are made up of several portlets that share a uniform appearance and have certain basic functionalities in common.

On January 20, 2002, this JSR was withdrawn.

Java Portlet Specification (JSR-167)

Just a week after IBM submitted a proposal for a portlet API with the JSR-162, Sun followed suit itself and brought its own request for a portlet specification into the process. This was supported by the biggest competitors IBMs. These included BEA , Plumtree, Vignette and Sybase . Interestingly, the parts of a portal were also referred to here as portlets.

This request was also withdrawn on January 20, 2002.

Portlet Specification 2.0 (JSR 286)

In July 2006, the Early Draft 1 for Portlet Specification 2.0 was published, and the final version was approved on June 12, 2008. The additions mainly focus on the communication between portlets, the so-called inter-portlet communication (IPC). A portlet should be able to send an event to any portlet on the portal page. Events are processed in an additional phase of the portlet life cycle: the processEvent phase. It takes place before the render phase and after the processAction phase. An event can be sent by calling the setEvent method of the EventResponse interface. It can be called from the methods processAction and processEvent. Events can be defined in the deployment descriptor and processed in the processAction method of the EventPortlet interface. Alternatively, the implementation of the GenericPortlet can be used to process events. To do this, the method that is to receive an event must be marked with a special annotation .

An example for processing an event using a method marked with annotation. 

     @ProcessEvent(Retention=RUNTIME, name="com.acme.foo")
     public void processFoo(EventRequest request, EventResponse response) throws
                             PortletException, java.io.IOException {
          //process event foo
     }

An example of processing an event that was defined in the deployment descriptor. 

     <event-definition>
          <name>com.acme.foo</name>
          <java-type>java.lang.String</java-type>
     </event-definition>
     ...
     <portlet>
          ...
          <supported-processing-event>
               <name>com.acme.foo</name>
          </supported-processing-event>
          ...
     </portlet>


     void processEvent(EventRequest req, EventResponse resp)
     {
          ...
          Event event = req.getEvent();
          if ( "com.acme.foo".equals(event.getName() ) )
          {
               String payload = (String) event.getValue();
               ...
          }
     }

Portlet Specification 3.0 (JSR 362)

In March 2013, work began on the third portlet specification. Completion was planned for the end of 2014, in fact the specification was completed in April 2017. The following changes have been implemented:

  • Specifying how resources can be shared between portlets
  • Optimized support for JavaServer Faces via JSR 378
  • Alignment with JEE-7 specifications, Servlet 3.1
  • Explicit render state
  • CDI 1.2 integration
  • Portlet Hub & XHR IPC

Web links

Individual evidence

  1. ↑ JSR 168
  2. ↑ The Java Community Process (SM) Program - JSRs: Java Specification Requests - detail JSR # 168. Original Java Specification Request (JSR). In: jcp.org. Retrieved January 18, 2014 .
  3. ↑ The Java Community Process (SM) Program - JSRs: Java Specification Requests - detail JSR # 168. Updates to the Original Java Specification Request (JSR). In: jcp.org. February 6, 2009, accessed January 18, 2014 .
  4. ↑ JSR 362: Portlet Specification 3.0 .
  5. ↑ Martin (Scott) Nicklous: Portlet Specification 3.0 is Here! . IBM. September 2016.