We get a lot of refugees who come to TG from other frameworks where they got themselves to a place they could not get out of.  I have worked with some of these frameworks in the past.  Things are awesome in the beginning.  You work on some less complex stuff, maybe change a template around, or the theme for a site.  Then you have some technical detail you need changed and BAM!  You just hit the wall.  Now you are forced to dig, or suck it  up and go on IRC and ask noob question.  Many times I find myself getting shut down, told to RTFM, or whatever.

With TG I never really felt the wall.  TW was a bit of a hump to get over, but seriously, things are so un-coupled in TG that using a technology you are already familiar with, or swapping out the standard stack is not something totally unheard of.  I for one do not like working with Genshi.  I’ll do it, and I support it for major OSS work I do, but really I prefer Mako.  Mako is fast, works in a non-xml way (which makes it great for writing form-emails for instance).  What this means is that TG has good support for Mako in the “standardized” parts like the admin.

The thing is, we really did not have to add much to TG to allow it to work with Mako.  I think one of the ingenious things that TG supports is dotted template lookup.  What this does is allow you to pull data from any package, because the lookup occurs using pkg_resources.  Beautiful, now we have the ability to move templates into their own succinct packages.  Also, we support non-dotted template lookup for template languages like Jinja, and adding support for dotted lookup wouldn’t be too hard to do in the future.

The new TGAdmin interface is another example where hitting the wall is just not something that happens.  TGAdmin is built on new technologies for TG2.0.  Namely RestController, Sprox, and lookup.  It creates a custom controller for each of your model classes, and therefore you have a good place to start from when you get going with your application.  This is great for demoing.  With SQLAutocode, Sprox, and TGAdmin you can literally hook into your client’s database (MySQL, Postgres, sqlite or MSSQL) and generate web forms where you can have an infinitely scrolling tableview, edit, and create forms.  From there you have the ability to customize further, by hiding table/form fields, changing the look and feel of any component in the chain.  This is made possible by Sprox’s configuration interface.  You can also modify the controller code for each model by adding controller methods to your default controller in the admin’s config object.  All of this customization is outlined in a tutorial.  

The great thing with the new TGAdmin is that since it is based on Sprox, you can re-use the knowledge of sprox externally to the admin, and also bring any existing knowledge you may have about ToscaWidgets to the table.  You can even use sprox outside of TurboGears for any other python web-based applications that you have that also use SQLAlchemy (read: Pylons).

To get back to the TurboGears discussion, a lot of folks don’t want everything that TG brings to the table.  Some folks need different auth/auth models,  have no use for a widget library, or even a relational database connection.  TG can serve you too, and it’s still fast.  Recently SourceForge moved over to TG for their main website.  This requires a connection to MongoDB on the back end (read: no SQLAlchemy), zero ToscaWidgets, and a different authentication method.  According to Mark Ramm, they had started with a different framework which lends itself to the Jinja2 templating engine.  As far as I know, Mark was able to meet all of these goals, and eliminate 9/10ths of the server load they had with their previous system, written in something non-python.  This just goes to show how flexible TG was to be able to meet all of these needs, and still provide a technically sufficient solution.  Maybe he will comment more about this in the future.

Now, there are those folks out there who have decided to role their own.  And WSGI definitely supports, if not encourages this behavior.  But I just have to ask:  Who’s agenda are you really fulfilling?  Even if people like your code and you have a small following, are you helping to further the benefits of your projects, or your career in general?  Are you helping your customer in the long run if you leave the project, or leaving them with a dead-end piece of code?  Will they be able to find someone to replace you, should you decide to leave?

TG has an active community of folks who are willing and able to help get your contributions into the main code branch.  We have embraced mercurial, and use it’s abilities to offer a lessened barrier for those who want to contribute.  So, please, before you go make your own framework, see if you can help us make TG better, and your reward is that you now have a community of folks that will help maintain your work, even if you decide not to.

Basically what I am saying here is that TG has an even learning curve.  Sure, as you get more involved, the problems will get harder, but you wont end up having to re-write half of the framework just to get it to do what you want.  And, if you do find something that needs work to meet your needs, you have options to participate in the development of TG.

In 2008 TurboGears ran a sprint series to flesh out the 2.0 release.  We successfully released in Spring of 2009, thanks to the hard work and dedication of a number of folks who saw the process through.  This was a great opportunity for folks who wanted to be actively involved with a web framework to jump in.  It is very likely in the coming months that TG 2.1 will see the same sort of community out-reach as we prepare to move from a development cycle, to a release one.  So, look forward to that, find out how you can contribute, and by all means, give us feedback as to what you really want from a Best of Breed framework.

I think a lot of people wonder what’s happened to TurboGears.  Where is TG going?  Where has it gone?  In a recent mailing list post, we were blasted for our documentation, or lack there-of.  People seem sort of frustrated that they have a great tool in TG2.0, but have to spend so much time isolating their own technical problems that they fail to see that there is considerable documentation in most areas, but that the docs have a few sore spots here and there.

2008 was all about making TG2 _work_.  We’re past that now.  Most things pretty much work, some things work really well.  Other things need some attention.  Now that we’ve got the hard part of actually  designing a functioning framework, we can focus on documentation, and using that valuable framework we have written to push the envelope of what TG can do.

One of the “things” we need provide to the user community is better documentation.  In the past few weeks I have seen more drive in our community to improve the docs than ever before.  Michael Pedersen has taken over responsibility for our documentation.  I cannot thank him enough for his work, both in reviewing, reorganizing, adding to, and fixing errors in our existing documentation.  His kind of no-sacrifices attitude towards the docs means that we won’t just have “something” up there, we will have what it takes for developers to create web applications using TurboGears.

ToscaWidgets is a sore spot for a lot of folks.  I feel your pain.  Lot’s of folks say you don’t really need TW to do what it does because you are just creating HTML forms, what is so hard about that.  Well, I’ll tell you that I could not have written Sprox without it’s flexibility.  Here’s the good news: TW has been re-written from the ground up by Paul Johnston in the past few months.  I’ve been helping in this process, providing the tests that will make it more stable than the previous version, and making sure the codebase is not so complex a feeble mind like my own cannot comprehend it.  I spent some time benchmarking it, and making sure it’s as fast as it can be.   TW2 is 2x as fast as TW.  It approaches the speed of simpler frameworks that _only_ produce html (they don’t do resource injection, parameter cascading, etc.)

On other fronts, Jorge Vargas and I have been working on integrating MongoDB with Sprox.  This will become the “killer app” for sprox 0.7.  For me, this represents proof of concept for Sprox.  We have successfully integrated the basic workings of MongoDB into Sprox, which means I generalized in the right places enough for this to work.  The result is a TG Admin that will work for MongoDB or for SQLAlchemy equally.

So yeah, there’s still a lot of activity on the TG front, and if you pop into IRC you can feel free to chat up at least one of the TG dev team at almost any hour.  Also, we are having a DocSprint Sept. 25-27 (with a main emphasis on Sept. 26), in Boulder, CO and worldwide remotely.  We will be addressing the over 100 todo items that Michael has so graciously gathered for us.

This is the first part in a 3 part serious on TurboGears.  The next part is entitled: “TG’s Job is hard.  Here’s why.” which will discuss various philosophical challenges with running a project like TurboGears.