[kforge-dev] turbogears framework for web RAD
John Bywater
john.bywater at appropriatesoftwarefoundation.org
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.
More information about the kforge-dev
mailing list