I'm currently looking at the Portlet interface in org.apache.jetspeed.portal and I see there a lot of methods that sould not belong (anymore) to this interface given its change of scope and the development of a declarative properties through the registry.
Methods to deprecate -------------------- Here's the list of methods I think we should deprecate and why: * getAllowEdit() * getAllowMaximize() These methods have been rendered completely obsolete by the implementation of the security manager and should simply disappear. * isShowTitleBar() This method functionality can be achieved now by a declarative control affinity in the Registry through the "_control" parameter. I don't see any use case for a programatic support as this is clearly a deployment issue. * get/setTitle * get/setDescription * get/setImage These properties are not owned by the portlet but by its instance and are already accessible through 2 other means: portlet.getPortletConfig().getMetainfo().getTitle() or portlet.getInstance().getTitle() I don't see the value of keeping these methods that are clearly out of the realm of a component. * set/getCreationTime Completely useless IMO * supportsType This is done in a declarative way now (ie in the Registry) * set/getAttribute This is now available through the PortletInstance which seems a better place for it in any case. * init This one is trickier... but the fact is that it's misleading because it makes the developer think that the Jetspeed portlet follows a "servlet-like" lifecycle. The fact is that init() without caching is worthless and init() with caching is buggy... so I'd rather remove it currently and implement other ways to initialize efficiently expensive resources (Portlet Tools) Deprecation methodology ----------------------- Since the goal of such a move would be to clean up the implementation and get rid of unecessary or unusable features, the deprecation needs to be fast: I propose that we move all the affected methods to a LegacyPortlet interface Have AbstractPortlet implement this interface. Change all Jetspeed portlets extend AbstratPortletInstance which would not extend AbstractPortlet but reimplement Portlet. Please let me know what you think as soon as possible. -- Rapha�l Luta - [EMAIL PROTECTED] Principal Consultant - Technology and New Initiatives Vivendi Universal Networks - Paris -- To unsubscribe, e-mail: <mailto:jetspeed-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:jetspeed-dev-help@;jakarta.apache.org>
