Sun micro system introduced Java Portlet technology to the world. In the Technology world each and every technology has some specifications based on this different people will implemented the software. The requirement specification is called Application Programming Interface.
Coming to portlet technology all requirement specifications comes under JSR 168 standards.
JSR 168 is portlet specification defined by java community people based on this many people implemented portlet technologies.JSR 168 is called portlet 1.0 specification.
Many vendors have implemented the Portlet Technology specification namely Liferay, uPortal, Web logic Portals, Webspear Portals and Apache Jetspeed.
JSR 168 is starting version of portlet technology and then people was added more specification in JSR 286.
This portlet technology specification was defined the portlet lifecycle and its management in the portlet container. Portlet lifecycle is similar to servlet lifecycle.
We already know to run or manage servlet lifecycle we need servlet containers similarly we have portlet container which is responsible for manage lifecycle of portlet.
All these specification and portlet lifecycle and management was specified in JSR 168 and JSR 286 standers all vendors who implemented the portlet technology should follow the portlet specification.
JSR 168 Portlet Important Specifications
- Provide Run time environment to run portlet i.e. define portlet container
- Implement API between Portlet Containers and Portlets
- Implement Mechanism to store transient and persistence data for portlet.
- Define Portlet Lifecycle
- Provide methods for easy deployments of portlets
- Allow portlets run in other vendor portals which follows JSR 168 standards.
- Run JSR 168 portlets as remote portlets using the Web Services for Remote Portlets (WSRP) protocol
Important Artifacts in JSR 168 specification
- Portlet Container
- Portal Page
Portal is web application which provides content aggregation, personalization and single sign of from different sources. Portal consists of web pages and each page has dynamic and static content.
Portlet page is part of portal and its simple a web page. In general web application page consist of one dynamic application but coming to portal page it consist of multiple dynamic application and static content all together is called portal page.
A portal page is an aggregation of dynamic content and static content we can say portal page is fragments of dynamic and static content served by portlet container. Each portal page has specific layout there all portlet applications are reside.
Example Diagram For portal Page
Portlet container is responsible for manage the portlet lifecycle. Portlet container is similar to server container.
Portlet container is integrated with web server/application so that it will use http protocol to communicate with client and serve the content. Generally some application server has provision to inbuilt with portlet container to support run time environment to portlet.
Portlet is fragment of dynamic content which reside in portal page. Similar to servlet, portlets are web components that are deployed inside of a container and generate dynamic content. On the technical side, a portlet is a class that implements the javax.portlet.Portlet interface and is packaged and deployed as a .war file inside of a portlet container
- Portlets are managed by specialized containers called portlet containers.
- Portlets are server side component which generate the dynamic content.
- Portlet have its own lifecycle which will be manage by portlet container
- Portlet will be used request/response mechanism to interact with web client using http protocol.
How portlets are differed from Servlet
- Generally in servlet web application each servlet will be referred by URL to invoke or access and each web page content will be served by one servlet but in portlets each page will be served by different portlet and each portlet will have its own lifecycle and own URL pattern to execute.
- Servlet will generate dynamic content which send to browser and it’s in single web page but portlet will server fragment of dynamic content and portal page is responsible to aggregate content from different portlet to generate whole page.
Portlet life cycle
As we already know each portlet has it own lifecycle and which will be managed by portlet container. According to the JSR 168 standard portlet have three lifecycle stages.
Initialize the portlet and put the portlet into service
Process different kinds of action- and render-requests
Put portlet out of service
Theoretically we have 3 lifecycle stages in portlets and these will be implemented via portlet interface. Portlet interface is implemented in jax.portlet package by Sun Microsystems.
Every portlet that should implement the portlet interface or it should extend the class that already implemented the portlet interface.
As we know portlet have three lifecycle staged and the following are interface methods which handle portlet lifecycle cycle in portlet implementation.
This method is initialize the portlet and this will be called only once when portlet is instantiated, we can say when we drag and drop portlet in page.
If any necessary functionality required at initial time of portlet we will use this method and write code here. It is similar to servlet init method. This method can be used to create expensive objects/resources used by the portlet.
processAction(ActionRequest request, ActionResponse response):
When user is requested to server then portlet will execute process action method.
This method will notify the portlet that used has triggered an action this portlet. , a portlet can issue a redirect, change its portlet mode or window state, modify its persistent state, or set render parameters.
render(RenderRequest request, RenderResponse response):
Render method will generate content and that will be send to web client.
In the portal page we have many portlet we have triggered action in one portlet then all portlet will be executed render method to aggregate dynamic content. The portlet can produce markup that may depend on the portlet mode or window state, render parameters, request attributes, persistent state, session data, or backend data.
Indicate to the portlet the life cycle's end. This method allows the portlet to free up resources and update any persistent data that belongs to this portlet.
In the portlet lifecycle for each action or request the final method is render method. Render method will be called for every time to aggregate content or produce content.
Generally portlet have different URL to call these methods like Action URL and Render URL.
Action URL will execute portlet porcessAction(----) method and then it will be execute the render(----) method.
Render URL will execute the portlet render (---) method only.
Portlet have addition Characteristics when we compare with servlet.
Portlet Widow States:
Portlet has different window states. Window state specifies how portlet will look in the page .Window state decides how much space will be accommodated in portlet page.
The following are important window states as for JSR 168 Standards.
When portlet state is decided as Maximized then entire page only one portlet is visible.
Generally we will use this state after perform some action then we will make widow state is Maximized.
Specified that is portlet may share the page with other portlets. This is the default window state.
Portlet should only render minimal output or no output at all.
Portlet mode specifies that the function will be performed by portlet.
Generally following are the portlet modes that each portlet should support as for JSR 168 standards.
This view mode is when portlet is access or render then portlet is in view mode and this is default mode for portlet.
Edit mode will be used to edit some portlet functionality and generally we wil use this mode for administrator to modify or edit something.
This will used to provide content to end user about portlet i.e how to use and access portlet like help information.
Persistent storage for preferences:
Portlets provide a PortletPreferences object for storing user preferences. These preferences are stored in a persistent data store, so they will be available across server restarts. As a developer, you don't have to worry about the actual implementation of how it is stored.