| TWiki . Portlet . JSR168FAQ |
HttpServletRequest from a Portlet?
PortletConfig.getInitParameter() and PortletContext.getInitParameter()?
No, you don't. You can build a portal using any web based technology: J2EE?, Dot Net , PHP or plain old CGI.
A portal server however provides a base infrastructure for rapidly developing/deploying portals. It also provides, out of the box implementations of most of the services that any portal would require.
Prior to JSR 168, almost all portal platforms offered their own proprietary approach to create pluggable portal components. For example, IBM had IBM portlets, Sun(iPlanet) had Providers, SAP had iViews and Plumtree had Gadgets.
JSR 168 aims to standardize these pluggable portal components so that they are independent of the actual portal server that they are written to. What this means is that one can migrate portlets seamlessly from one portal server to another without any code change.
A portlet container runs portlets and provides them with the required runtime environment. A portlet container contains portlets and manages their lifecycle. It also provides persistent storage for 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. It is the responsibility of the portal to handle the 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.
Here is a rudimentary List of Portal Servers?
Yes, Portlets only generate markup fragments, not complete documents. The Portal aggregates portlet markup fragments into a complete portal page. Also,Portlets are not directly bound to a URL and so web clients interact with portlets through a portal system.
Essentially, Servlets provide content that normally takes up the whole page in a browser (unless you're using frames), and portlets provide content that is wrapped by a window. With portlets, you can have multiple portlets side by side with one another and each one can provide content and functionality that is different from the other. A portlet can provide the complete interaction for one type of application, while another portlet can provide content for another type of application. The portal can provide some house keeping functionality and secured single point of entry to all of the portlets on a page. As for the particulars (similarities/differences) between them, please continue reading.
Here are some similarities:
Here are some differences:
There are several things that servlets are allowed to do, but portlets aren?t. These include the following:
HttpServletRequest from a Portlet?
The PortletRequest object is supposed to give you everything you need i.e. parameters, attributes, dispatching, etc. As per the spec, you should not need the HttpServletRequest.
However, some portlet container implementations do provide some kind of hack to get hold of HttpServletRequest e.g. in Pluto you can cast the RenderRequest to HttpServletRequest. But, be aware that this behavior cannot be relied upon.
Yes, the specification defines a PortletSession interface that allows a portal/portlet-container to use any of the session tracking approaches (such as HTTP
Cookies, SSL Sessions or URL rewriting) to track a user?s session. The PortletSession interface defines two scopes for storing objects,
APPLICATION_SCOPE and PORTLET_SCOPE.
Use APPLICATION_SCOPE, if you want to access attributes which have been placed within the session in external resources like your servlet. The
PORTLET_SCOPE attributes, although available to other resources, are used for attributes that are meant for the portlet's use only.
PortletConfig.getInitParameter() and PortletContext.getInitParameter()?
Context-wide init-params share the same context space as Servlets and JSPs belonging to the same application and they are defined in the web.xml file.
You can get them using PortletContext.getInitParameter() method.
Portlet-wide initialization parameters on the other hand belong in the portlet.xml file and you can get them using PortletConfig.getInitParameter() method.
No you cant.There is no direct way to set/retrieve a cookie value from a portlet.
Cookies are used a mechanism for session tracking. The portlet specification does not mandate the portal server to use any particular session tracking mechanism.
In fact, the portal server is free to use whatever mechanism it chooses: Cookies, URL rewriting, Https Sessions etc. Portlet developers are expected to use the
PortletSession object and leave it to the portal server to deal with the underlying mechanism.
This will not work. The Portlet Spec (PLT 16.3.3) mandates that the addCookie() call on an included Servlet or JSP does no operation. If this does work on
some containers, then it should be considered a bug and should not be relied upon.
getProperties() method of the PortletRequest would return the HTTP headers,if available.
This can be used to retrieve the cookie values in most containers. This behavior cannot be relied upon as there might be circumstances where they are unavailable.
Inter-portlet communication refers to the ability by which portlets can communicate with each other in a spec compliant way. There are currently two approaches to achieve inter-portlet communication. The exact approach you choose would depend on the problem you are trying to address
PortletSession:
A PortletSession is created for each user per portlet application. This makes the
PortletSession useful for communicating all user related information among different
portlets in the same portlet application.
When you set attributes in a PortletSession you have two options: To use a PORTLET
scope (this is the default) or to use an APPLICATION scope. If you want the particular attribute to be shared
among portlets, you need to use the APPLICATION scope.
For example, consider CityPortlet and WeatherPortlet, two portlets in the same application.
In processAction() of CityPortlet:
portletSession.setAttribute("cityName", newCityName, PortletSession.APPLICATION_SCOPE);
In the WeatherPortlet, you can retrieve the changed city name by getting it from the PortletSession:
In doView() of WeatherPortlet:
currentCityName=(String)portletSession.getAttribute("cityName",PortletSession.APPLICATION_SCOPE);
showWeatherForThisCity(currentCityName);
Pretty simple, but here is a caveat. The portlet spec does not mandate any order in which the
doView() (or for that matter doEdit() or doHelp()) be called for
multiple portlets on the same portal page. This means if you were to set an attribute in the doView()
method of CityPortlet you may or may not get the attribute in the doView() of
WeatherPortlet (depending on the portal server and perhaps the layout that you are using).
The spec, however, does mandates that the processAction() be called before any rendering
method is called. Therefore you need to ensure that any state change that needs to be propagated across multiple portlets
in the same portlet application is confined to the processAction() method.
PortletContext:
A PortletContext (very similar to a ServletContext) is shared between all users and all portlets
in a portlet application. You can get and set attributes from the PortletContext and this can be used as a global
point of communication.
For example, if the WeatherPortlet uses a webservice which is currently unavailable. You might have code like this:
doView() of WeatherPortlet
if(portletContext.getAttribute("errorMessage") = null) {
displayErrorMessage();
}
In this case, all instances of WeatherPortlet irrespective of which user is seeing it, would see the error message.
While inter-portlet communication can be done using any of the above stated methods, one must be careful about the dependencies that are introduced when utilizing interportlet communication.
In the CityPortlet/WeatherPortlet example, what would happen if the user decides to remove the
CityPortlet from his page? Would the WeatherPortlet still be functional? Should we force the user to remove
the WeatherPortlet as well? These are some of the design considerations that need to be taken in account before using
inter-portlet communication.
This situation occurs rarely and if it does, you may need to review your packaging structure. Do you really want to couple two unrelated portlets? If they are dependent wouldn't you rather package them in the same application?
If you still need the portlets to communicate, you will have to use some other standard J2EE? communication mechanisms like JNDI , Database with JDBC, messaging through JMS etc
Yea. It's called "remoting". The fact is that when two portlets are in two different wars, they are consider to be essentially in two different applications. One war = one wep app. The only exception to this rule is when the two wars happen to be actually the same application (meaning the same war) spread across a cluster (running in different JVMs).
That said, if you want two different portlets in two different applications to communicate with each other, there is nothing to stop you from using any of the other J2EE? remote communications mechanisms to make it happen. You have your choice of EJBs, RMI, or Messaging. There is nothing in the Portlet spec that would keep you from doing so.
Before you attempt to go this route, there are two questions you should be asking yourself:
You could also possibly solve these issues using WSRP. However, you are adding more to the layers and therefore taking away from your performance when it just might not be necessary.
It sounds like you're going about this all wrong. One of the possible uses for Portals is to bring together content from multiple sources. If you have two applications producing output that you wish to bring together in one portal application, the best thing to do (and one of the reasons that portals were designed to begin with) is to create an application that provides the portlets with each portlet pointing to their respective applications. That way you can gather the content from their respective sources easily and effiently and provide their output through the same portlet app. So, essentially, in your case you might have three applications. Two provide content that is channeled and rendered to the user through the third, which happens to be the portlet app.
In this case, you could still use the APPLICATION_SCOPE session attributes to pass content from one portlet to the other. As portlet1 interacts with the user, it places content into the session during its processAction call, and portlet2 uses the content in its doView call. During the doView call of portlet2, it can communicate with whatever application or resource it needs to, in order to gather the content and then produce it back to the portal page in its rendition.
----- Revision r12 - 22 Feb 2008 - 07:21:35 - Main.minhnn
|