Tuesday, August 23, 2016

Re: Starting new project -- version 1.10

On Tue, 23 Aug 2016, Michal Petrucha wrote:

> 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".

Michal,

Yesterday evening I started reading a book I bought several years ago
(when django was at version 1.5) for a project that got sidelined. With your
explanation and the book I'm starting to understand the django terminology
and project organization.

> 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.

Let me test my understanding by explaining my crm project. Getting it
right from the beginning will help me a lot.

First, this is a single-user project for my business; I'm not a
professional application developer but have built scientific and business
tools for my use for several decades. Since this, and the other django
application that has been put off for a while, are the only two that I plan
to develop I am not convinced that I need virtualenv and its wrapper. Each
will use python3 and I'll keep django upgraded to the latest version.

Second, now that I better understand the project/app design and disk
layout I'll rename some directories so the distinctions are clearer. Which
leads to my question about apps in a project.

Yesterday, in models.py, I set up the schema based on what I want. The crm
has several components: companies, contacts, activities, opportunities, etc.
Each of these is a single class within models.py. My question is whether
each should be a separate app since there will be methods for adding,
modifying, and deleting rows in the database tables as well as report
generation and views that incorporate data from multiple tables. If so, is
each named as a distinct python module and imported into the main models.py?

Or, should they all remain in models.py with separate modules for adding,
editing, deleting, and reporting that are imported to models.py?

My python2/wxPython applications have an organization that makes sense to
me and works. Since building a browser-based django application is a new
experience I want to learn how best to organize everything.

Thanks for the insights,

Rich

No comments:

Post a Comment