On Mon, May 5, 2008 at 9:54 PM, Jorge Vargas <[EMAIL PROTECTED]> wrote: > > On Sat, May 3, 2008 at 3:36 PM, noflashlight <[EMAIL PROTECTED]> wrote: >> >> >> >> On May 3, 2:12 pm, noflashlight <[EMAIL PROTECTED]> wrote: >> > On May 3, 1:34 pm, noflashlight <[EMAIL PROTECTED]> wrote: >> > >> > > On May 3, 12:19 am, Jonathan Vanasco <[EMAIL PROTECTED]> wrote: >> > >> > > > > as for the improvement I have to disagree TG1 gives you more than >> > > > > pylons in fact pylons is like a barebone TG. >> > >> > > > To many of us, that IS the huge improvement ;) >> > >> > > My thoughts exactly. >> > > > well from the need of flash it seems you will be missing many more components.
This comes out of the different design goals of Pylons and TurboGears. Pylons provides a set of essential tools. FormEncode and WebHelpers provide a medium level of extras, with a focus on flexible tools rather than all the megaframework features. Beyond that, we try to document how to integrate all the popular alternatives (ToscaWidgets, Django forms, Elixir) and missing megaframework features (auth libraries, CRUD, admin screens, CMS -- all still in progress). TurboGears and Django go straight to the last step and provide a single set of libraries encompassing all megaframework features. This is obviously easier if you just want to know "the way" to do "everything". They also document how to use some alternatives, but to a much lesser extent than Pylons does. Because their design is more all-encompassing, hardcoded assumptions between the standard dependencies can make it difficult or infeasable to use certain alternatives. Another point in Python's favor is that the state of the art changes every six months, and is unpredictable. Both TurboGears and Django have been weighed down at various times by being so big and all-encompassing. TurboGears when its libraries evolved out from under it (Kid unmaintained, SQLObject -> SQLAlchemy, Javascript libraries). Django with WSGI and the advent of SQLAlchemy. For python-web developers who have already had to change frameworks multiple times over the years as they lagged behind what's available, this flexibility of Pylons is a major asset which should make it more future-proof. But it does mean some more work up front to integrate the extras. -- 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 -~----------~----~----~----~------~----~------~--~---
