cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [WARNING] Version migrations are a headache!
Date Wed, 12 Dec 2001 18:54:47 GMT
Berin,

What I think about it... Isn't it too late to actually add and deprecate
removed/renamed methods/variables? The release is out of the door - and
does not have all this... To users of released version, this looks like
adding new deprecated methods. What's your opinion?

Vadim

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, December 12, 2001 1:31 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [WARNING] Version migrations are a headache!
> 
> Berin Loritsch wrote:
> 
> Does ANYONE remember what the value was for:
> 
> Constants.SESSION_STATE_ATTRIBUTE?
> 
> Or what it was replaced with?
> 
> > 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 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


Mime
View raw message