I'm evaluating the possibility to use TurboGears for a project, but I
have read so many comments about Django vs TurboGears and right now I
am very confused.
I installed both of them in my system and sincerelly I found that
Django is very easy to install and getting started while TG is not so
easy.
Nevertheless I hesitate to trust on the Django semplicity against the
TG complexity and I'm trying to examinate some characteristics in both
of them that interest to me.
Django gives you an admin environment for free while TG doesn't have
such thing and I have no idea how to create it.
TG applys the pattern MVC while Django does it in a strange way.
Django doesn't use AJAX while TG uses Mochikit and JASON.
Django is very compact while TG is assembled with many moduls to put
together.
Someone of you could give me a good reason to use TG instead of Django?
Thank you,
jo
As I said on the Django list... Take a weekend off, build something
with both, see what you like better :)
Elver
Django is easy to get started in, and good for quick easy projects,
but not so good for large complex projects.
Turbogears is more difficult to get started in, but handles large
complex projects better.
It's much the same difference for SQLObject and SQLAlchemy, once your using TG.
So if you're doing something very simple and just want to get it done,
use Django. If it might become more complex, us TurboGears.
Ed
On 7/29/06, jo <j...@sferacarta.com> wrote:
>
We don't know what's your background and purpose of your project.
So a bias suggestion may not fit your need.
You can follow Ian Mouer's IBM article for both django and turbogears.
He give's a good Conclusion for comparing TurboGears and Django
http://www-128.ibm.com/developerworks/linux/library/l-turbogears/#N10402
BTW: If you want to make an AJAX-enabled site, TurboGears is a good
choice.
--
fred
Now, I'm obviously biased (I'm one of the lead developers of Django),
so I I'm going to stay away from the "which should I use" question.
However, this blanket statement that Django isn't good for "large
complex projects" is a very unfair characterization.
There are *plently* of "large complex projects" that use Django; the
one I'm most familier with is Ellington, the commercial CMS that Django
was extracted from. Sloccount reports that it's around 50k lines of
Python code in around 1k files, and I can tell you right now Django
suits it just fine :) I could name any other of other large projects,
but I won't bore anyone.
Point is, the best way to figure out which of these (or any!) tools
suit you is to download 'em and play around. Free Software rocks that
way :) Oh, and if you're a VMware user, a great way to get started
playing around is to download the Python Web Developer VM
(http://www.vmware.com/vmtn/appliances/directory/289); it's got just
about every Python web toolkit pre-installed, and it's super fun for
messing around with.
The point is that sweaping generalizations without any facts or
specifics to back 'em up aren't worth the (virtual) paper they're
printed on. Trust your own judgement.
Jacob
I wholeheartedly think it's the second best web development framework
for large complex sites (Rails is good too), which is saying a lot.
Emphasis there on "I" and "think".
Sweeping generalisations are often quite useful. Django is very good
and you won't discover it's flaws until you've been using it a long
time. A quick play around with it won't tell you anything about it.
(same with TG).
To go back to the comparison with SQLObject and SQLAlchemy. Once is
very easy to get started in, and amazing for the small problems. The
other is quite hard to get started in, but good for complex problems.
That's not to say one is better than the other. I think that's fairly
accepted opinion and most people on this list would agree (I think
even Ian Bicking would agree). It's very useful information to people
who are getting started. If your site is going to be simple, use
SQLObject, otherwise it might be worth putting the considerable effort
into learning SQLAlchemy.
To clarify that I wasn't being excessively biased, I should point out
that I did recommend he should use Django unless he was going to do
something complex. That's the same advice I give to anyone who asks
me (sometimes I don't mention TG as an option if I'm sure they're not
right for it).
I love TurboGears but I don't think it is entirely suited to
beginners, particularly people without programming experience.
Whereas I think Django is (or at least is more so than anything else).
Ed
Jacob is right about this, it's not the size of the project, or it's
complexity that makes the difference here.
It's the kind of complexity you have.
* If there's the right kind of complexity SQLAlchemy is going to be a
huge win over Django's ORM.
* If there's the right kind of complexity Kit's match templates, and
the ability to create your own tag libraries is a huge win over Django
Templates.
* If you are working with complex legacy URL structures that don't fit
into CherryPy's object publishing paradigm the regex based URL -->
object mapper in Django is a huge win over TurboGears.
* If you are desiging sites where Django's admin interface gives you
what you need in a lot of places, that's a significant win over
TurboGears where you'll have to design your own administrative
interfaces.
Both systems reflect their heritage, Django as a CMS, and TurboGears
as the underlying framework of a cross platform application.
Django is more of a coherent whole, so it's easier to learn, but the
component parts of TurboGears have been around a long time and are
used in lots of different contexts so there's more flexibility
built-in to TurboGears.
The particular needs of your application are going to make a big
difference in which framework is best for you. But the good news of
the Django/TurboGears debate is that both are reasonably mature, and
no matter which one you choose you should be able to build whatever
application you need to build. Either way you're going to be more
productive, and create more maintainable code than you would have
without them.
That said, I've made the investment in learning TurboGears and I
personally find it a better fit for what I want to do, with more
powerful templates and a lot more database flexibility that Django.
So, I don't think I'll be making the switch any time soon.
If on the other hand I were putting together a high traffic online
news site, and having a powerful admin interface out of the box were
important to me, I might choose django.
--Mark
I installed both of them in my system and sincerelly I found that
Django is very easy to install and getting started while TG is not so
easy.
Django gives you an admin environment for free while TG doesn't have
such thing and I have no idea how to create it.
TG applys the pattern MVC while Django does it in a strange way.
Django doesn't use AJAX while TG uses Mochikit and JASON.
Django is very compact while TG is assembled with many moduls to put
together.
Someone of you could give me a good reason to use TG instead of Django?
Thank you,
jo
disclaimer: its my personal opinion, i did a core module for a big site
in Django, and i did a front end to a decission support system and am
working on a DB driven CMS with TurboGears
Thanks for the pointer to the article. I've been playing with TG, but
haven't used it for a production application yet. I'm interested in the
list's take on this statement:
However, the Django configuration system allows for maximum control
and flexibility. Django URLs can be easily remapped onto an
application after a major refactoring. This helps prevent "link rot"
caused by old bookmarks or cached search engine results. "Link rot"
severely hurts the traffic levels and usability of content-based Web
sites that Django was designed to create.
Can't turbogears provide default handler that could be used to intercept
"bad" or "old" links and redirect them into a newer or refactored hierarchy?
Thanks,
e.
Can't turbogears provide default handler that could be used to intercept
"bad" or "old" links and redirect them into a newer or refactored hierarchy?
Thanks,
e.
> Fred,
>
> Thanks for the pointer to the article. I've been playing with TG, but
> haven't used it for a production application yet. I'm interested in the
> list's take on this statement:
>
> However, the Django configuration system allows for maximum control
> and flexibility. Django URLs can be easily remapped onto an
> application after a major refactoring. This helps prevent "link rot"
> caused by old bookmarks or cached search engine results. "Link rot"
> severely hurts the traffic levels and usability of content-based Web
> sites that Django was designed to create.
>
>
> Can't turbogears provide default handler that could be used to intercept
> "bad" or "old" links and redirect them into a newer or refactored hierarchy?
Yes. There's also Routes:
which is a port of the Rails routes system that lets you do all the
fancy mapping to support arbitrary URL schemes. Integrating it with TG
is pretty easy.
I've used Routes a bit and I love it for supporting legacy url
schemes. However, the tradeoff is that it (and Django's regexp based
mapping) is very complicated and difficult to debug. If I don't have
to deal with legacy URLs, I'll go for the simple cherrypy approach
every time. The recent addition of positional parameter support in
TG has made it easy to support all but the most convoluted URL
structures now without introducing the complexity and confusion of
mapping.
--
anders pearson : http://www.columbia.edu/~anders/
C C N M T L : http://www.ccnmtl.columbia.edu/
weblog : http://thraxil.org/
On a quickstarted project:
---8<--- snip ---8<--- snip ---8<--- snip ---8<--- snip ---8<---
class Root(controllers.RootController):
@expose(template="agt.templates.welcome")
def index(self):
import time
log.debug("Happy TurboGears Controller Responding For Duty")
return dict(now=time.ctime())
class Obj(controllers.Controller):
class SubObj(controllers.Controller):
@classmethod
@expose()
def method1(self, arg1, arg2, arg3):
return "arg1: %s<br>arg2: %s<br>arg3: %s" % (arg1,
arg2, arg3)
@classmethod
@expose()
def method2(self, *args, **kw):
return "args: %s<br>kw: %s" % (args, kw)
---8<--- snip ---8<--- snip ---8<--- snip ---8<--- snip ---8<---
Then try to hit:
http://localhost:8080/Obj/SubObj/method1/arg1/arg2/arg3
http://localhost:8080/Obj/SubObj/method2/arg1/arg2/arg3?kw1=data1&kw2=data2&kw3=data3
http://www.cherrypy.org/trunk/docs/book/html/index.html#id3516454
> js...@fastwebnet.it <mailto:js...@fastwebnet.it>
>
>
I already did that, it was a message in italian in a new topic titled
"Bologna - Italia" but the message wasn't sent to the list, I think
moderator remove it. :-(
jo
>
>
>
>
> >
If there is anybody interested to give professional support to a
software house in Bologna-Italy to start a project using TurboGears,
please contact me at: js...@fastwebnet.it <mailto:js...@fastwebnet.it>
--
cheers
elvelind grandin