On 4/23/06, Jorge Godoy <[EMAIL PROTECTED]> wrote:
I think we need a better way to measure that,
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.
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.
see above
Again this wouldn't be an issue if the code was right there in their model.py and they could have just change it.
I'm liking the tg-admin quickstart identity idea much more everytime i think about it :)
Em Domingo 23 Abril 2006 20:44, Jorge Vargas escreveu:
>
> How about what I said there, have no default provider? Unless people
> contrain their app to the default provider most people will
> a) extend it
> b) write their own
There are applications where it is a good default.
I think we need a better way to measure that,
My biggest one for
example :-)
because you made it fit to it :) (not that that is bad)
Having no default provider makes the "entry" harder as well. You can only be
dissatisfied / satisfied with something you know how to make work.
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.
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.
> problem with a) is that it adds overhead, basically 2 everything being the
> most expensive (in performance) the 2 tables
>
> problem with b) is that even if it's easy most people at first glance are
> "scare" of going into the deeps of TG.
>
> So having no default at all will make everyone go with b)
The scariest thing, according to you... It doesn't sound like something that
would make it a good default (no default is no good default).
see above
See, for example, Ben's and Tim's cases. Both are satisfied with the model,
they just need minor tweaks. Tim uses it as it is, even with some facility
of logging in by email, while Ben would be happy if this was optional. But
the model needed just minor tweaks for both.
Again this wouldn't be an issue if the code was right there in their model.py and they could have just change it.
> Looking at the soprovider.py code, the TG_* classes are just normal
> SQLObjects the only reason they are there is convinience (which seems some
> people don't see it that way)
Yes. Those could go the harder way, instead of forcing everyone to follow
that path...
I'm liking the tg-admin quickstart identity idea much more everytime i think about it :)
--
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 turbogears@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
-~----------~----~----~----~------~----~------~--~---
