Deprecating methods in Portlet

["Luta, Raphael (VUN)" <Ra...@groupvu.Com>]

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 - raphael.luta@groupvu.com
Principal Consultant - Technology and New Initiatives
Vivendi Universal Networks - Paris

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Deprecating methods in Portlet

[Mark Orciuch <ma...@ngsltd.com>]

> * getAllowEdit()
> * getAllowMaximize()
> * isShowTitleBar()
> * get/setTitle
> * get/setDescription
> * get/setImage
> * set/getCreationTime
> * supportsType

+1

> * 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)

+1 - also, certain portlets (for example RSSPortlet) initialize their
content via init() which makes it difficult to personalize

>
> 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.

+1 - I already modified a handful of portlets to extend
AbstractInstancePortlet

Best regards,

Mark C. Orciuch
Next Generation Solutions, Ltd.
e-Mail: mark_orciuch@ngsltd.com
web: http://www.ngsltd.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Deprecating methods in Portlet

[David Sean Taylor <da...@bluesunrise.com>]

Hi Raphael,

The init() removal worries me that it will break people's existing portlets.
Also getAttribute is used to read from the registry setting.
Which API should we use to get an attribute from the registry (not from the
instance)?

> * getAllowEdit()
> * getAllowMaximize()
> * isShowTitleBar()
> * get/setTitle
> * get/setDescription
> * get/setImage

+1

Be sure to patch any velocity templates making calls to these methods, as
they won't be caught by the compiler

David

> -----Original Message-----
> From: Luta, Raphael (VUN) [mailto:Raphael.Luta@groupvu.Com]
> Sent: Tuesday, October 29, 2002 11:15 AM
> To: 'jetspeed-dev@jakarta.apache.org'
> Subject: Deprecating methods in Portlet
> Importance: High
>
>
> 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 - raphael.luta@groupvu.com
> Principal Consultant - Technology and New Initiatives
> Vivendi Universal Networks - Paris
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>