On Fri, 2011-06-24 at 16:23 +0200, Vlad K. wrote:
> On 06/24/2011 03:32 PM, Chris McDonough wrote:
> > If you never use the factory= or traverse= arguments to to add_route and
> > you never use *traverse in a URL pattern, it will always be the default
> > context.  But it isn't always the default context.
> 
> My point is that the context parameter ( of 
> pyramid.security.has_permission() ) has no default, and therefore has to 
> be supplied even for URL dispatch apps that use no context:
> 
> has_permission("someperm", request.context, request)
> 
> My suggestion is to give it a default for less writing.
> 
> has_permission("someperm", request=request)

That would probably be OK.

> > You're free to define such a feature yourself.  The framework won't
> > provide it, though.  You can use
> > "pyramid.threadlocal.get_current_request()" in the function you create
> > if passing the request bothers you.
> 
> True, and that's what I'm doing (removing the context param, request 
> remains). I just wanted to suggest an out of the box solution that would 
> not add any bloat nor break compatibility.

Well, defining your own does neither, albeit not out of the box.

> > Also just a matter of creating a wrapper object of some kind I guess.
> >
> > from pyramid.security import has_permission
> >
> > class Perms(object):
> >      def __init__(self, request):
> >          self.request = request
> >
> >      def __contains__(self, perm):
> >          request = self.request
> >          return has_permission(perm, request, request.context)
> >
> > perms = Perms()
> >
> > In either case, pass in "perms" or "my_has_permssion" to the template in
> > the return dictionary in a rendered view or make it a global using a
> > before render subscriber as per
> > http://docs.pylonsproject.org/projects/pyramid_cookbook/dev/templates.html#using-a-before-render-event-to-expose-an-h-helper-object
> 
> Great idea, thanks!
> 
> But, why won't the framework provide something like this? Isn't checking 
> for individual permissions a rule rather than exception in most of the 
> apps complicated enough to require a framework to begin with?

For better or worse, Pyramid is very explicit, and very few of its APIs
are optimized for less typing. I think you're suggesting that passing
parameters is too hard and too much typing, because you already have the
API you want (has_permission), it just takes more typing than you'd like
to use it.  Am I right?  Or are you missing functionality you want?

I personally have had some rather poor experiences with other frameworks
that are more implicit.  While they're great for some use cases, for
others, the implicitness is really troublesome and makes evolving the
framework over time extremely difficult.  So my usual knee-jerk reaction
to adding convenience features is conservatism.  Over time, though,
we'll move more towards convenience where it doesn't hurt
maintainability, so I'm happy to talk about it.

- C


-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" 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/pylons-discuss?hl=en.

Reply via email to