Best practice folder hierarchy of a Django Web APp

[Brajeshwar]

Hi,

What type of folder structure do you use for a Django powered Web App?
How do you organize your folders?

I'm talking about an extensive web application and not just a sample
app that you write and finish in a day.

--
Regards
Brajeshwar
_____________________

[shabda raaj]

1. Break your project into logical areas. Let each logical area be a
django app.
2. Read http://www.b-list.org/weblog/2007/mar/27/reusable-django-apps/.
Make each app a reusable app. This is going to save you a lot of
headaches 2 months down the line.
3. Read http://paltman.com/2008/01/29/breaking-apart-models-in-django/.
Break your models into multiple files if needed.
4. Break views into multiple files if needed.
5. Create a urls.py for each app.
6. From your project's mail urls.py do something like
(r'^admin/', include('django.contrib.admin.urls')), for each app.
7. I prefer template organization as

project_name\
templates\sitebase.html
app1\templates\app1\app1base.html
app2\templates\app2\app3base.html
app3\templates\app3\app3base.html

So each of my app templates does a {% extends 'appn/appnbase.html %}
and the appnbase.html does a {% extends 'sitebase.html' %}
8. Have libs package where you dump third party libs which do not go
to pythonpath as needed.

[Brajeshwar]

Thanks, will look into these.

--
Regards
Brajeshwar
_____________________

[Amit Upadhyay]

Hey Shabda,

Those are nice tips indeed. One of the things that you may have to worry about when a project starts growing large over time is django trunk. There is just too much happening in trunk that you would not want to base your new projects on Django-0.96, last official release, so will base off from some revision of trunk. And while django developers are careful in not breaking trunk and announce backward incompatible changes, you may still find yourself using particular revisions of django trunk. Another thing is many times you will find that neat patch that does exactly what you want to do but have not been checked in in django yet, and it may make perfect sense to just apply them. Managing all this will become an issue, and in my pre git era I just checked in django along with my rest of the code. Today I would just use django's git [http://repo.or.cz/w/django.git/] and maintain my own django branch, doing control updates and checking in my selected patches for django. You may have to do this or similar for a few other django or otherwise external libraries too, I had to make some changes in twitter module and pyfacebook etc to support my website, all checked in along with my project.

On Thu, Jun 5, 2008 at 9:48 PM, shabda raaj <shabd...@gmail.com> wrote:

--
Amit Upadhyay
Vakow! www.vakow.com
+91-9820-295-512

[shabda raaj]

How hard is it to move for a svn guy to git? How hard is using Git on
windows?

On Jun 6, 12:30 pm, "Amit Upadhyay" <upadh...@gmail.com> wrote:
> Hey Shabda,
>
> Those are nice tips indeed. One of the things that you may have to worry
> about when a project starts growing large over time is django trunk. There
> is just too much happening in trunk that you would not want to base your new
> projects on Django-0.96, last official release, so will base off from some
> revision of trunk. And while django developers are careful in not breaking
> trunk and announce backward incompatible changes, you may still find
> yourself using particular revisions of django trunk. Another thing is many
> times you will find that neat patch that does exactly what you want to do
> but have not been checked in in django yet, and it may make perfect sense to
> just apply them. Managing all this will become an issue, and in my pre git
> era I just checked in django along with my rest of the code. Today I would
> just use django's git [http://repo.or.cz/w/django.git/] and maintain my own
> django branch, doing control updates and checking in my selected patches for
> django. You may have to do this or similar for a few other django or
> otherwise external libraries too, I had to make some changes in twitter
> module and pyfacebook etc to support my website, all checked in along with
> my project.
>
>
>
> On Thu, Jun 5, 2008 at 9:48 PM, shabda raaj <shabda.r...@gmail.com> wrote:
>
> > 1. Break your project into logical areas. Let each logical area be a
> > django app.

> > 2. Readhttp://www.b-list.org/weblog/2007/mar/27/reusable-django-apps/.

> > Make each app a reusable app. This is going to save you a lot of
> > headaches 2 months down the line.

> > 3. Readhttp://paltman.com/2008/01/29/breaking-apart-models-in-django/.

[Amit Upadhyay]

On Fri, Jun 6, 2008 at 1:04 PM, shabda raaj <shabd...@gmail.com> wrote:

How hard is it to move for a svn guy to git? How hard is using Git on
windows?

For moving you may want to read: http://www.amitu.com/blog/2008/march/git-svn-whys-and-hows/

Windows is pretty good for git, use msysgit instead of cygwin [this is what I have tested and to my taste, comes with unix utilities too so you don't really need cygwin if you have this, corollary: you may face conflicts with PATH if you have both installed].

Our primary repo is svn, and I personally use git to talk to it, but will move to git eventually, the thing stopping me from moving from svn to git altogether is bugzilla integration. There is scmbug, but I ended up writing my own http://code.google.com/p/hooker/source/browse for the same, because I could not configure scmbug on dreamhost in time [who wants to debug perl anyways when we can hack something faster in python -)]. Once I am free, the ever elusive state of being, I will figure out, or hopefully one of you [hint hint, nudge nudge] will and write a decent howto, and I will move to git.

[vidyanand]

For the layout I find this to be the most useful:

http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/



But do note that its a little bit old and I am not sure how much of
that would make sense with the django trunk. I

On Jun 5, 9:18 pm, shabda raaj <shabda.r...@gmail.com> wrote:
> 1. Break your project into logical areas. Let each logical area be a
> django app.

> 2. Readhttp://www.b-list.org/weblog/2007/mar/27/reusable-django-apps/.

> Make each app a reusable app. This is going to save you a lot of
> headaches 2 months down the line.

> 3. Readhttp://paltman.com/2008/01/29/breaking-apart-models-in-django/.

[cschand]

My project stucture is

project_name/
app1/
views
models
urls
app2/
views
models
urls
media/
images/
css/
js/
custom_dirs/ -- for profile picts and uploaded files
templates/
sitebase.html
app1/
index.html
app2/
index.html
shared/
pagination.html -- Common shared template files
db/
project_name.db - if its is sqlite database
middleware/
middleware_1
middleware_2
fixtures/
initial_data.yaml
utils/
tools.py -- common functions like auto_render
thumbnails.py - image resizing
models - for common models like country
templatetags/ -- My template tag folder comes here
math_filters
pagination_filters

The only difference between shabda's post is the template structure.
Both have its own advantages.
If you are assisted by a desinger to template integration put all
templates in a single folder. He can easily find the files and change
the templates.

And for css create a base css file called base.css and link only this
file to template.Import other css file to this base.css.

On Jun 11, 1:59 pm, vidyanand <vidyan...@gmail.com> wrote:
> For the layout I find this to be the most useful:
>

> http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-appli...