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?
> 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?
> Django is easy to get started in, and good for quick easy projects, > 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.
To be fair I didn't say that Django isn't good for large projects, I 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
On 7/30/06, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> > Django is easy to get started in, and good for quick easy projects, > > 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.
> > Django is easy to get started in, and good for quick easy projects, > > 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.
One small thing that made a big difference to me was the fact that TurboGears uses rather common libraries. What this has meant for me is reuse. I have many projects that will never even include a web interface or involve any sort of javascript. In these cases, I am very happy I learned about TurboGears because it let me understand great tools along with how to effectively integrate them into different applications. I understand Django is currently working on this as well which is great, but in my case, learning TurboGears gave me the most knowledge so that was what I spent more time learning. The result is I have a reasonably good understanding of cherrypy, sqlobject, mochikit, kid, cheetah, buffet, cherrytemplate, paste, etc. all because I went with TurboGears.
Just my two cents of course ;)
Eric
On 7/30/06, Mark Ramm <mark.mchristen...@gmail.com> wrote:
> > > Django is easy to get started in, and good for quick easy projects, > > > 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.
> 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 :)
I worked for a while with Django and switched to TG because: * 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
> BTW: If you want to make an AJAX-enabled site, TurboGears is a good > choice.
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?
> 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 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?
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.
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.
Thx
Kevin H
On 8/1/06, anders pearson <and...@columbia.edu> wrote:
> On 2006-08-01 12:58:08 -0600, Eric Brunson wrote:
> > 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?
> 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.
Kevin Horn wrote: > 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.
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())
Kevin Horn wrote: > 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.
> Thx
> Kevin H
> On 8/1/06, anders pearson <and...@columbia.edu> wrote:
> > On 2006-08-01 12:58:08 -0600, Eric Brunson wrote:
> > > 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?
> > 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.
> 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>
> Kevin Horn wrote: > > 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.
> > Thx
> > Kevin H
> > On 8/1/06, anders pearson <and...@columbia.edu> wrote:
> > > On 2006-08-01 12:58:08 -0600, Eric Brunson wrote:
> > > > 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?
> > > 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.
> > 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>
If there is anybody interested to give professional support to a softwarehouse in Bologna-Italy to start a project using TurboGears, please contact me at: j...@fastwebnet.it
Jorge Vargas wrote: > On 8/4/06, *jo* <j...@fastwebnet.it <mailto:j...@fastwebnet.it>> wrote:
> hi Jo, I think you will probably get better responses if you post a > new thread.
> If there is anybody interested to give professional support to a > softwarehouse in Bologna-Italy to start a project using TurboGears, > please > contact me at: > j...@fastwebnet.it <mailto:j...@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. :-(
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: j...@fastwebnet.it <mailto:j...@fastwebnet.it>
I might have been me that removed it :/ 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.
> > On 8/4/06, *jo* <j...@fastwebnet.it <mailto:j...@fastwebnet.it>> wrote:
> > hi Jo, I think you will probably get better responses if you post a > > new thread.
> > If there is anybody interested to give professional support to a > > softwarehouse in Bologna-Italy to start a project using TurboGears, > > please > > contact me at: > > j...@fastwebnet.it <mailto:j...@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. :-(
