Analysis of Django Project
Andrea Zilio
I'm a graduate Computer Science student and in my Open Source
Technologies class I've chosen Django as the project to write about in
my final exam paper.
So I'll write a short document (7-15 pages) about the vision, target,
innovative features, possible business models, development process and
community status of this project.
I'm not new to Django: I've already used it for more than a year in a
bunch of projects and I liked it (I came from PHP and used some PHP
frameworks in the past), so I already have some ideas about what to
write in this paper.
I'm writing here and opening this thread just because I would like to
know your opinions as django developers or contributors about some
ideas I have and that I'll cover in this document.
This explains why I've sent this message to django-developers and not
to django-users.
If this is not the appropriate place to write I'm sorry and in this
case I'll be glad to know if someone want to share his opinions
anyway, maybe contacting me directly via email.
Otherwise I'll soon post my first question for you in this thread (so
without creating separate discussions) waiting for your feedback.
Thanks in advance to everyone who will participate
P.S.
I'll probably write the document in english (I'm italian), so I'll be
happy to share it with you when finished if you want to. (eta: mid
july).
Russell Keith-Magee
> Hello,
>
> I'm a graduate Computer Science student and in my Open Source
> Technologies class I've chosen Django as the project to write about in
> my final exam paper.
> So I'll write a short document (7-15 pages) about the vision, target,
> innovative features, possible business models, development process and
> community status of this project.
>
> I'm not new to Django: I've already used it for more than a year in a
> bunch of projects and I liked it (I came from PHP and used some PHP
> frameworks in the past), so I already have some ideas about what to
> write in this paper.
>
> I'm writing here and opening this thread just because I would like to
> know your opinions as django developers or contributors about some
> ideas I have and that I'll cover in this document.
> This explains why I've sent this message to django-developers and not
> to django-users.
>
> If this is not the appropriate place to write I'm sorry and in this
> case I'll be glad to know if someone want to share his opinions
> anyway, maybe contacting me directly via email.
> Otherwise I'll soon post my first question for you in this thread (so
> without creating separate discussions) waiting for your feedback.
This is as good a place as any if you're looking to solicit opinions
from the development community around Django. I'm happy to answer a
few quick questions (and even a couple of detailed questions) to help
out.
Yours,
Russ Magee %-)
Andrea Zilio
The first thing I would like to talk about is what I think is the "big
idea" behind Django, related probelms and so to hear about your
opinion on this.
(If you're in hurry just skip to the conclusions reading the last
paragraph ;))
I think that the most important feature of Django framework is the
idea of creating websites aggregating multiple reusable applications.
The idea of reusing components is obviously one of the main principles
of software engineering and it is also widely used in many
environments, but before using Django I have never seen this simple
but brilliant idea in any other *web* framework.
Other frameworks may have plugins, helpers, and various libraries, but
no one shares the concept of build web sites building separate and
reusable applications.
In my opinion, there are two problems about this:
- this innovative difference and its consequences for the developers
are not well advertised. I mean that when someone comes to the Django
website to get an overview of the framework he usually don't get this
crucial idea.
- even when a django beginner user realizes that he could and should
develop different *reusable* applications in order to use them in the
current and future projects and so saving a lot of time, it is
difficult to understand how this can be achieved in practice.
So, the key benefit of using django is not well advertised in the web
site and, the worst, when someone discovers it, it is difficult to
find information about HOW to build reusable applications. I mean that
patterns such as how to organize configuration, how to organize
application files, how to allow easy subclassing of the application it
self, etc.. are not easy to be found and this maybe because there are
not yet standard and established ways to do so.
Instead a user is required to participate, search or listen to
technical Django talks to know about patterns on how to create
reusable applications, about how to organize files, about when to add
a feature to an existing app and when to avoid it, etc...
The result of this is that actually a lot (I think the great part) of
the contributed django applications available online on various web
sites (eg: github, googlecode, etc..) are in fact not easily
*reusable*, *configurable* or *extendable* and, if they were, the
advantage of using Django would also be more evident because building
websites with it would require more and easy integration of existing
applications then actual developing new apps.
Maybe advertising more about the benefits of django and, more
important, making available into the documentation it self patterns
about how to build reusable applications would reduce these problems.
I would like to highlight that I'm not criticizing anyone, I just have
this opinion and I think that it would be useful to share it with you
to improve the future versions of Django or maybe to realize that I'm
wrong.
So, I would like to know if you agree or disagree with me on the
points I've talked about, which are:
- the idea of reusable app is one of the biggest advantages of using
django
- no other famous and widely used *web* frameworks (es: cakephp, ror,
etc...) shares the same idea
- this idea is not well advertised (how many of us started developing
a website in a single and heavy application and only then realized the
"big idea" of reusable apps?)
- patterns to build actual reusable applications are not established
yet or they are not easily available to users to follow, resulting
(with some exceptions) in a lot of not reusable apps or apps
implementing their modularity in very different ways (not following a
patter or a standard method)
I'm really interested in your opinions :)
Andrea
On Jun 12, 12:56 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
Russell Keith-Magee
It's certainly one of the strengths of Django as a framework. However,
I would also point at a couple of other big features that contribute
to Django's success:
* Language choice - Python is a very clean, highly expressive language
* Batteries included philosophy - Django works out of the box with a
minimum of fuss.
* Great documentation - Although it isn't perfect, there's a lot of
officially provided documentation, and it is (for the most part) well
written and clear.
* API stability - our backwards compatibility policy is a strong
selling point for larger customers
> - no other famous and widely used *web* frameworks (es: cakephp, ror,
> etc...) shares the same idea
I don't think I'd agree with this quite as rapidly. Zope, for example,
is essentially a framework for reusable web applications by definition
-- you plug your Zope application into your Zope server. You could
argue over how well the Zope implementation achieves the reusability
goal, but it's hard to argue that the idea of reusable components
aren't at the core of it's architecture.
As for more contemporary frameworks like RoR or Pylons; they may not
make as much of a community noise about reusable apps as part of their
core philosophy, but that doesn't mean that reusability doesn't matter
to users of those frameworks. There is a vibrant community of plugins,
APIs and tools for RoR and Pylons, all intended to maximize reuse.
Reuse isn't a Django-specific feature - other frameworks use different
language and different approaches, but *any* good engineer will aim to
maximize reuse, regardless of the toolset they are using.
> - this idea is not well advertised (how many of us started developing
> a website in a single and heavy application and only then realized the
> "big idea" of reusable apps?)
No disagreement here. In the broader community (through presentations
like those given by James Bennett, and by example in projects like
Pinax) there is a lot of documentation about the reusable app
philosophy. However, we haven't been as effective at integrating this
into the core project website.
There has been some talk recently about adding some more pages to the
tutorial to address this omission -- however, this has also been
discussed many times in the past. It's not a new idea, it's just a
matter of resources. Writing good documentation takes time, doubly so
for tutorials.
> - patterns to build actual reusable applications are not established
> yet or they are not easily available to users to follow, resulting
> (with some exceptions) in a lot of not reusable apps or apps
> implementing their modularity in very different ways (not following a
> patter or a standard method)
Part of the problem here is that standards for reusable apps are still
emerging. Every time we write a new reusable app, we are able to
improve slightly on best practice. contrib.comments was a good example
of a reusable app when it was delivered in v1.0. However, as of v1.2,
it's missing a number of important features (such as URL namespaces
and class-based URL configuration). If Arthur Koziel's GSoC project
lands, that will change best practices yet again.
Interestingly, the idea of documenting best practices for reuse is
actually where Pinax started. Originally, Pinax grew out of a project
called 'Django Hotclub', which was/is a mailing list that was/is
trying to identify best practices for reusability. James Tauber
identified (quite correctly) that it's very hard to have these
discussions in the abstract, so he started Pinax as a way of providing
a testbed for reusability ideas. Pinax has been extremely successful,
and serves as an excellent set of examples for how to do reusability
well; however, the original project of distilling the best practices
into a documented set of guidelines hasn't fared as well.
As for the state of reusability in the wider community -- yes, some
publicly available apps aren't as reusable as they could be. However,
in their defence -- they're exactly as reusable as they needed to be
for their creators. People don't intentionally put bad code up on
Bitbucket et al; they put up code that they have found useful, and
they want to share with the wider community. An app that doesn't reach
the theoretical maximum reusability doesn't mean it isn't reusable, or
isn't useful for some given purpose.
While there is a some theoretical, Platonic ideal of reusability that
could be achieved, actually shipping a product is much more important
-- remember, we're perfectionists with deadlines. While there are some
simple things you can do to maximize reusability, many of the steps
require some serious engineering work -- for example, using url
reversing instead of hardcoding URLs is easy; making a core data model
pluggable (as contrib.comments does) is much harder. Sometimes, the
effort required to make an application completely reusable isn't
warranted by the person who writes the application in the first place.
I'm sure that most of the authors of these "imperfect" apps would
gladly accept patches to improve them, and the more successful the
app, the more likely it will approach best practices. Again, Pinax has
made a habit of this -- find a project in the wild that does something
interesting, and 'adopt it', making it more reusable until it can be
integrated as part of Pinax itself.
Again, this is an area where Django has room for improvement. If there
is a pain point or common patterns that reusable apps need to
implement, we should be providing the infrastructure to minimize the
code that end-users need to write. We rely upon our community to talk
about these pain points, and to propose (and implement) solutions.
Yours,
Russ Magee %-)