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?
Thanks for your time, Jason
On Wednesday, October 30, 2002, at 11:49 AM, David Sean Taylor wrote:
-----Original Message-----The advantage is that you can leverage the Servlet API with your portlets,
From: Jason Novotny [mailto:novotny@;aei.mpg.de]
Sent: Tuesday, October 29, 2002 12:11 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: why do portlets inherit from servlets?
Hi,
I've been looking at IBM's Portlet API in which portlets inherit from
servlets-- I would like to get some technical reasons for why this is a
good or bad idea. For one thing it seems performance might be slower
since portlets would be invoked presumably using
RequestDispatcher.include() methods rather than using a portlet object
instance. Another thing is that portlets would be managed by the
servlet container such as classloading, whereas if I have portlets as
independent objects I could use my own classloading mechanisms to
reload them without restarting the servlet container.
Any comments and information is greatly appreciated.
instead of mimicking the functionality.
This makes for a nice aggregation engine based on servlet dispatcher, all
built in and less work for the portlet container developers.
I wouldn't consider IBM's API as the standard, especially in this area of
portlets inheriting from servlets.
--
To unsubscribe, e-mail: <mailto:jetspeed-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@;jakarta.apache.org>
-- To unsubscribe, e-mail: <mailto:jetspeed-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:jetspeed-dev-help@;jakarta.apache.org>
