Can I get the 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.
Can I use sessions in portlets?
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.
What's difference between 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.
How can I set/retrieve a cookie from a portlet?
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.
Can I set a cookie from an included Servlet/ JSP ?
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.
Is there a hack to get/set cookies ?
- PortletRequest Properties:
The 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.
- Javascript:
You can embed javascript functions in a JSP page and include that JSP in your response. In the javascript,you can have code that can set/retrieve cookies
and if needed, pass it over to the portlet
How do I achieve inter-portlet communication ?
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
-
Using the
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.
-
Using the
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:
In 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.
What if I need two portlets from two different portlet applications to communicate with each other ?
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
|