Hi,
On 4/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Revision 9190 Author philipp Date 2007-04-26 11:24:24 +0200 (Thu, 26 Apr
2007)
Log Message MAGNOLIA-1485
magnolia/trunk/magnolia-core/src/main/java/info/magnolia/cms/core/Aggregator.java
- public static final String CURRENT_ACTPAGE = "actpage"; //$NON-NLS-1$
+ private static final String CURRENT_CONTENT = "current_content";
is there any reason for renaming the variable from "actpage" to
"current_content"? I am trying to catch up with the latest changes in
magnolia 3.1 and I am pretty concerned about the amount of (often
unnecessary) changes...
I agree that "actpage" should not be used directly but I realized that
I was using it pretty often in some jsp. This change breaks lots of of
complex templates I built for magnolia 3.0: maybe nobody else used it
but as a rule of thumb I would avoid renaming/deleting/moving anything
if not really needed. Is there any reason here apart from "the new
name is prettier"? :(
Same thought for other changes:
- for jcr configuration it will probably be easy to automatically
move/rename nodes but we should really ask ourself if this changes are
really needed or if we can keep configuration more similar to the one
in 3.0 (e.g the subscriber thing). This is not only a question of
automatic upgrade, but also of knowledge: anybody comfortable with
previous magnolia versions will be probably upset by having to find
out that the configuration is not where I was used to find it...
- more important: for API changes we definitively should try to keep
compatibility, using deprecations or avoiding unnecessary changes. I
saw lots of breaking changes that seems to have only "cosmetic"
reasons (like the renaming of filters) and everything was changed
without deprecating anything. We should remember that we are going
from 3.0 to 3.1 and usually this means *NO BREAKING API CHANGES*, at
least only deprecations.
Sometime this is not possible, but most of the time it could be done
easily, with only a little bit of additional effort and attention.
Remember that API changes in custom code and jsps means a big barrier
to upgrading for anybody how implemented something on top of standard
jsp templates and I think that now we have MANY users who did that for
magnolia 3.0...
I saw a lot of effort and great new additions for magnolia 3.1 (great
work Philipp and Gregory!), but I think that a smooth upgrade is one
of the top feature users are waiting for... can we agree on not
breaking anything public if not really needed? :/
Thoughts?
fabrizio
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/developer.html
----------------------------------------------------------------
