> I suppose there are a few questions worth asking: > > - does a user want the additional tables for groups and permissions, > and are these perhaps a minor burden (eg. if writing a very > lightweight app, or one without a database)?
You mean there is an DB out there that can't cope with one table more with one single row in it - a group named "User" or such? And I personally don't use permissions at all, so it's just a schema object in my DB. > - is there a pre-existing user table/object that doesn't have > Identity? Or perhaps you have an old TG project that didn't use > Identity, but need to think about password protecting a few things? > Upgrading to Identity from an app that doesn't yet use it doesn't > sound trivial to me. For the latter case, it's certainly not more difficult than creating your own scheme. Sure, attaching pre-existing user-data might be an issue, as long as you can't simply migrate it. But the question wasn't "how easy is identity adaptable to my already existing structures and ideas". Which it actually might even be, more so than rolling out your own - I just don't know. But I do know that at least the HTTP-side of things is already covered for me, as well as controller decorators and such. So I certainly would try and adapt instead of reinventing two wheels. > - does Identity contain too many fields for your use? (eg. I have an > app where you need to enter a password, but no username. I don't think > Identity copes with that too well.) Again a storage space argument. We live in the 21st century - a time where HD-storage is soon to be measured in TBytes. Regarding the "one field to rule them all"-requirement - well, one can always imagine situations where the sensible default of username/password doesn't apply. > - is the default behaviour of redirecting a non-logged in user to a > login page what you want (often, it's not), and is the alternative > where you protect parts of controllers/templates explicitly any easier > to do with Identity than checking a session variable yourself? (Also, > a slight wart is that Identity's use of redirects makes my browser > think I reached the originally-intended page via a POST request. This > alone can be irritating enough at times.) This is true - but only is important in cases where you develop an app, restart and reload frequently. And at least it works in that scenario due to the persistent visits - whereas most other session-based approaches will force you to redo an actual login. > Overall, I find Identity quite monolithic and inflexible. For my > current project, I'm lucky in that it just about fits what I want, but > I can certainly see why some people would not want to bother. I don't say that identity is the greatest thing since sliced bread. But it just works out of the box and provides sane & useful defaults. So if someone just needs a login-semantics, he should go for it - unless some constraints are given like "if I use a table with more than two columns for my users, the moon will crash onto the earth". Diez --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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?hl=en -~----------~----~----~----~------~----~------~--~---
