Learn all about the second version of the Java Portlet Specification (JSR ). In Version , the specification and the APIs more than doubled. The Java Portlet Specification addresses the requirements of aggregation, was approved by the Java Community Process in March as JSR This tutorial on JSR development provides an introduction to portlet programming as the reader is taken through the creation of a simple HelloWorld portlet.
|Published (Last):||24 April 2011|
|PDF File Size:||14.4 Mb|
|ePub File Size:||14.15 Mb|
|Price:||Free* [*Free Regsitration Required]|
Portlets are componentized user-facing applications that create some kind of markup. This markup is intended to be aggregated with other markup fragments into a larger application, for example, a portal page as shown in figure 1. View image at full size.
Portlets can therefore be viewed as user interface UI -based services that take the Service-Oriented Architecture SOA approach all the way up to the user interface. Since then, nearly all the vendors in the Java portal space, both commercial and open-source vendors, have implemented this standard, and developers have written portlets using the Java Portlet API.
The JSRhowever, stopped at defining the overall UI component model and did not define any means for building integrated composite applications out of these components. This limitation, and many other things that didn’t make it into Portler. The expert group of JSR consists of all the major commercial and open-source portal developers, portlet bridge developers, and portlet framework developers.
You can find a complete list of the members of the expert group here.
This article provides an overview of the main new features in JSR and some examples of how to leverage these features. This article assumes basic knowledge about the portlet programming model defined in version 1. The main new features of version 2. At development time, you define only the data that a portlet understands, and the actual connections between portlets are created specifivation deployment or runtime. Leveraging sprcification coordination features, portal administrators or business users can now build larger composite applications, out of portlet components without programming.
This capability opens the possibility to create new functionality by combining existing components into business mashups in a similar fashion to popular Web 2. JSR allows portlets to send and receive events.
Introduction to JSR / Portlet Specification ~ Liferay Savvy
As mentioned before, the model is a loosely coupled model where the portal application acts as broker between the different portlets and distributes the events.
Figure 2 depicts the details of how this distribution works. Portlet 1 defines that it can publish some event A in its portlet. Portlets 2 and 3 define that they are able to receive event A in their portlet. The portal administrator or business user has now put these three portlets on a page and created connections between the sending portlet Portlet 1 and the receiving portlets Portlet 2 and Portlet 3.
Now the user interacts with Portlet 1 and triggers an action on Portlet 1. As a result of this action, the portlet issues event A. After the portlet has finished its action processing the event broker component, which is typically part of a portal runtime, it looks for targets of this event.
What’s new in the Java Portlet Specification V (JSR )?
In our sample, there is a connection between Portlet 1 and Portlets 2 and 3 for this event. Thus, the event broker calls the processEvent life cycle method introduced with version 2.
After the action and event processing have finished, the rendering lifecycle starts and the portlets can create new markup based on the state updates that occurred porrlet the action and event phases. JSR does not specify how connections for portlet coordination are defined and managed. Typically, connections are defined explicitly at page creation time, or they are automatically inferred by the specirication at runtime. Specifiaction first approach allows more control and flexibility, while the second is easier to use.
In both cases, the portal needs to know what kind of events a portlet can receive and send. Therefore, you need speclfication provide this information in the portlet. How would you do this? First, you provide the general event definition, and then you reference this definition in the portlet section with tags that specify that the portlet can either receive or send this event. QNames are the mechanism for using unique names in XML; they also have a Java representation as the standard library class javax.
A QName consists of a namespace for example, http: You can specify a full QName for each event, or if you use the same namespace for many events, you can declare it as the default namespace and then specify only the local part of each event. Why do we need this additional JAXB serialization?
A portlet may want to send an event to specificafion remote portlet that is running using WSRP. These remote portlets may not be written in Java, and so we need a more general mechanism than the Java serialization. This detail was the hard part; now your work is getting simpler: To receive events you need either to extend GenericPortlet or to implement the EventPortlet interface yourself. Extending GenericPortlet has the additional advantage of being able to use annotations for potrlet special methods for handling events, processing actions, and rendering a specific portlet mode.
Public render parameters allow sharing of request parameters across different portlets or other artifacts, like themes or portal pages in IBM WebSphere Portal. Defining a public render parameter is very similar to defining an event: You specify a unique QName and optional alias names in the portlet. The QName and alias names are used to connect public render parameters of different portlets.
You can view these public render parameters as a shared storage area where all participating portlets can set and get the values.
Figure 3 depicts an example where a navigator portlet and a content portlet share the same public parameter docid. After you click a link in the navigator portlet that sets the docid to document3, the content portlet displays the content of that document because its view state the ID of the current document has been changed from an external influence.
Note that public render parameters can be stored in the URL, as in the WebSphere Portal implementation, and thus you can bookmark pages and use the browser’s Back and Forward buttons. How can the portlet get access to these public render parameters? In the portlet itself, you access the public render parameters with the same methods that are used to handle ordinary render parameters defined in version 1. Given that these methods take only Strings as keys and not QNames you need to define an identifier in the portlet.
In most cases, the portlet code does not actually need to change whether a render parameter is public or private, so you can enable your portlet for coordination by simply declaring those parts of the view state information in the portlet. If you want to specifically access only public render parameters in your code, then you can also use the method getPublicParameterMap on the request. In the first version of the Java Portlet Specification, you could not serve dynamically generated resources directly through the portlet.
Instead, you needed an additional servlet that served the resources. This limitation had some disadvantages:. One advantage of serving resources through a servlet is less overhead because the request does not have to pass through the additional portal framework, for example, when serving large media streams. Resource URLs trigger the lifecycle method, serveResource, on the ResourceServingPortlet interface that you can leverage to create dynamic resources directly in the portlet.
You must have a resource URL to trigger the new speciifcation life-cycle method.
Java Portlet Specification
Let’s start by looking into the details of the new resource URL. You receive these parameters in the serveResource call. Note that ResourceURLs cannot set new render parameters, portlet mode, or window state. This restriction occurs because serveResource calls do not generate a full new portal page, but return sppecification response of serveResource.
Thus, the portal does not have a chance to update other parts of the page where this information may be encoded; for example, in WebSphere Portal all URLs contain this epecification and so need to be updated. You can also set an additional resource ID on the resource URL that clearly identifies your resource. You can set the path to your resource asID, as shown here: In this case, GenericPortlet automatically dispatches to the given JSP, which can then make use of the portlet state information by including the portlet tag library.
Serving static resources using the portlet’s serveResource method causes unnecessary performance overhead. To receive a serveResource call triggered by a resource URL, you need to either implement the new ResourceServingPortlet or extend GenericPortlet, which already implements the new xpecification. The resource request has similar methods to the render request, but in addition it lets you get access to upload data.
In the resource request, the parameter handling lets you specufication access to three different types of parameters:.
The ordinary parameter access methods return the merged set specificaiton these three parameter maps. Parameters that have the same key first get the resource parameter values merged and then either the private or public render parameter values, depending on whether the parameter key was declared as a public render parameter in portlet. These state changes, though, should be limited to private state of the portlet: You should not modify state that affects other portlets because the portal framework does not have a chance to update other parts of the portal page for serveResource calls, so that updates to page-level state may not jjsr visible.
Render parameters, portlet mode, and window state fall into this category as some portal implementations, such as WebSphere Portal, store this information in the URL to support the ability to bookmark and the use of Back and Forward buttons in the browser.
This implementation means that changing a render parameter, for example, requires an update of all the URLs on the page, which the portal cannot perform, as the processing of the response data on the client is done entirely by the portlet. Because the markup returned from serveResource is not aggregated with other markup from the portal framework, the resource response allows full control over the output stream.
For example, the portlet specificatoin set a HTTP status code. There are many different use cases for serving resources; therefore, there are also different requirements for the ability to cache serveResource calls. This method gives a hint to the portal about how much information the target serveResource call requires.
Note that setting the cacheability of a resource response makes sense only if you allow the response to be cached by specifying HTTP caching headers for the returned response. This specification means that you must portlwt at least an expiration time using response. If the returned content is not user specific, you should additionally set the cache control to public scope. Full cacheable resources, which do not depend on interaction state. An example is a programmatically generated SVG view that depends on the portlet preferences for back-end access.
This setting means that the portal can generate a URL that does not contain any interaction state of the page and the portlets on the page. Thus, the browser can cache the returned markup of the serveResource call for at least as long as the user interacts with the current page. As a result of not encoding any state of the page and portlets on the page, you cannot count on getting the current render parameters, portlet mode, or window state in your portlet.
In summary, these cacheability levels give you the ability to provide as many hints about the cacheability as possible to the runtime. The runtime also can enhance the cacheability portlst resources in other ways, for example by keeping track of the state changes on the client and re-rendering only the parts affected by state changes. You had only the ability to provide an additional servlet that serves the Ajax fragment.