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
Function does not really solve the issue.
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
OK, I do understand the issue now and indeed we should populate this
actpage variable. Perhaps with a Proxy object using AggregationState
properly.
Perhaps a Magnolia30Filter could populate this deprecated attributes.
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.
You should use the anonymous role to define what a not logged in user
can do. We added the possibility to define url acl in the role dialog.
I think this is much cleaner than the former unsecure/secure thing.
That's bad: ho can you do with bypasses something like: everything is
open except for uris with pattern "*/secure/*"? :(((
Simple: Use a negative bypass by setting 'not' property to true
Advanced:
- the bypasses are voters so you can define positive and negative
votings
- there is a TrueVoter to set a specific default value. Use it to
define that this filter is bypassed in general (you can set trueValue
to -1 if you need the inverse in other voting environments)
- then define the not bypassing voters and set there trueValue to
negative. -2 for example to be stronger than the true voter
- this allows any kind of complex bypassing (bypass /test but not /
test/hallo, ...)
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).
This is true. My concept is that modules (we will have a system
module too), can provide update pages, where they exactly list what
you have to change in our code/configuration. Some steps will be
executable (optional) some will be manual (API changes, web.xml, ...).
Updating would no longer be a nightmare even when you have changed
API in some places.
> 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 ;) )
Welcome ;-)
fabrizio
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/developer.html
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/developer.html
----------------------------------------------------------------
