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";
The original CURRENT_ACTPAGE constant was kept (but deprecated). By
accident the constant was made private (I changed that back). I think
the devs used mainly Resource.getActPage(req) and no the constant.
The methods related to that are deprecated and were not removed.
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...
To discuss,... but I agree that there were more changes than
originally planed.
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"? :(
The constant shouldn't have been private. But we separated the
AggrigationFilter and introduced the AggregationStatus. I think the
change has a good value:
- easier to understand for new users (how should you find out to use
info.magnolia.cms.util.Resource.getActPage() to get the current page?
- consequent deprecation of methods needing a request
- consequent deprecation of static methods
- making MgnlContext the entry point for most of the operations
templaters has to do
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...
We will implement an auto update and update the config menu points.
Otherwise I think the new configuration is more intuitive.
- two sections (server, modules)
- activation is called activation instead of subscribers (this is the
name you know by using the interface)
- you see the class property where you can change the class to be used
- 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
We had issues to solve related to cache and security. The separation
of the filters (replacing cms with a couple of single filters) was a
must. Related to that we needed a flexible bypassing (at least the
bypassing is bootstrapable now)
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.
Yes I agree in general. Since we have not the big budget to make a
4.0 or 3.5 we decided to improve the software stepwise version by
version. This time we improved the inner architecture in 3.2 we will
focus on gui and usability.
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 agree. But the nightmare won't be repeated:
- data migration is easy (no activation, no migration needed)
- configuration will update
- most of the often used methods are indeed deprecated and not removed
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? :/
We planed 15 mendays for implementing the update mechanism. Currently
I do work from time to time on the support channels. Belief me I do
care ;-). But I also care about initial questions new users have. We
try to make magnolia simpler and more transparent.
Thoughts?
Thanks for insisting. We will try to be more sensitive.
Philipp Bracher
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/developer.html
----------------------------------------------------------------
