A short summary of JSR Portlet Specification JSR Enhancements and new features for serving non-html resources (pdf, doc, images etc.). Specification Leads. Martin Nicklous, IBM. Expert Group. Adobe Systems Inc.: Ed Solovey, Adobe Systems Inc.: James Ward, BEA Systems: Subbu Allamaraju. 1. Agenda. • JSR 2. • JSR – What Is Missing? • JSR • Portlet Events. 28 JSR defines a portlet specification with the following goals: – Simple . Portlet acts as a proxy to a resources, e.g. PDF documents. – Portlet.
|Language:||English, Spanish, Arabic|
|ePub File Size:||21.39 MB|
|PDF File Size:||11.58 MB|
|Distribution:||Free* [*Sign up for free]|
JSR Schedule. Kick-off: Feb Early draft 1: Aug Early draft 2: April Public draft: July Final draft: Dec Approved: Mar Size of specification. Required Files. File Description and Name, Size. JSR Portlet Specification schema musicmarkup.info, KB. JSR Portlet Specification JSR Portlet Specification for Portal and Portlet Developers. JSR Portlet serving non-markup resources .pdf,.doc, images etc.) ○ portlet filters. ○.
Section 2: Request 2. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions. The new Portlet Specifications will add functionality that was not addressed in the first version specification, other JSRs were not final at the time JSR went to public review e. J2EE 1. These areas were not addressed in the first version of the Portlet Specification. Version 2. To be determined by the expert group, initial target is to have a working EG by December , a early public draft beginning of , a public draft by mid and a final version by end of
Generally if any portlet is have in action page other portlet need to render the portlet within the page. With the help of Ajax we can avoid render all portlets in page. We simply send Ajax call from portlet so that we can communicate with server then get the response. In JSR was added another feature called serving resources with help of this we can serve the images, pdf and other content types to client.
This method also used specially for Ajax call in portlet, to call this method we will use different URL i.
Generally in the portlet transition state will always change from Action Phase to Render Phase when we perform actions. Portlet Filter and Listeners We can portlet related filters and Listeners in portlet portlet. This will add advantage to perform some events or some actions before portlet is rendered. Direct copy will result in parse errors. Comment 1 Override the doView method as in the first tutorial.
Comment 2 This entry attempts to obtain the value of the render parameter named yourname.
If defined it should redirect to the hello. Comment 3 Get a request dispatcher on a file located within the web archive. Comment 4 Perform the inclusion of the markup obtained from the JSP. These modes need to be defined in the portlet. This will enable the corresponding buttons on the portlet's window. The generic portlet that is inherited dispatches the different views to the methods: doView , doHelp and doEdit. Portlet calls happen in one or two phases.
Listing 1 shows a sample. Listing 1. Why do we need this additional JAXB serialization? A portlet may want to send an event to a 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: receiving and sending events through your portlet. 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 denoting special methods for handling events, processing actions, and rendering a specific portlet mode.
Listing 2 shows a sample. Listing 2. 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. Public render parameter coordination example View image at full size 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. Serving resources 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: You do not have the portlet context available, which means you have no access to render parameters, portlet mode, window state, portlet preferences, portlet session, and more. URLs generated in the servlet are outside the portal scope and leave the portal experience. In addition, the current state of the portal page accumulated in the portal URL is lost.
The servlet does not run under the portal access control and needs to be secured separately. 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.
Version 2. Resource URLs trigger the lifecycle method, serveResource, on the ResourceServingPortlet interface that you can leverage to create dynamic resources directly in the portlet. 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 the 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 information 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: url.
Serving resources 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 interface.
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 have access to three different types of parameters: Resource parameters set on the resource URL that are available only for this resource call, accessible through the getPrivateParameterMap call Private render parameters of the portlet, accessible through the getPrivateRenderParameterMap Public render parameters, accessible through the getPublicParameterMap call The ordinary parameter access methods return the merged set of 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: portlet-scoped session data and portlet preferences.
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 be visible. NOTE: 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 can set a HTTP status code.
Caching levels of resources 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 set 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. JSR supports the following scenarios: 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. Keep in mind that because of the missing state information, you are restricted in the output of serveResource: You can include only resource URLs that are fully cacheable, and you cannot include action or render URLs.
Portlet-level cacheable resource that depends on portlet interaction state, for example, a dynamically generated PDF output of the current portlet view. If you need to have access to the portlet state, for example the render parameter, portlet mode, or window state, but you are not going to put action or render URLs in your response or in later responses, you set the cacheability level to PORTLET.
This level allows refreshing the resource for each interaction with the portlet, but also allows using the cached resource when interacting with other portlets on the page. Page-level cacheable resources such as resources providing action or render URLs, for example, the markup returned for an Ajax call. PAGE-level cacheability is the default setting. You have no restrictions in your serveResource method, which means that you can generate action or render links.
It also means that your resource cannot be cached across any interaction with the portal page that changes a part of the state of the page. 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 of 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. Using Ajax In version 1. This servlet, however, was then addressed directly and not through the portal framework, so it did not have the portlet state provided, nor was it under the security protection of the portal, as you can see in figure 4.
The only way to share data between the portlet and the servlet is to use the application-scope session or the parameter on the URL that invokes the servlet. Figure 4. Ajax solution in JSR Serving the Ajax data using an additional servlet View image at full size How does the new portlet specification support Ajax use cases? As we have seen, JSR provides you with the means to serve resources directly using the portlet.
Thus, you can issue XmlHttpRequests to ResourceURLs and, on the server side, get complete access to the portlet context such as render parameter, portlet mode, window state, portlet preferences, and portlet session. We also learned that you can make some state changes in the serveResource call: Change the portlet preferences Change data in the portlet session scope You can now implement additional use cases such as asynchronous updates that make your user interface more responsive.
Figure 5. You can see that the Ajax calls go through the portal servlet and thus are under the control of the portal. Closing the gap to the servlet programming model The first version of the Java Portlet Specification restricted the portlet programming model in some areas compared to the servlet programming model.
This restriction was done because portlets are aggregated on a page and all concepts that assume that you are the only component on the page are not easily applied to the portlet programming model.
The second version tackles these issues and provides solutions so that the portlet programming model has nearly the same capabilities as the servlet one, plus the portlet specific extensions.