0

being new to Django (v3.x) I'm trying to write an IDE-like app that allows to:

  1. Create new "work projects" (not as in Django projects, but as in work projects like in an IDE, where each created work project later on contains various artefacts and files)
  2. always in the context of a project upload files to that project and then work with them.

Hence, the structure of my Django app should look like so:

myapp/
     /project/
             /file_1
             /file_2
             /file_3

Accordingly, following best practices of how to build URIs the URL patterns probably ultimately should look like:

myapp/project/<int:project_pk>/file/<int:file_pk>/

What I don't fully understand is: How can I cause Django to always work in the context of a pre-selected project?

Either I do it all in a stateless fashion where users always need to specify the full URL including the project primary key. Problem is that my templates may not know what primary key the current project has, which may cause issues with reverse URLs and the like.

Or I somehow keep the current project primary key as state in some kind of non-global but shared variable among all resources in the same project. Here the problem is obviously how to invalidate the state at the right time etc.

Furthermore, should I use a flat structure of apps (e.g. project, project_files, project_users etc.), or should I nest all my apps under a project app (e.g. project, project.files, project.users etc.)?

What are best practices for such a situation in Django (> v3)? Is there any simple sample app that has such a structure where I could look it up?

user4461099
  • 35
  • 6
  • Does this help https://stackoverflow.com/a/23469321/4901118? – isAif May 17 '20 at 08:22
  • This is a misunderstanding, maybe my description was confusing: I am not looking for a way to structure my Django projects. I am looking for a way to build hierarchical entity models in Django. (Coincidentally, one of my entity is called 'project'.) Let's use different names here: foo and bar. Foo has many bars, but a bar ALWAYS exists only in the context of one foo. In fact, when the user starts the application, then first thing s/he needs to do is to select a foo. Then, all other operations on bar objects always happen in the context of that foo. – user4461099 May 17 '20 at 15:00
  • A work colleague gave me some valuable input. There are more or less 3 ways of handling this: 1. stateless: reading out the project's pk always from the kwargs 2. stateful: writing the project pk into the session variables 3. combination of 1 and 2: when a user accesses a URL then some Django middleware always first checks, whether the project's pk has already been loaded as a session variable. If not, then do so. It does not tell about what is best practice, but at least it provides some guidance. – user4461099 May 18 '20 at 17:11

0 Answers0