cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Getting rid of deprecated Interfaces/Classes/Methods
Date Mon, 30 Sep 2002 12:15:53 GMT


Giacomo Pati wrote:

>On Mon, 30 Sep 2002, Carsten Ziegeler wrote:
>
>  
>
>>Giacomo Pati wrote:
>>    
>>
>>>Ok, this thread had made alot of people think about it and the conclusion
>>>is that we should not switch to a newer/better container at least until a
>>>2.1 release is out, right?
>>>
>>>      
>>>
>>Yupp.
>>
>>    
>>
>>>I've allready commited the step 1 (Loggable -> LogEnabled).
>>>
>>>      
>>>
>>Nice work!
>>    
>>
>
>Thanks.
>
>  
>
>>>Now I'm on step 2 (as there has not been any -1). This can be done while
>>>we stay with ECM for now and have still backward compatability for all
>>>custom Components somebody has around for his private projects.
>>>
>>>But I have some questions about this move. We have classes named after
>>>the deprecated Interfaces (ie. CocoonComponentManger, ComposerAction). I'd
>>>like to hear your suggestion how we should deal with those:
>>>
>>>1. don't change the names
>>>2. rename them to appropriate names like CocoonServiceManager
>>>3. create new one and deprecate the old ones
>>>
>>>What is your oppinion?
>>>
>>>      
>>>
>>A definit -1 for 2, because people writing custom components use
>>ComposerAction etc.
>>as a base class, so we can't remove them.
>>I think 3 is the way to go: deprecate the old ones and only create new ones
>>where appropriate.
>>    
>>
>
>Ok, so your suggestions are what I'd thought of doing :).
>
>Another issue is the missing interface Recomposable which has vanished in
>the service package. We use it internally on some component. Most of their
>use is publicate code like:
>
>	public void compose( ComponentManager manager )
>	{
>	    this.manager = manager;
>	}
>
>	public void recompose( ComponentManager manager )
>	{
>	    this.manager = manager;
>	}
>
>Which was for the sake of the guideline from the Component packge and can
>be replace by a single service method.
>
>In other places I've seen code like this:
>
>	public void compose( ComponentManager manager )
>	{
>	    this.mainManager = manager;
>	    this.manager = manager;
>	}
>
>	public void recompose( ComponentManager manager )
>	{
>	    this.manager = manager;
>	}
>
>which can be ported to:
>
>	public void service( ServiceManager manager )
>	{
>            if( this.mainManager == null )
>            {
>	        this.mainManager = manager;
>            }
>	    this.manager = manager;
>	}
>  
>

This is the correct approach.

When preparing the service package I excluded the Recomposable notion on 
the grounds that (a) it was insufficiently documented and insufficiently 
understood at the time, and (b) in terms of an interface - you can do 
exactly what you propose above - i.e. re-apply an invocation of service( 
manager ).

Cheers, Steve.

>Do I have your +1 for that?
>
>Giacomo
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message