>From the discussion so far, I think we can take something Mark said in the very first email and choose a direction right here.
>The point I emphasized a bit was that Django is doing a great job of >marketing, and the current situation is something like this: >#1 Python web Framework > ---> Django >#2 Python web framework > ---> TurboGears or Pylons or repoze.bfg or flask or... Whatever direction is chosen we want the end result to lead us in the goal of redefining that logic as: Python web frameworks: #1 Django (let's just be realistic here) #2 Turbogears (full-featured web app development stack) #3 Pyramid, web-core, etc... (build it yourself + disparate components) Basically TG needs to move out of the pool of "other" and rise above to the step new devs look at before they dig in to #3. Personally what I'd like to see is a solid, stable stack...with pretty much every component most users will need 99% of the time built-in and fully integrated. As while it's good to offer choice of various components (hence why I chose TG over Django), TG2 has a few areas that are not very pythonic...there needs to be one obvious, preferred way, and if you want to venture into another direction, that's up to you...but TG's documentation will primarily focus on the "correct" way. One thing that has really bothered me ideologically in this area is TG2's seeming lack of a preferred Javascript/Widget set (as opposed to TG1's implied integration with MochiKit). Sure, there's Tosca, but it's just so limited that it's really only good for simple web sites, not true web apps, which as someone already said should be the real focus of TG. I don't really care whether it's JQuery, Dojo, Pyjamas or some other option...but this needs to be built in and standardized upon. For the app I've been working on the past 2+ years I've had to write everything myself to get Dojo and TG2 to work together, it could really be much much more *automagical* in transferring data between client and server and integrating with my templates. What you really need to be successful is a singular set of tools, with just about everything you should need to write a web app built in, fully documented as if TG were a single project like Django as far as the user is concerned. Abstract out all your dependencies too, there's no reason I should be importing things directly from SQLAlchemy or Genshi, I should be importing things like tg.database and tg.template, even if they're only wrappers so that if and when those things are changed I don't have to go back and update my code to the new dependency. That also applies to documentation, putting "see docs on Dependency X's web site" doesn't cut it. If you want to be the full- featured mega framework, then I should rarely have to leave the turbogears.org domain. Whatever is decided, TG or whatever we call this in the future needs a much more active community, with more developers, more users, and probably some sort of corporate backing where at least a couple of our core devs are getting paid full-time to work on TG if it's really going to be sustainable and become the vibrant framework we all want it to be. Personally I'm still leaning toward the 3 way merger of BFG/ Pyrmaid, Pylons and TG, with the 2 package concept Mark mentioned (minimal-core vs full-stack). -- 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?hl=en.
