Welcome to the Hot Club of France!

The ultimate goal is to develop conventions, code and maybe a site or  
two for helping make Django apps that work well together.

Here is an extract from a post I made to django-users:

"""
The idea is that an app or contrib package that follows the "Hot Club
of France" conventions "jams" well with other apps and contrib
packages in the Hot Club of France. And if ones own site (even if not
open-source) follows the HCoF conventions,  it will be easier to plug
in features provided by the Hot Club of France.

Let me give a concrete example. Consider my flashcard site,
Quisition, which is built on Django. The core of the site is
flashcards, but much of what I have and what I want to add could be
generic. It currently uses account management code based on that
provided on [James Bennett's] blog. It uses the feed package for  
providing a feed
of new card packs. I plan to use the comments packages for providing
comments on new packs. But I'd also like to add tagging of packs. And
rating. And possibly the ability for users to add other users as
"friends".

If written properly, all those components could be reusable on
completely different sites. For example, I'm also working on a site
for filmmakers to share tips, discuss gear, critique each others
work, network, etc. There should me a lot of reusable apps between
those two sites, even if the sites themselves are on completely
different topics. Even with very different *core* apps, the support
apps could be shared if conventions were followed.
"""

James Bennett has suggested the following on django-users as some  
tips for more reusable apps:

"""
1. Good conventions for code structure, so things end up in
predictable locations.
2. Use of the "app directories" template loader so you can distribute
sample templates with the app.
3. Careful import statements which don't rely on the name of an
overarching project (which isn't hard, but a little different setup
from when people do a project where all the apps live in directories
under the project dir).
4. Documentation. Can't stress this one enough: having both standalone
documentation and docstrings and comments throughout the code can make
or break an app's reusability.
"""

I'm also thinking of things like conventions for CSS classes as well  
as a skeleton project that HCoF apps can be dropped straight into for  
try out.

On this second point, consider just as a concrete example James  
Bennett's Cab project which is the core app of djangosnippets.org. If  
you download Cab, you can't try it out immediately without having a  
project with a base.html template and a few other things already set up.

Anyway, the idea of this post was to just throw a bunch of ideas out  
there.

My suggestion is we just have an open brainstorm here for a while and  
see what sort of consensus emerges as to the best way forward.

James
--
James Tauber              http://jtauber.com/
journeyman of some   http://jtauber.com/blog/

I love all of these ideas!  Adding on to #3 and #4, we should make
sure to change some of the documentation as well (the tutorials,
specifically) so that people get into the habit of doing this from the
start.

Also, I was wondering if there should be sort of a script which can
take these "HCoF" layed-out apps and puts them into an app layout that
fits each user's existing project layout.  I.E. it would look in the
settings at MEDIA_ROOT and TEMPLATE_DIRS and "install" them into the
right place.

This kind of flies in the face of the egg-style pluggable objects, for
sure.  However, it is one of the ways that we could solve the problem
of having media be served from a variety of different places that may
not be in the same directory.

What do you guys think?

-Eric

Has there been any more talk about this?  Offline, perhaps?

-Eric

On Tue, 27 Feb 2007 07:25:24 -0000, "flo...@gmail.com"
<flo...@gmail.com> said:

Not that I'm aware of.

James
--
  James Tauber               http://jtauber.com/
  journeyman of some    http://jtauber.com/blog/