cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Getting rid of deprecated Interfaces/Classes/Methods
Date Mon, 30 Sep 2002 13:26:37 GMT
Stephen McConnell wrote:

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


This should work well. However, recompose() is defined to be allowed to 
happen at anytime after the component has been initialized or started, 
whereas compose() is called only once during the component lifecycle. Is 
calling "service()" several time allowed by the Serviceable contract ?

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




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


Mime
View raw message