basic difference is
2) portlet lifecycle is
1) servelet runs on servlet container but portlet on portal container
2) portlet lifecycle is
- init
- render
- process action
- resource action
- pro
cess event - destr
oy
servlet lifeycle is
- <>init
3) portlet is based on jsr 168-286 butservlet is based on web framework directly
although jsr 168-286 is built upon web framework
portlets also have an additional deployment descriptor, portlet.xml, which must
declare all of the portlets that will be used by the portlet container.
2. Instead of HttpServletRequest and HttpServletResponse objects, portlets expect either an ActionRequest or RenderRequest object and ActionResponse or
RenderResponse objects. There are limitations in the objects that portlets manage such as not having direct access to original servlet request parameters (JSR 168).
But check your portlet specification and portlet container implementation to verify which features may or may not be available.
3. Portlets have a Context interface that allows developers to access the Portlet
application under which a portlet is running. This is similar to the servlet's context interface.
4. Portlets have their own config object, PortletConfig, which can be used to access properties within the portlet.xml.
5. Portlets use the concept of portlet modes that allows developers to provide
varying levels of end-user control for viewing, editing, or accessing help.
6. Portlets have window states of normal, maximized or minimized that determine how much a portlet can be seen within the portal window.
7. Listeners and Wrappers used by portlets are still declared within the “web.xml” deployment descriptor.
8. Sun provides a Portlet Tag library that is used for accessing portlet features from markup such as Java Server Pages or Velocity templates.
9. Portlets can expect to be invoked multiple times by the portlet container to update its area of the display. This means that rendering methods must contain
idempotent code. When performing actions on a portlet, portlets should expect
that the action will be performed only once and therefore should be non-
idempotent.
Check the portlet specification that you're using to see the complete list of features supported. Also, review your portal documentation to see how closely the portlet container follows the specification.
In Summary, Portlets are similar to servlets, in that:
Similarities:
1. Both servlets and portlets use the “web.xml” deployment descriptor. However,portlets also have an additional deployment descriptor, portlet.xml, which must
declare all of the portlets that will be used by the portlet container.
2. Instead of HttpServletRequest and HttpServletResponse objects, portlets expect either an ActionRequest or RenderRequest object and ActionResponse or
RenderResponse objects. There are limitations in the objects that portlets manage such as not having direct access to original servlet request parameters (JSR 168).
But check your portlet specification and portlet container implementation to verify which features may or may not be available.
3. Portlets have a Context interface that allows developers to access the Portlet
application under which a portlet is running. This is similar to the servlet's context interface.
4. Portlets have their own config object, PortletConfig, which can be used to access properties within the portlet.xml.
5. Portlets use the concept of portlet modes that allows developers to provide
varying levels of end-user control for viewing, editing, or accessing help.
6. Portlets have window states of normal, maximized or minimized that determine how much a portlet can be seen within the portal window.
7. Listeners and Wrappers used by portlets are still declared within the “web.xml” deployment descriptor.
8. Sun provides a Portlet Tag library that is used for accessing portlet features from markup such as Java Server Pages or Velocity templates.
9. Portlets can expect to be invoked multiple times by the portlet container to update its area of the display. This means that rendering methods must contain
idempotent code. When performing actions on a portlet, portlets should expect
that the action will be performed only once and therefore should be non-
idempotent.
Check the portlet specification that you're using to see the complete list of features supported. Also, review your portal documentation to see how closely the portlet container follows the specification.
In Summary, Portlets are similar to servlets, in that:
- A specialized container manages Portlets.
- Portlets generate dynamic content.
- The container manages a portlet’s life cycle.
- Portlets interact with web client via a request/response paradigm.
- Portlets only generate markup fragments, not complete documents.
- Portlets are not directly URL addressable. You can’t send somebody URL of a portlet. You can send him the URL of the page containing a portlet.
- Portlets cannot generate arbitrary content, since the content generated by a portlet is going to be part of portal page. If a portal server is asking forhtml/text, then all portlets should generate html/text content. On the otherhand, if the portal server is asking for WML, then each portlet should generate WML content.
No comments:
Post a Comment