On Mon, Aug 22, 2016 at 07:48:44AM -0700, Rich Shepard wrote:
>   One clarification on projects vs applications will help my learning.
> Rather than using the same name for both (based on prior advice), the
> project name is clientmanagment and that directory contains
>       clientmanagement/  crm/  manage.py*
> 
>   The clientmanagement/ subdirectory contains
>       __init__.py   __pycache__/  settings.pyc  wsgi.py
>       __init__.pyc  settings.py   urls.py
> 
> and I wonder why the project-related files in this subdirectory are not
> under the parent project directory. In other words, why is there a project
> subdirectory under the project directory?

This is mostly an issue with how we name things. You have a project,
which is a CRM application. That's the entire thing, which consists of
a bunch of different Python packages. So, each of the subdirectories
in the top-level “clientmanagement” directory is one Python package.
For better or for worse, Python packages containing Django models,
views, URL patterns, and whatnot, are referred to as “Django apps”.

So you have a project named “clientmanagement”, which contains two
Python packages (in other words Django apps), called “crm”, and
“clientmanagement”.

Usually, it's a good practice to split your project into smaller
self-contained packages. Those all live together inside the project
directory, and each of them can have its own URL patterns, models,
views, static files, templates, and pretty much anything else. They
can even depend on each other, although it's often a good idea to keep
the coupling between as low as possible.

Finally, you need one Python package that serves as the “app” that
glues all the other packages together. This is the package (or app)
that contains the settings module, the root URL configuration, the
WSGI entry point, and often also static files, templates, views and
other stuff that only make sense in the context of the project itself,
and cannot reasonably be spun out into a separate package (that would
be things like the base template, or sometimes the landing page view).
This is what you referred to as the “project-under-the-project”.

The reason why this is inside a separate subdirectory is that you want
Python to be able to import it. In theory, you could just put
everything one level higher (and, in fact, that used to be the default
layout created by startproject until a few years ago), but it's
troublesome in practice, because with such layout, all of those files
end up in the global Python import namespace, which can easily lead to
conflicts.

As a final note, if your entire project is really small, and only does
one single thing, it's not entirely unreasonable to use a single
Python package (Django app) for everything – if there are no more than
a couple-three models in the entire project, and just a handful of
views and forms, I just stuff everything into the single package
created by startproject.

I hope this explanation makes sense, and feel free to ask if there's
anything unclear.

Cheers,

Michal

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20160823121159.GO27882%40koniiiik.org.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: Digital signature

Reply via email to