Kevin Horn wrote: > I've been away for a few days, so I'm a bit behind, but here goes: > > WebOb: > > Great! Sorry to hear you had trouble, Alberto. Hope it works better > next time. > > Aliasing: > > Johnathan's totally sold me on the aliasing too (I was iffy before). I > think documentation should prevent confusion, and I don't think cruft > will be too much of an issue. > > Keeping everything in the tg namespace should also prevent problems > similar to ones I had when starting out with TG...i.e. I kept forgetting > to look in th cherrypy namespace!
In a very short-lived framework that I wrote at one time, I imported everything locally, and nothing from the framework ever got used except in code generated with paster create. I don't know if that would work that well with TG, but it is a way of identifying the most important objects, and giving the application a chance to customize those objects. It's kind of what Pylons does with BaseController and helpers, but was just a bit more complete. > Identity/AuthKit: > > I've been reading over some of the AuthKit stuff, and I have to say, I > was expecting to be more impressed. It seems that it's pretty complex > for what you get, and it seems more limited than TG1 identity. > Especially disappointing was the lack of TG1-style "permissions". What > AuthKit calls permissions equate to the "conditions" in TG1 identity. I > suppose you could use AuthKit's "roles" to serve this purpose, but then > you have another problem, which is that in AuthKit, a user can only > exist in one "group" at a time. For any situation where you might want > multiple groups for a user, you could use roles, but then you've lost > your "permissions" again. > > What I really want (and the way I usually structure authorization for > projects) is to pretty much only use the "has permission" condition, and > then assign permissions to users/groups as needed. This keeps me from > having to touch my source code every time I decide to add a new group or > user type. It looks like this would be (barely) possible with AuthKit, > but it would hackish and ugly. > > Also, the AuthKit docs are a mess (at least last week, haven't checked > today). The original docs have disappeared and the book chapters are > unfinished. > > So the dilemma...do we: > 1) use AuthKit (wrap it or whatever), even though it has problems > 2) write some kind of really extensive wrapper around AuthKit, that > makes it look completely different > 3) create something from scratch Ben mentioned some interest in 3, especially since WebOb makes middleware much easier to implement. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to turbogears-trunk@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
