That sounds fine in theory, but seems to make the implementation kind of schizophrenic. So if portlets are servlets and they have an entry in a web.xml file and a servlet mapping, then it would seem they are really managed by the servlet container e.g. Tomcat. However portlets don't implement servlets they extend them, so the only calls that the servlet container can make are the init(ServletConfig), service(HttpServletRequest, httpServletResponse) and destroy() methods. How do the init(PortletConfig) initConcrete(PortletSettings) and doView, doEdit, doHelp, etc, methods get called that are defined in the WebSphere portlet API? If portlets are in fact their own objects than they can be managed by a chief servlet otherwise it seems that the portlet container is really a servlet container. Possibly IBM hacked Tomcat as well to make their model fly. I'm beginning to think there is really no good reason for portlets to subclass servlets.
Jason
Weaver, Scott wrote:
Here is a portion of JSR 168. "The Portlet specification will be based on the Servlet specification. It is envisioned that the developer API will be similar to the Servlet API.The Portlet specification will restrict the use of functions provided by the Servlet API to a subset that makes sense for components providing fragments of a markup page." It's pretty much like David stated below. Use the servlet API pieces for where it makes sense, drop the stuff that doesn't. Scott-----Original Message----- From: David Sean Taylor [mailto:david@;bluesunrise.com] Sent: Thursday, October 31, 2002 12:55 AM To: Jetspeed Developers List Subject: RE: why do portlets inherit from servlets?-----Original Message----- From: Jason Novotny [mailto:jdnovotny@;lbl.gov] Sent: Wednesday, October 30, 2002 9:02 PM To: Jetspeed Developers List Cc: [EMAIL PROTECTED] Subject: Re: why do portlets inherit from servlets? Hi David, Thanks for the information. In trying to implement something similar myself, I'm confused as to how to manage the portlet lifecycle if portlets are servlets. For instance, the only method a "manger" servlet, or portlet container, can access of a portlet is the service method thru the RequestDispatcher.include call. How would the init(PortletConfig) or initConcrete(PortletSettings), login and other methods get called? In the other case, where portlets are their own objects and not necessarily servlets, then what about the PortletConfig object, which seems to get its params from the web.xml? Will that be a part of the standard?Well wouldn't the servlet interface be just one of the interfaces that a portlet may implement, so the container can make standardized calls such as init on the Portlet (extended) interface. IMO, there are too many differences between a portlet and servlet. The servlet api should be mimicked where needed. I personally wouldn't extend a Portlet interface from Servlet. A portlet has a different lifecycle and request phases. Some Servlet API methods would be not applicable (or stale) on the Portlet api. Portlets render fragments, servlets the entire page. David -- To unsubscribe, e-mail: <mailto:jetspeed-dev- [EMAIL PROTECTED]> For additional commands, e-mail: <mailto:jetspeed-dev- [EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:jetspeed-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:jetspeed-dev-help@;jakarta.apache.org>
