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. My biggest one for example :-) Having no default provider makes the "entry" harder as well. You can only be dissatisfied / satisfied with something you know how to make work. > 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, 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. > 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... -- 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 -~----------~----~----~----~------~----~------~--~---
