Are Django/Turbogears too specific?

[Gilles Ganault]

Hi

I'd like to rewrite a Web 2.0 PHP application in Python with AJAX, and
it seems like Django and Turbogears are the frameworks that have the
most momentum.

I'd like to use this opportunity to lower the load on servers, as the
PHP application wasn't built to fit the number of users hammering the
servers now.

I'm concerned, though, that these frameworks they may be too specific
to the tasks they were originally developped for (news articles,
AFAIK). Do you think I should just use eg. CherryPy and some basic
AJAX?

Thank you for any feedback.

 

[Patrick Mullen]

Hi

I'd like to rewrite a Web 2.0 PHP application in Python with AJAX, and
it seems like Django and Turbogears are the frameworks that have the
most momentum.

I'd like to use this opportunity to lower the load on servers, as the
PHP application wasn't built to fit the number of users hammering the
servers now.

I'm concerned, though, that these frameworks they may be too specific
to the tasks they were originally developped for (news articles,
AFAIK). Do you think I should just use eg. CherryPy and some basic
AJAX?

Thank you for any feedback.

No, they aren't very specific at all. Both frameworks allow
configuration at nearly every level.
The cool, slick admin interface might not be so useful depending on your
application, but everything else has uses in just about any field. I only have
experience with TG and cherrypy, TG for me is almost like cherrypy
(I'm not sure if it still does,
I've been out of the loop, but it used to use cherrypy under the
hood), but a bit
nicer to work with, especially if you have any AJAX.

 

[Philip Semanchuk]

Hi

I'd like to rewrite a Web 2.0 PHP application in Python with AJAX, and
it seems like Django and Turbogears are the frameworks that have the
most momentum.

I don't have any practical experience with these, but I've done some
research. My impression is that Pylons has more momentum than TG. The
latter project has declared the 1.x branch to be a dead end, and
they're working on a 2.0 branch that's not out yet. I could be wrong,
but that's what I gathered from my reading.

I'm concerned, though, that these frameworks they may be too specific
to the tasks they were originally developped for (news articles,
AFAIK).

From the reading I did, I gathered that Django was really good if you
want to do what Django is good at, but not as easy to customize as,
say, Pylons. Pylons, on the other hand, is a little more complicated
because it's made of several different parts, but the positive side of
"complicated" is "flexible".

Do you think I should just use eg. CherryPy and some basic AJAX?

Yes or no, depending on what you're trying to do! =)

Good luck
Philip

 

[Bruno Desthuilliers]

Gilles Ganault a écrit :

Hi

I'd like to rewrite a Web 2.0 PHP application in Python with AJAX, and
it seems like Django and Turbogears are the frameworks that have the
most momentum.

I'd like to use this opportunity to lower the load on servers, as the
PHP application wasn't built to fit the number of users hammering the
servers now.

I'm concerned, though, that these frameworks they may be too specific
to the tasks they were originally developped for (news articles,
AFAIK). Do you think I should just use eg. CherryPy and some basic
AJAX?

I can't tell about Turbogears, but you're dead wrong if you think that
there's anything specific to "news articles" in Django. It's *not* a
CMS, it's a web programming framework, and is totally agnostic about
what kind of application you're using it for.

 

[Bruno Desthuilliers]

Philip Semanchuk a écrit :
(snip)

From the reading I did, I gathered that Django was really good if you
want to do what Django is good at, but not as easy to customize as, say,
Pylons.

That was my first impression too, and was more or less true some years
ago. After more experience, having gained a deeper knowledge of Django's
internals, I can tell you this is just not true. You can "customize" it
as you want - meaning: you can use any ORM (or no ORM at all) and any
template language you want, as long as you don't intend to use django's
ORM and template language related features (which just don't exist in
Pylons). IOW : Django is just as flexible as Pylons (or pretty close
to), but has more to offer if you stick to builtin components.

NB : not to dismiss Pylons, which is a pretty great framework too, and
use IMHO better default components (namely SQLAlchemy and Mako).

 

[Philip Semanchuk]

Philip Semanchuk a écrit :
(snip)

