On Sat, Jun 13, 2009 at 10:35 AM, Gustavo Narea<[email protected]> wrote: > > Hello, > > Jorge said: >> My goal is to make the "booleanize" stuff work by default. Where teh >> predicate will return true/false if it's called from allow_only or >> @protect (sorry if that's not the name of the decorator) then >> >> result = predicate() >> if not result: >> raise NotAuthorized > > Where would that code be? In the user's controller or inside @require? Either > way, that's already the way things work. Give it a try. > in "repoze.what"
> >> which means the predicate is simply a function, > > Just to return a Python bool, instead of another class instance? > yes, > Anyway, that function would be anything but a predicate. It won't be reusable, > it won't be stateless. why it has to be stateless? why not reusable? you are assuming we'll keep doing allow_only = not_autorized() that of course is dumb. something like this could do the job. http://wiki.python.org/moin/PythonDecoratorLibrary#Countingfunctioncalls > As a consequence, its result could not be used in > @require or .allow_only -- it will be True or False forever, whatever the > requests, because it would be evaluated when the module is loaded and will > remain constant from there on. > not really. If you make a decorator that will evaluate on each call it will serve the same purpose. Although I agree the syntax will need to be changed. > The other similar thing would be to wrap the predicates around functions which > return True/False. But it wouldn't be a good idea either: > 1.- You'd need one of those functions per predicate. why? first of all the predicate will be become the functions instead of the class. Second with just one decorator you can do this. Remember a decorator can keep state > 2.- It could be dangerous. They should only be used *inside* the controller > action (i.e., inside the method, never outside) or in the templates. This is, > they must not be used in .allow_only or @require, for example. see below > 3.- You'd have to instantiate them on each function call, which would be > inefficient: > """ > def has_permission(permission): > predicate = repoze.what.predicates.has_permission(permission) > return predicate.is_met(request.environ) > """ if it's a function it doesn't needs to be instantiated, seems like you missed the point a predicate will be a function not a class and you will have 3-4 decorators that will provide the "is_met", "allow_only" and "require" functionality. > 4.- You can already do "if my_predicate(): do_something()", thanks to the > booleanize_predicates() monkey-patch enabled by default in TG2. > which you totally trash as a "hack" in the documentation and point out it's dangerous because you are injecting (monkey-patch) the function instead of making it the default, which is only dangerous because of the monkey-patch. > >> it doesn't even needs to be tied to the SA stuff. > > Nothing is tied to SQLAlchemy. > sorry I mean the SA model (User,Group,Permission) Last please keep in mind this is an experiment and I'm not entirely sure I can accomplish the same API with predicates as functions. But in the case I do go back to classes I think we should rethink the API (which is my original goal) because as I pointed out in here http://groups.google.com/group/turbogears/browse_thread/thread/c2aa4cb5ed07f52d, the current API is completely horrible > Cheers, > -- > Gustavo Narea <xri://=Gustavo>. > | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
