I have an idea for an application where users submit json files that
represent different data that needs to be parsed and put in a DB. I believe
there may be many many different types of this input data over time so I
had this idea that I would break down the different models by applications.
On Mon, 2009-08-10 at 20:51 -0700, MattR wrote:
> Are there any best practices documents to organizing large Django
> projects?
>
> Should the view code be in a file called views.py? It seems like this
> file could get rather large and hard to manage, is there some
> suggested way to break it up
Hallöchen!
MattR writes:
> [...]
>
> Should the view code be in a file called views.py? It seems like
> this file could get rather large and hard to manage, is there some
> suggested way to break it up?
I have a subdir "views", with roughly one module per model, each
typically containing "show
Are there any best practices documents to organizing large Django
projects?
Should the view code be in a file called views.py? It seems like this
file could get rather large and hard to manage, is there some
suggested way to break it up?
Should the files with views even be called views.py, or s
Hi Guillermo!
But what would happen in this case if two sites use very different
templates for the same app?
My templates used to have the same skeleton, the diference could be the
base_site.tmpl, I can replace the base_site.tmpl on the
project/templates/appname, I can use stylesheets to defi
I place my templates inside the "app_name/templates/app_name"
directory. It seems template search path look for the template on this
directory first. So, to decouple the app, templates should be inside it
I think.
But what would happen in this case if two sites use very different
templates for
Hi,
Yeah. And conversely, it's weird that in other places django smooshes
together what ought to be separate namespaces. For example, a
template can refer to the templatetags of any app without
qualification. Is there even a way to add qualification to
disambiguate? If I have two apps with
"Doug Van Horn" <[EMAIL PROTECTED]> writes:
You would put parent_folder and parent_folder/spam_website into your
python path.
So when you need a model from the foo application, you do:
from foo.models import Eggs
and if you need something from the settings module in the project, you
do:
cumentation I
can find doesn't really give any clues about best practices for
project organization. One problem is that the name of the Django
project folder (and thus root module) always seems to creep into the
code in the app-specific directories. Any insight you can offer would
be apprec
David Abrahams wrote:
...One problem is that the name of the Django
project folder (and thus root module) always seems to creep into the
code in the app-specific directories.
IANADE (django-expert), but from what I've gleaned you can put the path
of each individual application into the python
any clues about best practices for
project organization. One problem is that the name of the Django
project folder (and thus root module) always seems to creep into the
code in the app-specific directories. Any insight you can offer would
be appreciated.
in most cases (all for me so far) you ca
For me, Django doesn't seem to be delivering on its promise to allow
me to build a collection of apps and organize them in different
combinations into multiple Django projects, and the documentation I
can find doesn't really give any clues about best practices for
project organiza
Hi -
I'm relatively new to Django, and have a question about site & project
organization.
I have several sites that I'd like to develop using Django. Some of
these sites are "top-level" (site1.domain.com, site2.domain.com) and
some that fall under an existing hostname (
13 matches
Mail list logo
