[kforge-dev] turbogears framework for web RAD

Mon Oct 17 12:58:48 UTC 2005

Rufus wrote:

 > One question this raises is: should we switch from django to turbogears
 > (or at least investigate this)?

 > Currently we have invested in using django
 > (http://www.djangoproject.com) but so far not that heavily -- ie. it has
 > been used for templating and some of the form validation but nothing
 > much else (John: correct if i am wrong here).

Yes, that's right. But also: url dispatch to view handlers, and 
mod_python request handler:

We've written our templates as Djano templates, but Django templates 
don't have many features, and so our templates are very simple: there's 
nothing complex to port. And there aren't very many templates, so I 
expect the problem isn't large.

We've also got url dispatch running through Django, but we've not 
written much more than a list of regexps, each associated with some 
function (as one might expect).

We also use their mod_python request handler, but it isn't very good 
(e.g. messy, and swallows exceptions when you don't use the Django 
model, etc.).

But by far the most complex thing we did with Django is form handling, 
particularly auto generation and handling of forms driven from the 
KForge domain meta objects. However, much of the time was spent trying 
to work out how to set up the contexts given the extreme simplicities of 
Django templating. We did at first make rapid progress using their form 
handling stuff, and invoke a lot of their code to process errors, and so 
on. But Mamading also told me that turbo gears uses another stable 
Python package for form handling, so I'd like to check that out.

Overall, I think we might usefully reconsider the option (suggested by 
Rufus during the summer) of not using any framework at all, and moving 
from trying to use frameworks to using stable components in a well 
patterned manner.

That is, with Fowler's "dependency injector" pattern, which would invert 
the control that these frameworks provide (perhaps the 
justification/motivation for their exitence?), and so reduce the 
motivation/need for having any framework.

I mean, pattern language-think claims "infrastructure follows", so 
starting with (and then trying to keep up with) the best/correct/latest 
framework sounds wrong, and I think will generate increasing friction as 
time goes by.

Given that the appeal of turogears (what appeals to me at least) is that 
it brings existing components together, perhaps we should listen to 
that, but make sure we avoid trying to produce another general web 
application framework, and just solve our own problem: creating a web 
user interface for an enterprise (software) application.

I'm supposing/suggesting that KForge is more of an "enterprise 
application" than a "web application". So the furthest we should go 
towards a general web framework is: "web user interface framework". This 
is what we hoped to make from Django, but it isn't good enough. And 
particularly, becoming a "django application" or a "turbo gears 
application" seems to be quite wrong.

In other words, using a web application framework for KForge's web 
interface would seem on the one hand to be appropriate because it 
appears to be an application of the web, but on the other inappropriate 
both because a user interface isn't a whole application (swiss army 
knives never have very good spoons?), and also because software patterns 
suggest that "infrastructure follows" (from "listen[ing] to the code").

So the challenge (let's say) of trying to extract value from any Python 
web application framework when writing the KForge Web UI is partly of 
the form "square peg in a round hole" (it isn't a web application) and 
partly of the form "cart before the horse" ('code against framework' is 
an anti-pattern).

But that having been said, I do think it wasn't wrong to give Django a 
spin, and we did get some initial speed/value from it. But I think we 
should eliminate it piece by piece (mod_python request handler first), 
and move towards using established and stable components of a web user 
interface layer, just as we have done with the persistence layer.

Just some thoughts....

Best wishes,

John.