Hi Hanno,

>> For the record, I love this functionality :)
> While I like this too, I'm a bit concerned about the performance
> penalty. Is there an easy way to turn this behavior off? Like a switch
> in some control panel?

There is not, but there easily could be. The hardest part is making the control panel page. :)

I don't think it's that much of a hit, though. On every object move or delete, the following operations take place:


They basically look up and perform an operation on the storage utility in:


Those operations are string manipulation and BTree lookups/inserts. I doubt they would cost much relative to the cost of renaming, cut/pasting or deleting an object in general. I'd be tempted to wait to make a switch until we have some evidence that it's a problem, but having those two event handlers short-circuit on some switch somewhere would be trivial.

The other performance hit (which is bigger) is on the default_error_message page when it gets a NotFound error. In that case, we attempt to do a redirect (more string and btree logic), and possibly perform some traversal and catalog searches, in the first three methods in this view:


I don't see why the 404 page needs to be fast, though (except during the spam attack we had on plone.org, but that's rather different).

>> I'd like to merge this now, unless people have objections. There's no
>> bundle, but the code is here:
>> http://dev.plone.org/plone/browser/plone.app.redirector/trunk
>> http://dev.plone.org/plone/browser/CMFPlone/branches/plip125-redirector
> The only thing that seems a bit dubious to me is the IGNORE_IDS constant
> in browser.py. I think this is a policy decision that should be easier
> to customize. The simplest solution here would be to turn this into a
> simple global utility with just one method that would return this list.
> This way people who really wanted to customize it could add their own
> local utility to return something different (for instance ignore all
> aliases registered on any content type + all dynamic view templates + ...).

Good idea. I'd forgotten about that whart, actually, it was originally taken from the (age-old) RedirectionTool.

> Is there any way to clean up some old redirects, like a 'delete all
> redirects' option somewhere? I imagine that people might need this after
> a while.

Not for now. The operations are there, it just requires some UI. I'm not 100% convinced its needed, but I agree that it feels like something that may need it one day (note that redirects are cleaned up when objects are deleted, so in theory only redirects to actual, live objects should exist, and of course, redirects are only created when an object is actually renamed or cut/pasted (moved), which in itself is not something you'd expect to happen with extreme frequency).


Framework-Team mailing list

Reply via email to