On 4/24/06, Jorge Godoy <[EMAIL PROTECTED]> wrote:
You got me wrong there I said no default classes, the fact that they are commented out in model.py will make them NOT be there, and will also take out 2 nasty "features" having 2 tables and having to run the app ones before having a custom model.
I have always talk about TG_* which is the 4 classes
NO i never said move the provider just the classes which are 4 with a total of 20 lines or so, which will be 100% SQLObject declarations.
No just the relevant one, that is why we need a tg-admin quickstart template for that.
TG_VisitIdentity 240-246
TG_Group 249-272
TG_User 284-306
TG_Permission 343-355
that's 6+23+22+12 = 63 lines with a space in between lines and all the deprecaded stuff we are talking about 20 at most
I finally end up writing a possible model.py from the template , total 30 lines and it's MUCH more cleaner then the one in soprovider.py because we don't have to force it to be TG_*
I prefer that then having this magic email address that I don't want :) or having two tables! with user data.
No they will use the correct template went creating their project, and yes I know someone will say, what if I change my mind,etc. then you must change it, (hint create one with the new template and move your other classes, or the other way around) that is a rare case anyway.
Again that is where the tg-admin comes in. it will be something similar to TGbig
Em Segunda 24 Abril 2006 02:41, Jorge Vargas escreveu:
> You didn't undestand or we are confused in terms, I'm not saying replace
> soprovider.py I'm just saying remove the TG_* classes, and make
> soprovider.py look for them in the model.py of each project, changing the
> way the config values work.
I was talking about the same thing. I said that having no TG_* classes would
make it harder. And I believe that moving them to model would make the model
a more polluted place.
You got me wrong there I said no default classes, the fact that they are commented out in model.py will make them NOT be there, and will also take out 2 nasty "features" having 2 tables and having to run the app ones before having a custom model.
> In fact we can even make a "tg-admin quickstart identity" that will create
> a model.py file with all the TG_* classes commented out. That will even
> make "migration" easier, the only thing everyone that is using the original
> provider has to do is uncomment those lines, (or copy them over) and for
> people that have extend it with 1 or 2 fields can think it better and just
> make a new class with the new values.
Why making a new class if the original model will be in there and can be
freely changed? What about all the other rules, glueing Permissions and
Groups to users? 'Cause I've just seen talk about TG_Users here, not all the
rest that ties all three main classes together.
I have always talk about TG_* which is the 4 classes
Even though you can work with just one of them, the mechanism that is coded
uses all of them. Some of which you can override, as stated in the
configuration file.
> see above
The same.
> Again this wouldn't be an issue if the code was right there in their
> model.py and they could have just change it.
So you're not "removing", you're "moving" all that code to model.py... Now,
you're moving code for which provider?
NO i never said move the provider just the classes which are 4 with a total of 20 lines or so, which will be 100% SQLObject declarations.
SQLObject? SQLAlchemy? Both?
No just the relevant one, that is why we need a tg-admin quickstart template for that.
The SQL Object provider file has 364 lines, the SQL Alchemy provider file has 267
lines. Let's say that 30% of each is table declaration and dependent logic,
we still have an average of 70 lines for each one.
TG_VisitIdentity 240-246
TG_Group 249-272
TG_User 284-306
TG_Permission 343-355
that's 6+23+22+12 = 63 lines with a space in between lines and all the deprecaded stuff we are talking about 20 at most
I finally end up writing a possible model.py from the template , total 30 lines and it's MUCH more cleaner then the one in soprovider.py because we don't have to force it to be TG_*
So we'd start our models
with 140 lines that should be read, understood and uncomented + modified for
each application we start that needs identity.
I prefer that then having this magic email address that I don't want :) or having two tables! with user data.
This doesn't sound like a good thing to me.
> I'm liking the tg-admin quickstart identity idea much more everytime i
> think about it :)
But you've thought about just one provider, right? What about people using
other providers -- e.g. an LDAP provider -- that they've tailored? Will they
have to erase all 140 lines on every application instead of just pointing the
config to their custom classes?
No they will use the correct template went creating their project, and yes I know someone will say, what if I change my mind,etc. then you must change it, (hint create one with the new template and move your other classes, or the other way around) that is a rare case anyway.
Since Tim did all threee options -- use nothing, use default, use custom --
and said that they're mostly equivalent in work required to have it working,
I believe we should document better how to have a custom class, put all
requisites in the docs -- extra code included -- and then see if it helps
better. I don't believe a relocation of code will help, specially with compatibility
with two ORMs existing and the plugability of identity.provider that we have.
Again that is where the tg-admin comes in. it will be something similar to TGbig
--
Jorge Godoy <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
