On Mon, Jun 14, 2010 at 3:28 AM, Andrea Zilio <m.ep...@gmail.com> wrote: > So, Here I am. > > 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
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 %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