That was my first impression too, and was more or less true some
years ago. After more experience, having gained a deeper knowledge
of Django's internals, I can tell you this is just not true. You can
"customize" it as you want - meaning: you can use any ORM (or no ORM
at all) and any template language you want, as long as you don't
intend to use django's ORM and template language related features
(which just don't exist in Pylons). IOW : Django is just as flexible
as Pylons (or pretty close to), but has more to offer if you stick
to builtin components.

Based on what I read, I got the idea that Django *can* be as flexible
as Pylons, but most people find it *easier* to take advantage of
Pylons' flexibility. In other words, no one is saying Django is
incapable, but that it is less focused on making it easy to allow
developers to mix & match components and more focused on providing a
smooth tool with which to work.

NB : not to dismiss Pylons, which is a pretty great framework too,
and use IMHO better default components (namely SQLAlchemy and Mako).

I prefer Mako over the other template languages I've seen.

 

[J Kenneth King]

Hi

I'd like to rewrite a Web 2.0 PHP application in Python with AJAX, and
it seems like Django and Turbogears are the frameworks that have the
most momentum.

I'd like to use this opportunity to lower the load on servers, as the
PHP application wasn't built to fit the number of users hammering the
servers now.

I'm concerned, though, that these frameworks they may be too specific
to the tasks they were originally developped for (news articles,
AFAIK). Do you think I should just use eg. CherryPy and some basic
AJAX?

Thank you for any feedback.

They're not "specific" in the sense that they only build certain types
of applications. However, they do package their own batteries and
expect applications to be designed a certain way. As long as you drink
the kool-aid, everything is smooth sailing. That's what any
"framework" banks on -- being useful to 85% of the web applications;
not all. Even if they advertise themselves as such, it's just not
true.

My suggestion is web.py -- It too has its own set of conventions and
philosophies, but in my experience it is the most loosely coupled in
terms of internal dependencies. Import exactly what you want to use
and deploy it the way that suits you. It gives you batteries but you
have to pick and choose how to put the pieces together. Therefore, it
takes a little longer to get running, but IMO that is the most
flexibility you can ask for without writing your own servers and
frameworks.

Cheers.

 

[Philip Semanchuk]

Philip Semanchuk wrote:
...

I prefer Mako over the other template languages I've seen.

From what I can tell Mako is nearly identical to all other
template languages you might have seen (e.g. PHP style
tags). Thats why I personally would not consider it. Its just
much of a hassle to mix code and design this way.

I prefer TAL (template attribute language, ZPT) [1]
much over the other attempts I've seen ( and I've seen a lot)

That's an excellent example of how Python can accommodate different
tastes. =) I can't stand TAL; I find it awkward and unPythonic. Your
comment makes sense, though. Mako and TAL have very different design
philosophies, and if you really like one, you're probably going to
find the other strange at best.


Cheers
Philip

 

[James Mills]

Philip Semanchuk wrote:
...

I prefer Mako over the other template languages I've seen.

From what I can tell Mako is nearly identical to all other
template languages you might have seen (e.g. PHP style
tags). Thats why I personally would not consider it. Its just
much of a hassle to mix code and design this way.

I prefer TAL (template attribute language, ZPT) [1]
much over the other attempts I've seen ( and I've seen a lot)

That's an excellent example of how Python can accommodate different tastes.
=) I can't stand TAL; I find it awkward and unPythonic. Your comment makes
sense, though. Mako and TAL have very different design philosophies, and if
you really like one, you're probably going to find the other strange at
best.

I agree! And just for the record I prefer
Mako (Not that I really use it at all)

--JamesMills

PS: Web Services FTW

 

[Daniel Fetchinson]

I'd like to rewrite a Web 2.0 PHP application in Python with AJAX, and

it seems like Django and Turbogears are the frameworks that have the
most momentum.

I'd like to use this opportunity to lower the load on servers, as the
PHP application wasn't built to fit the number of users hammering the
servers now.

I'm concerned, though, that these frameworks they may be too specific
to the tasks they were originally developped for (news articles,
AFAIK). Do you think I should just use eg. CherryPy and some basic
AJAX?

The 1.x branch of tg is built on cherrypy, the 2.x branch is built on
pylons. Both branches depend on external packages for most of their
functionality which makes them very flexible. Django is monolithic and
was intended to be monolithic. Of course you can customize it and use
different components than the defaults, but after all *everything* is
customizable since the source code is there and you can modify it. The
point is that tg was designed with flexibility and customizability in
mind, while django was designed with a monolithic infrastructure in
mind.

The 1.x branch of tg is stable and has been for years while the 2.x
branch is in beta but will be released soon as a stable, production
version.

Cheers,
Daniel

 

[Bruno Desthuilliers]

Daniel Fetchinson a écrit :
(snip)

The 1.x branch of tg is built on cherrypy, the 2.x branch is built on
pylons. Both branches depend on external packages for most of their
functionality which makes them very flexible. Django is monolithic

Except that
1/ you can use each component (request handler/dispatcher, templating
system and ORM) standalone, and
2/ you can use any other ORM or templating system.

and was intended to be monolithic.

"highly integrated" would be more accurate than "monolithic" IMHO.

Of course you can customize it and use
different components than the defaults, but after all *everything* is
customizable since the source code is there and you can modify it.

You don't need to touch the source to swap ORM or templating system.

The
point is that tg was designed with flexibility and customizability in
mind, while django was designed with a monolithic infrastructure in
mind.

s/monolithic/integrated/