Hi Philipp,
On 5/31/07, Philipp Bracher <[email protected]> wrote:
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.
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?
Unfortunately I didn't notice till now how often I used
${actpage.handle} in templates... I think this is a pretty common
habit for previous versions of magnolia, and although maybe not so
clean (we should make an el function for that, maybe) I would keep it
working if there is not a real reason why it shouldn't. At this point
a better name for new users should not justify the change IMHO...
Try googling :/
http://www.google.com/search?q=actpage.handle&num=100&hl=en&filter=0
http://www.google.com/search?q=actpage.title&num=100&hl=en&filter=0
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)
I absolutely agree that some things *must* be refactored but sometime
we should pay more attention to compatibility anyway. Just leave the
old bits as deprecated, that can be done...
An example about security: great work with bypasses but with magnolia
3.1 I can't do what I was used to do with magnolia 3.0 secure/unsecure
uris.
That's bad: ho can you do with bypasses something like: everything is
open except for uris with pattern "*/secure/*"? :(((
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
ok, as said what I was concerned about was especially API changes...
you can see several cases where a total rename of classes was simply
due to "better names" (for example filters have changed names more
than once...). This can't simply be "upgraded" by a migration tool,
you know (just like the "actpage" stuff).
> Thoughts?
Thanks for insisting. We will try to be more sensitive.
Sorry for insisting, and I know I should spend more time helping than
complaining ;) (hey, that's not a complaint ;) )
fabrizio
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/developer.html
----------------------------------------------------------------
