Fan boys will be as they are. It’s good on you to not get involved. ;)

I think I did misunderstand the purpose of lib/base.py at first — but that’s just one reason why I don’t like boilerplate code. I didn’t write it and if I am to understand what’s going on in my application I have to know what it does.

To be fair, it doesn’t look like the TG2 boilerplate does a whole lot on its own, but there’s just so much of it that it’s a little disorienting for new developers despite their level of expertise.

Anyway — I’m looking forward to giving TG2 a go on a small project.

Good work again on the talk.

Cheerio.

There’s obviously a balance between providing easy ways to customize things in the quick started template and keeping the code generation under control. TG2 started with the same template as Pylons, and we’ve been slowly but surely decreasing the amount of code in the quickstart template and moving somethings into TG2.

I do think you may be confused about how the base controller works, it’s just there as a stub for you to use to add customizations too — the controller in lib.base is very, very small and just subclasses a controller in TG2. It’s purpose is just to make it obvious where such customizations should live.

As I mentioned, most of the flaming is coming from people who haven’t actually watched the talk and are making interesting assumptions about what I must have said, or what motives I must have had.

I’m not worried about it though, it’s just part of life, and really it hasn’t been that bad.

However, I think you’re being mislead to think that Django is talking about the framework dependencies when it uses the slogan, “tightly integrated, loosely coupled.”

What it really means when talking about Django is that the framework is tightly integrated, but the application code written on it is loosely coupled.

For example, I write a bunch of code for a forum built on Django. That code lives on its own as a python package. It has only a handful of imports to do from Django in order to work. I can then pack and re-use or even distribute my new forum package. Anyone running Django can import the package into their settings file and it will just work. They can then specify their own template path and start developing their own forum templates without touching my package’s source.

That, I think, is a very nice feature.

Contrasted with Turbogears 2 which I just set up the other day — I’m starting with a huge file-system structure and a tonne of boilerplate code. I just entered the ‘paster quickstart’ command and already have more code than most Django apps I’ve ever had to write. There’s a lot of code I would assume should just be in the tg package, but for some reason it’s polluting my application source. What’s with all the boilerplate? Why can’t those controller base classes live in tg.controllers?

Boilerplate makes babies cry.

However, Django could definitely be better off if it would open up to outside developments like SQLAlchemy (which is being worked on AFAIK) and the various other template languages and dispatch systems (though I think Django’s dispatcher is the best thing since sliced bread… really not a fan of the active routing method).

If you are getting lots of flaming it might simply be a mis-communication issue.

Good talk though overall — I did sit through all 50mins of it on youtube. ;)