0

Building a "history" system that serves static pages based on the date the user asks for. Not all dates have associated pages, and it isn't possible to know, based on what's in the database which do, which don't. I haven't been able to find a way to redirect to a static page because there doesn't seem to be any way to capture the value of the {{STATIC_URL}} tag on the python side. I have got some code that depends on the static file being on the same file system as the django server, but that is clearly wrong. I have two needs:

1: how can I (redirect?) to the static page(s) from my views.py file?

2: how can I query for the existence of a particular one of those static pages?

griswolf
  • 71
  • 1
  • 5

2 Answers2

0

I'm not certain from your question if you understand the intention of the {{ STATIC_URL }} tag. It is a URL prefix for static content files such as css, javascript, or image files. It is not intended as a path for your own static HTML files. In the end I'm not sure you are asking the right question for what you are wanting to accomplish.

zzzirk
  • 1,582
  • 2
  • 14
  • 18
  • Umm. OK, then what is Django best practice for serving up "external" static files? What I'm hoping for is a way to programmatically keep track of which files have been put (wherever they go), without having them on the same file system as the django code. Am I stuck with having a human in the loop twice? (Once to upload the file, once to somehow "mark" that it is present.) I'm still reading django manuals, which is probably not the most efficient way to get at esoteric details. – griswolf Oct 06 '12 at 06:01
  • Generally static files are maintained within the app they are used for and served during development via the `'django.contrib.staticfiles.finders.FileSystemFinder'` in the `STATICFILES_FINDERS` tuple from the `settings.py` file. Once you go into production you specify the `STATIC_ROOT` which is a directory on your filesystems where the web server (apache or whatever) will serve static files from. When you deploy you initiate a `manage.py collectstatic` command which will consolidate all the static files from where they live in your project into the directory specified in `STATIC_ROOT`. – zzzirk Oct 08 '12 at 22:02
  • OK. I'm perceiving you having a blind spot about what I need/want. Often, when I have that perception, it is really about **my** blind spot, so perhaps I'd best go off and commune with the spirits a bit. Meanwhile, please consider the scenario I'm actually describing: – griswolf Oct 10 '12 at 00:45
  • (trying to describe) 1: I deploy a "finished" app that needs to serve some static html files. Not CSS or javascript, but actual html files which happen to have no dynamic content 2: Over the course of time, that set of static html files grows as the users and administrators interact with the app. (Created by admins) The question is (has become): What is django best practice for files such as are described above? Thanks – griswolf Oct 10 '12 at 00:52
  • Thank you so much for clarifying and I sincerely apologize for not grokking what you needed initially. So are these static HTML files that are somehow uploaded to the system, or just added directly to the filesystem by the administrators? – zzzirk Oct 10 '12 at 04:00
  • Thanks. It could be either way. The static files that triggered this discussion are schedules for events. Each event starts as a description of the entertainers, and as these entertainers interact with the event staff, the schedule for the event is created. That schedule (for each event), as a static html file, is what triggered this question. Event staff right now are also admins but that need not always be the case, so a file-upload option could happen. Right now they are added directly to the FS. The "history" aspect is that these events and their schedules remain in place over time. – griswolf Oct 11 '12 at 05:17
  • Typically static pages such as you are describing would be handled outside of Django, by whatever web server you are using. I use apache for example and would setup a URL in my apache config to point to a location that would house these pages. Another alternative that is handled within Django would be the flatpages module. That may be closer to what you are looking for: https://docs.djangoproject.com/en/1.4/ref/contrib/flatpages/ – zzzirk Oct 11 '12 at 13:18
  • OK. That is the conclusion I was coming to. Thank you for your patience. – griswolf Oct 12 '12 at 18:37
  • No worries, I hope that was at least somewhat helpful. – zzzirk Oct 12 '12 at 18:38
0

As zzzirk says: Django really isn't about flat pages, so the most Djangonic solution is to put flat pages beside the django app, not within it.

griswolf
  • 71
  • 1
  • 5