TurboGears vs Django
jo
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
Elver Loho
> Someone of you could give me a good reason to use TG instead of Django?
As I said on the Django list... Take a weekend off, build something
with both, see what you like better :)
Elver
Ed Singleton
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:
>
gasolin
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
Jacob Kaplan-Moss
> but not so good for large complex projects.
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
Ed Singleton
said that I think it isn't as good as TurboGears.
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
Mark Ramm
> > but not so good for large complex projects.
>
> 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.
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
Eric Larson
Just my two cents of course ;)
Eric
Jorge Vargas
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.
how hard it is to easy_install it, and then run quickstart ?
Django gives you an admin environment for free while TG doesn't have
such thing and I have no idea how to create it.
The toolbox (since 0.9) gives some of those features.
TG applys the pattern MVC while Django does it in a strange way.
Django doesn't use AJAX while TG uses Mochikit and JASON.
AJAX is not a tool is a concept. so what you wanted to say is that TG uses JSON instead of XML for AJAX, and the reason for that is that JSON is better both in performance and simplicity.
Django is very compact while TG is assembled with many moduls to put
together.
that's exactly the goal of both frameworks, while Django aims to build a module for every need, TG goes out and takes the best module for certain task and incorpates it. Just two diferent ways of doing the same thing.
Someone of you could give me a good reason to use TG instead of Django?
I have 2 if you don't like what the framework gives for X task don't use it and incorporate your own, best example Javascript you can use anything that's outthere and TG won't complain, a little less is the template which can be added with a small plugin to create the entry point.
The second reason is that you don't have to go out and look at *all* the tools for a task someone in TG has already done that. which is what is happeing with SQLObject/SQLAlchemy, when TG was created SO was the best, right now SA is getting better and ones it's great TG will be at SA, and new people will know that SA is the best ORM in python :)
Thank you,
jo
Wektor
* Django has a nasty ORM (very inconsistent api and error-prone)
* had problems with Djangos regexp url mapping(it seems cool and
powerfull but it was difficult to get working correctly and TG mapping
is more straightforward and is as powerfull)
* TG has much better support for user interaces -- Widgets
* TG has better support for modularization ( TG is using setuptools
and Paste so you can use these in your app; another thing is that at
the moment there is a number of plugins to TG -- Widgets, Template
Languages and more comming )
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
Eric Brunson
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.
Javier Rojas
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, when some link fails, tg searchs for a controller named "default", and passes as arguments all the elements of the URL
Thanks,
e.
anders pearson
> 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/
Kevin Horn
Thx
Kevin H
Yves-Eric Martin
> Can anyone point to an example of how the positional parameter support
> actually ended up working? I couldn't find anything on the wiki or through
> Google, except for trac ticket #73...which isn't very clear.
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
Kaan
> Content-Type: text/html; charset=ISO-8859-1
> X-Google-AttachSize: 2820
>
> Can anyone point to an example of how the positional parameter support actually ended up working? I couldn't find anything on the wiki or through Google, except for trac ticket #73...which isn't very clear.<br><br>Thx<br>
> <br>Kevin H<br><br><div><span class="gmail_quote">On 8/1/06, <b class="gmail_sendername">anders pearson</b> <<a href="mailto:and...@columbia.edu">and...@columbia.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> On 2006-08-01 12:58:08 -0600, Eric Brunson wrote:<br><br>> Fred,<br>><br>> Thanks for the pointer to the article. I've been playing with TG, but<br>> haven't used it for a production application yet. I'm interested in the
> <br>> list's take on this statement:<br>><br>> However, the Django configuration system allows for maximum control<br>> and flexibility. Django URLs can be easily remapped onto an<br>> application after a major refactoring. This helps prevent "link rot"
> <br>> caused by old bookmarks or cached search engine results. "Link rot"<br>> severely hurts the traffic levels and usability of content-based Web<br>> sites that Django was designed to create.
> <br>><br>><br>> Can't turbogears provide default handler that could be used to intercept<br>> "bad" or "old" links and redirect them into a newer or refactored hierarchy?<br><br>Yes. There's also Routes:
> <br><br> <a href="http://routes.groovie.org/">http://routes.groovie.org/</a><br><br>which is a port of the Rails routes system that lets you do all the<br>fancy mapping to support arbitrary URL schemes. Integrating it with TG
> <br>is pretty easy.<br><br>I've used Routes a bit and I love it for supporting legacy url<br>schemes. However, the tradeoff is that it (and Django's regexp based<br>mapping) is very complicated and difficult to debug. If I don't have
> <br>to deal with legacy URLs, I'll go for the simple cherrypy approach<br>every time. The recent addition of positional parameter support in<br>TG has made it easy to support all but the most convoluted URL<br>structures now without introducing the complexity and confusion of
> <br>mapping.<br><br>--<br>anders pearson : <a href="http://www.columbia.edu/~anders/">http://www.columbia.edu/~anders/</a><br> C C N M T L : <a href="http://www.ccnmtl.columbia.edu/">http://www.ccnmtl.columbia.edu/</a><br>
> weblog : <a href="http://thraxil.org/">http://thraxil.org/</a><br><br><br></blockquote></div><br>
>
> ------=_Part_100184_1495228.1154466153486--
http://www.cherrypy.org/trunk/docs/book/html/index.html#id3516454
Kevin Horn
That's exactly what I was looking for.
Kevin H.
jo
softwarehouse in Bologna-Italy to start a project using TurboGears,
please
contact me at:
js...@fastwebnet.it
Jorge Vargas
hi Jo, I think you will probably get better responses if you post a new thread.
jsds
> 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
>
>
>
>
> >
jsds
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>
Elvelind Grandin
I'm used to not allow non-english msg onto the ML, since they usually
is spam. It would be better if you wrote it in english.
--
cheers
elvelind grandin