On Tue, Nov 9, 2010 at 5:03 PM, Chris McDonough <[email protected]> wrote: > On Tue, 2010-11-09 at 16:18 -0800, Mike Orr wrote: >> On Tue, Nov 9, 2010 at 3:10 PM, Chris McDonough <[email protected]> wrote: >> >> That's perfect. It keeps the Pyramid brand, it respects the fact that >> >> TurboGears is the fast way to get started, >> > >> > But is TurboGears the fast way to get started? I ask this because >> > currently TurboGears doesn't include any OOTB application functionality >> > in its core. It provides a bunch of frameworky bits that someone can >> > glue together if they work hard to make an application. It has some >> > batteries but the batteries are still extremely low-level. >> >> Haha, I've never heard TurboGears described as "low level". > > Well, lower level than an application anyway. Lower level than Django, > even. > >> There are really two kinds of users, with different notions of what "a >> fast way to get started" is. One wants only the essentials and a short >> manual. The other wants all the optional parts prechosen and >> preconfigured. The third option, with application components, is >> something TG and Pylons have never really addressed, although TG has >> had db-admin and I think general admin screens at various times (until >> they become obsolete and don't get replaced). I guess Django has more >> of the application components, and that's one reason so many people >> have been using Django. >> >> But certainly there's a need for a TurboGears-level framework in any >> case. Many people don't want to spend hours deciding which auth >> library or form library or Javascript library to use, and they want >> admin screens and create-an-account-with-email-confirmation screens >> out of the box. But things like blogs and registration systems are a >> little big; they will always be add-on components. (Unless you're >> Zope.) > > But as far as I can tell, TurboGears 2 doesn't have any of the things > you mention above *working* of-the-box as core functionality. > > It does depend on SQLAlchemy, and there is some information about how to > use SQLAlchemy in its docs. Its docs also show you how to use > ToscaWidgets, but it doesn't have any forms configured in its > quickstart. So it makes choices about a form library and a persistence > system, but only as dependencies. I *think* this is because its users > want it to be flexible, like a lower-level framework might be, which is > where I get confused. > > It depends on Sprox, but there's nothing in the TG2 docs that tell you > how to use Sprox. Likewise with Catwalk. There is an admin interface > add-on to TurboGears 2 > (http://www.turbogears.org/2.0/docs/toc.html#tg2-extensions) that uses > Sprox, but it's not included in the core. Its core docs do not tell you > how to use any particular JavaScript library in a TG2-specific way. > > So as far as what's documented as useful out of the box, TurboGears 2 > itself doesn't provide *that* much more than a Pyramid paster template > like "plylons_sqla" does right now. You can cobble together enough > information to understand how to use all of its dependencies, but that'd > be true of using them with Pyramid as well. > > Do you see the distinction?
I thought these things were preconfigured in TG, or at least available in optional application templates. If not, this would be a good thing to add. Or maybe the TG developers can clarify the goals of the framework, and whether they might want to go to a higher level in TG3. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en.
