init(PortletConfig config)
This method is called by the portlet container on the abstract portlet when the
portlet is first loaded. As with servlets, portlets are loaded when they are first
requested. Any subsequent calls to the portlet will not execute this method.
Generally, initialization that is applicable to every concrete portlet based on this
abstract portlet is placed in this method. If you choose to override this method, at
a minimum it should make a call to its parent via super.init(portletConfig). At
this point in the portlet life cycle, no portlet-specific storage objects are available.
initConcrete(PortletSettings settings)
This method is called by the portlet container on the concrete portlet. The
initialization code performed in this method is not shared by other concrete
portlets even though they may be based upon the same abstract portlet. It is in
this method that the PortletSettings object is first available. The PortletSettings
encapsulates the concrete portlet configuration parameter information. From the
PortletSettings object, the PortletApplicationSettings object is available. The
PortletApplicationSettings object encapsulates concrete portlet application
context parameters. In this method, no user-specific objects are yet available.
This method is called by the portlet container on the abstract portlet when the
portlet is first loaded. As with servlets, portlets are loaded when they are first
requested. Any subsequent calls to the portlet will not execute this method.
Generally, initialization that is applicable to every concrete portlet based on this
abstract portlet is placed in this method. If you choose to override this method, at
a minimum it should make a call to its parent via super.init(portletConfig). At
this point in the portlet life cycle, no portlet-specific storage objects are available.
initConcrete(PortletSettings settings)
This method is called by the portlet container on the concrete portlet. The
initialization code performed in this method is not shared by other concrete
portlets even though they may be based upon the same abstract portlet. It is in
this method that the PortletSettings object is first available. The PortletSettings
encapsulates the concrete portlet configuration parameter information. From the
PortletSettings object, the PortletApplicationSettings object is available. The
PortletApplicationSettings object encapsulates concrete portlet application
context parameters. In this method, no user-specific objects are yet available.
login(PortletRequest request)
If the concrete portlet has been placed on a page that requires authorization, the
login method is called by the portlet container to associate a user with the portlet.
It is at this point that the PortletData object is first available. The PortletSession is
created by the container for the registered user at this point and is available in
this method via the request object. If the request for the portlet is made by an
anonymous user, this method is not called. If this method is not called, a default
session object can still be created with no user association, though it may be of
little practical use. This method is actually defined in the PortletSessionListener
interface which is implemented by the abstract class Portlet. Since your custom
portlets will extend from Portlet, it is included in this discussion even though other
oft-used listeners are not.
service(PortletRequest request, PortletResponse response)
This method is called on each and every request of the portlet. After the portlet
has been added to a page and initially accessed by a user, this is the only
method that will be called by the portlet container on subsequent requests.
Generally, this method will delegate the request to the appropriate do method to
render content. At this point, all portlets and, if applicable, user-specific objects
are available.
logout(PortletSession session)
Only when a user specifically selects the Log Off button on the portal is this
method called. This method provides you with the opportunity to manage any
user-specific information once the user has logged out and to clean up
user-related resources. If the user removes the portlet from their page, the logout
method is not called until the user actually logs out of the portal, even though
they no longer are accessing the portlet. When the portlet is taken out of service
by the Portal server or the administrator, this method will not be called. The
PortletSettings object is still available in this method, although the PortletRequest
is not. This method is actually defined in the PortletSessionListener interface
which is implemented by the abstract class Portlet. Since your custom portlets
will extend from Portlet, it is included in this discussion even though other
oft-used listeners are not.
destroyConcrete(PortletSettings settings)
This method is called when the concrete portlet is taken out of service either
because of the portal server stopping or the application being uninstalled from
the portal server. The portlet container will call each running concrete portlet in
the application individually when the application is deleted. In this method, the
PortletSettings object is passed in as a parameter and cannot be retrieved from
the normal getPortletSettings method.
destroy(PortletConfig config)
The portlet container executes this method on the abstract portlet when the
portlet is taken out of service. Since it is executed on the abstract portlet and not
the concrete portlets, it is executed only once. This method provides an
opportunity to execute clean-up code on each and every concrete portlet in the
application derived from this abstract portlet.
No comments:
Post a Comment