Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Wed, 12 Dec 2001 19:47:03 -0500
From: Tim Myers <phantom@stserv.hcf.jhu.edu>
To: cocoon-dev@xml.apache.org
Subject: Re: [WARNING] Version migrations are a headache!
Message-ID: <20011212194703.A26147@stserv.hcf.jhu.edu>
References: <3C179D4A.8000703@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3C179D4A.8000703@apache.org>;
 from bloritsch@apache.org on Wed, Dec 12, 2001 at 01:09:14PM -0500

On Wed, Dec 12, 2001 at 01:09:14PM -0500, Berin Loritsch wrote:
> The problem comes with changing dependencies and classnames.  For example the
> SessionStateSelectorFactory has been renamed the SessionAttributeSelector.
> While the second is arguably a better name, please use deprecation so that
> users can be warned before the class is eliminated!
> 
> Avalon Excalibur has a few classes which follow the following approach:
> 
> /**
>   * @deprecated Use ExcaliburComponentManager instead!
>   */
> class DefaultComponentManager extends ExcaliburComponentManager{}
> 
> This way the functionality is the same, but the user is pointed to the
> correct version gracefully.
> 
> It is a number of issues like this, the constant rearranging of the core
> components, etc. that make moving between Cocoon versions a headache.
> 
> I honestly think we have a few too many different types of core components,
> and it would be better if they were rearranged a bit.
> 
> This is especially true since people have portions of the cocoon.xconf
> file that are specialized to their site!
> 
> DANGER, WILL ROBINSON!
> *Any* time you add a new abstract method to an abstract class, or change
> an abstract method on an abstract class--that change is NOT BACKWARDS
> COMPATIBLE!
> 
> I have some specialized actions that extend AbstractComplimentaryConfigurableAction
That would most likely be my fault... I wanted access to the environment passed in from the sitemap to be accessible to the configure method.  a resolver (environment) needs to be passed as the second arguement to AbstractComplimentaryConfigurableAction...  It was the solution to what seems to be a longstanding problem of not being able to use configuration files relative to subsitemaps.

Tim

> that are now broken because of this very thing.  Now I have to figure out
> what changed!
> 
> -- 
> 
> "They that give up essential liberty to obtain a little temporary safety
>   deserve neither liberty nor safety."
>                  - Benjamin Franklin
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

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