Jeremy Jones: A Brief Django/TurboGears Comparison
Simon Belak
I am *not* posting this as a call to arms, but rather as means of
gathering end-user input.
My comments:
1,2: With full WSGI multi-app support from the bottom up we will retain
praised simplicity while adding even more powerful application composition.
3: It would be nice to support Django templates now they decoupled them
somewhat.
We really need to improve error reporting for Kid.
4: WSGI + Ian's excellent middleware
5: Some work into alternative mapping schemes would be good.
How are we on Routes integration?
6: we are getting there with ToolBox
Cheers,
Simon
Kevin Dangoor
>
> http://www.oreillynet.com/pub/wlg/9168?wlg=yes
>
> I am *not* posting this as a call to arms, but rather as means of
> gathering end-user input.
>
> My comments:
>
> 1,2: With full WSGI multi-app support from the bottom up we will retain
> praised simplicity while adding even more powerful application composition.
Yes. The TurboGears model is not to lump a bunch of applications in
one project. You make independent projects, build eggs out of them and
then wire them up into bigger projects.
> 3: It would be nice to support Django templates now they decoupled them
> somewhat.
I actually don't care about that one :)
> We really need to improve error reporting for Kid.
Definitely. Odds are very good that we'll make serious headway at the sprint.
> 4: WSGI + Ian's excellent middleware
Yep.
> 5: Some work into alternative mapping schemes would be good.
> How are we on Routes integration?
Lee has some stuff working that sounds good. There may be some more
config/multiapp work necessary for it. This is not going to land in
the first 0.9 release, but it's the kind of thing that we can try out
on a branch and build it up from there.
> 6: we are getting there with ToolBox
Not exactly. The Toolbox, in my opinion, is an excellent, unique
feature of TurboGears for helping a developer work on their project.
Django's admin system is designed to be deployed to end users (which
is how it varies from the Toolbox). That's where FastData is heading.
I'd like to see FastData, via widgets, become a very customizable way
to do CRUD on the cheap. It's not there yet, but it's a start.
Kevin
Lee McFadden
> How are we on Routes integration?
>
As Kevin said, I have some measure of Routes integration but it is by
not yet finished. Once I get it to a stage where it's releaseable
into the wild I will do so and you'll all be the first to know. :)
Lee
Sean De La Torre
I don't know if this will help you with the Routes integration, but I
spotted an article [1] that provides information about integrating
Routes with CherryPy.
Sean
[1]
http://www.zachary.com/s/blog/2006/02/02/integrating.cherrypy.and.routes.part.two
Justin Johnson
It's interesting. Django seems to be a more CMS oriented solution -
similar to Drupal/Civicspace - not surprising given it's news oriented
roots. That's not going to suit everyone though - me for starters. If
I had to use Django I'd be pulling out the admin stuff from the start as
it doesn't really fit in with our requirements. There's soon going to
be a huge explosion of web application diversity and not all models are
going to be based on CMS paradigm.
I personally think Kevin has made some good choices with TurboGears that
deliver a lot of flexibility and power. CherryPy's a great framework,
Kid's a very cool templating system that does The Right Thing with
regards to not encouraging code and logic integration into the
template. It's XML oriented approach is also going to become more
important as time goes on. SQLObject is a great ease of entry ORM.
There seems to be quite a lot of grizzling about Kevin's choices too
which, quite frankly, aren't helping matters much. If Kevin and Co. had
been less clear minded about TurboGears it could have actually destroyed
the whole effort. If the choice of components seems disagreeable the
why not build your own? Fragmenting the TurboGears effort isn't going
to help.
One of the main reasons that I think RoR has been so successful is
because it's a very cohesive and consistent bunch of components that
work really well together. That and endless fervent evangelism. :-)
TurboGears seems to be heading the way of supporting lot's of different
components. Is this going to fragment the effort? Would it have been
better to stick with Kevin's choice of best of breed components and make
them better still?
Kevin Dangoor
>
>
> It's interesting. Django seems to be a more CMS oriented solution -
> similar to Drupal/Civicspace - not surprising given it's news oriented
> roots. That's not going to suit everyone though - me for starters. If
> I had to use Django I'd be pulling out the admin stuff from the start as
> it doesn't really fit in with our requirements. There's soon going to
> be a huge explosion of web application diversity and not all models are
> going to be based on CMS paradigm.
Yep. As I mentioned in a different thread a few days back: people are
already writing CMSes on top of TurboGears. But, TurboGears itself is
an application development framework first and foremost.
> I personally think Kevin has made some good choices with TurboGears that
> deliver a lot of flexibility and power. CherryPy's a great framework,
> Kid's a very cool templating system that does The Right Thing with
> regards to not encouraging code and logic integration into the
> template. It's XML oriented approach is also going to become more
> important as time goes on. SQLObject is a great ease of entry ORM.
Thanks!
> There seems to be quite a lot of grizzling about Kevin's choices too
> which, quite frankly, aren't helping matters much. If Kevin and Co. had
> been less clear minded about TurboGears it could have actually destroyed
> the whole effort. If the choice of components seems disagreeable the
> why not build your own? Fragmenting the TurboGears effort isn't going
> to help.
>
> One of the main reasons that I think RoR has been so successful is
> because it's a very cohesive and consistent bunch of components that
> work really well together. That and endless fervent evangelism. :-)
>
> TurboGears seems to be heading the way of supporting lot's of different
> components. Is this going to fragment the effort? Would it have been
> better to stick with Kevin's choice of best of breed components and make
> them better still?
Let me be clear on this: where TurboGears has a solution to a problem,
there will be one recommended (and properly documented) way to do it.
There are good reasons for TurboGears to allow for template plugins,
but that doesn't change the fact that TurboGears comes with Kid, the
widgets are made with Kid templates, the documentation will use Kid,
etc. If someone has a lot of non-HTML/XML templates they need to do, I
wouldn't hesitate to recommend Cheetah for that task.
The one solution to a problem focus is not going to change. That's a
core part of the project. The solutions themselves will change in
various ways over time, but for each release it should be clear to
people how they should proceed to build their apps.
Kevin
Karl Guertin
> components. Is this going to fragment the effort? Would it have been
> better to stick with Kevin's choice of best of breed components and make
> them better still?
Unlike Ruby, Python has a half-million web related frameworks. This
means that the projects TG uses don't exist solely for TG. They will
continue to grow and be used whether TG uses them or not. While not
the sole driver of project demands, TG has generated interest in the
component projects and all have improved as a result. TG is a tide
that raises all boats. ;]
The TG philosophy is that there will be one and only one default for
TurboGears and that is the best of breed components. This cuts down on
the tyranny of choice that makes getting started with web development
in python so difficult. At the same time, there are people who use the
components TG does not choose and the best of breed will change over
time as new projects start and new development priorities take shape.
I, for example, find that SQLObject does not suit my needs. I require
composite primary key support in order to map the legacy databases
that I work with every day. I'm happy that I can swap out for
SQLAlchemy and retain the rest of the stack. That way I still get to
take advantage of identity, error handling, catwalk, i18n, and the
fact that the stack is a thousand times more tested than any I'd
create on my own.
PS: Django tends to be a more CMS oriented solution because of admin.
You are free to ignore the admin interface, however, and you're
basically left with a more tightly integrated version of TG.
gabor
>
> PS: Django tends to be a more CMS oriented solution because of admin.
> You are free to ignore the admin interface, however, and you're
> basically left with a more tightly integrated version of TG.
>
yes, i also wanted to make this point.
you do not have to "remove" the admin module.
admin is simply an additional module, that you either install or not.
django has it's problems, but the admin-interface being too tightly
coupled with the system is not one of the problems.
gabor