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 <[EMAIL PROTECTED] > 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.

--Mark





--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---

Reply via email to