On 2/13/06, Justin Johnson <[EMAIL PROTECTED]> wrote: > TurboGears seems to be heading the way of supporting lot's of different > components. Is this going to fragment the effort? Would it have been > better to stick with Kevin's choice of best of breed components and make > them better still?
Unlike Ruby, Python has a half-million web related frameworks. This means that the projects TG uses don't exist solely for TG. They will continue to grow and be used whether TG uses them or not. While not the sole driver of project demands, TG has generated interest in the component projects and all have improved as a result. TG is a tide that raises all boats. ;] The TG philosophy is that there will be one and only one default for TurboGears and that is the best of breed components. This cuts down on the tyranny of choice that makes getting started with web development in python so difficult. At the same time, there are people who use the components TG does not choose and the best of breed will change over time as new projects start and new development priorities take shape. I, for example, find that SQLObject does not suit my needs. I require composite primary key support in order to map the legacy databases that I work with every day. I'm happy that I can swap out for SQLAlchemy and retain the rest of the stack. That way I still get to take advantage of identity, error handling, catwalk, i18n, and the fact that the stack is a thousand times more tested than any I'd create on my own. PS: Django tends to be a more CMS oriented solution because of admin. You are free to ignore the admin interface, however, and you're basically left with a more tightly integrated version of TG.
