Em Segunda 24 Abril 2006 02:41, Jorge Vargas escreveu: > I think we need a better way to measure that,
Me too. I saw nothing to corroborate any "citations" of "quantity" on this thread. So, we're just saying what we think is true and that is different for each one. > because you made it fit to it :) (not that that is bad) Actually this is not entirely true. I needed all the fields that were there. They were required and email had to be unique, but I didn't need it as an alternate_id, so this is why the proposed patch didn't harm my needs -- I'll need something to make the email unique and required, though... > 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. > 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. 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? SQLObject? SQLAlchemy? Both? 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. 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. 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? 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. -- 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 -~----------~----~----~----~------~----~------~--~---
