On Saturday January 31, 2009 00:54:57 Christoph Zwerschke wrote: > > I would be -1 on making it available there because of the same issue I > > mentioned in my previous email, I think defining/evaluating predicates in > > the template is anti-MVC. > > Actually I agree with you. My whole point is that it should be possible > in the template to conditionally add e.g. an additional column to a > table using <td py:if="interal_user" py:content="record.secret_info"/>, > and it should be possible to derive the boolean internal_user from any > existing repoze.what predicate (which may be used in other places to > restrict access to certain controllers). Whether this is done in the > controller or in the template (using a standard template function and a > reasonable name for the predicate), I really don't care.
OK, so once it's been created we'll make it available in the template. > Btw, instead of using an extra function for evaluating predicates to > booleans, can't the predicate interface be augmented with an additional > method for that purpose? Or maybe even make it callable and the return > value will be a boolean? Yes, that's one of the upcoming features of repoze.what. But still, for the sake of convenience in TG2 applications, we need a TG2-specific function to evaluate predicates because for a predicate to be evaluated you must pass at least the environ as a parameter; if you don't use the function, you'll have to pass the environ every time you evaluate the predicate. > >> By the way, checking a permission is not a good use case for this > >> funciton since you can already easily do this in a template using > >> tg.identity.user.permissions(), > > > > No, that's in TG1 (I guess, I've only used TG2). > > tg.identity.user.permissions is still available in TG2 templates. Ah, I thought you meant the package tg.identity. > What's > not available in TG2 any more is tg.identity.permissions. The latter was > much more convenient because it returned permission names instead of > permission objects. Well, don't use the current user's object (identity['user']) then. If you use User.permissions(), you'll get permission objects instead of strings. If you want strings, then you have to use the repoze.what's credentials dictionary (environ['repoze.what.credentials']['permissions']). > But you can easily add methods has_permission() > checking for permission names to the Group and User classes (maybe TG2 > should add these by default?). Using these should be the same as > evaluating the existing has_permission predicate. I don't think we really need to duplicate a functionality that is already available in TG2 apps and maintained by a third party. Unless, of course, that you want to know if a non-logged in user has a given permission -- but that'd be specific to one's application. Cheers! -- Gustavo Narea <http://gustavonarea.net/>. Get rid of unethical constraints! Get freedomware: http://www.getgnulinux.org/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
