On Dec 27 2007, 10:58 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> > 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.
It's not just a storage space issue, it's a complexity issue. It gives
you extra classes in your model that you have no use for. It's not a
big deal for experienced users who can quickly rename or work around
stuff, but as a new user it's actually quite daunting to have this
pile of boilerplate code shoved into model.py and 7 extra tables in
your 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.
I disagree, since I think that writing my own is_logged_in function in
terms of sessions is about 2 lines of code, and writing a log_in
function is about another 2 lines, plus a couple more lines for the
controller. That doesn't compare favourably to having to quick-start a
new project and merge the files together. Is there a better way? If
so, it would be useful (for others) to hear it.
> 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".
But that is still worth discussing, even if it's not directly what the
original poster asked about. Usually when I develop something, I add
to it incrementally, having started from a minimal base. Something
that appears to require you to have made an up-front decision before
you begin development can be awkward.
> 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.
This is one of those interesting things that people have to decide for
themselves. The 'HTTP side', as you call it, is not something I've
ever wanted in previous non-TG apps. But if I did, surely a simple 'if
not logged_in(): raise redirect("wherever")" is not a great burden?
And arguably it's more obvious what is going on, compared to the
decorator approach. "Explicit is better than implicit".
> > - 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.
No, this is not a storage space argument at all. It's about methods of
authentication. Not every app with restricted access requires
individual user accounts. It's just not necessary. I wonder if it's
possible to hack it so that everybody goes through one account.
--
Ben Sizer
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
