On Wed, Feb 11, 2009 at 12:57 PM, Florent Aide <[email protected]> wrote: > > On Wed, Feb 11, 2009 at 5:35 PM, jorge.vargas <[email protected]> wrote: > >>>> I like the "class decorator" approach but I'm really not >>>> sure if it will break stuff already build on TG. >>> >>> It doesn't break anything by itself, but I'm proposing that we drop the >>> Controller.allow_only feature. >>> >> it breaks the docs.... > > -1 on this change (on the timing of the change) > > and the actual apps that are relying on the allow_only attr in their > controller to protect the full controller. > > We need stability not a flurry of changes every other day. We are in > b5 and should really not changes core things like this. Could we not > just postpone this to tg 2.1 with a deprecation warning in 2.1 and > then a drop later on? > > This would help people rely on docs and things not moving at speed of light.
We had a small discussion over this on irc (gustavo, percious, me) here is the summary. - this change will complicate too much existing code - it looks like py2.6 is the default in tg2 So this is what we'll implement (and by we I mean gustavo) - pylons "class decorator" will be renamed to allow_only (consistency of names) - TG2 default will remain an attribute called "allow_only" - under the hood the attribute will delegate to the same code the decorator calls (ie, add an auth call to __before__) - The "decorator" approach will be documented as an added feature not the default. - allow_only attribute will be deprecated when py2.6 is consider the default TG version. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
