Kevin Dangoor wrote: > On 1/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > Nowhere is there any mention of generic functions or adding methods or > > criteria, but it internally uses a Dispatcher object that does lookups > > based on class and attribute names. So, it's not necessary to expose > > generic functions' complexity directly, if all you want to do is define > > some type of registry of rules based on standardized access patterns. > > RuleDispatch was created in part because I got tired of having to write > > new kinds of registry classes all the time for PEAK, every time there I > > had some new way of looking things up. RuleDispatch lets me focus on > > the app and not on the data structures needed to implement it. > > I actually did consider identity.require registering rules in a > context, but I couldn't see the value of doing that over just putting > an expression in the call to require() and eval'ing it.
It all depends on the complexity of the rules. For the use cases peak.security is intended for, where you have complex business rules to determine access, and evaluating those rules can result in SQL queries, you really want to make sure that the relevant tests are done at most once. If you're eval-ing multiple rules, you can't guarantee that without additional caching. For trivial rules, you're right that there's little additional benefit. PEAK is biased towards "enterprise class" business rules in this area, and the "equipment shipping" examples given in the peak.security docs are actually a *simplified* version of some business rules from a real enterprise application. The other benefit of course is indirection. Since permissions are separated from the authentication and authorization rules, it allows you to distribute an application component that can be customized without changing its source. The security rules are determined by context, not by hardcoding. It also allows you to avoid repetition, and encourages thinking about access control in terms of users and use cases rather than in terms of individual operations. And even if an application defines default permissions and rules, these can still be overridden in a particular deployment by subclassing the context and defining new operation-to-permission or permission-to-user rules. Anyway, these are not necessarily benefits for TurboGears' audience; I'm just pointing out for the sake of anybody following this thread what the intended benefits of peak.security are, so they can tell for themselves whether eval() is indeed better for *their* use cases. :)
