#9535 closed Cleanup/optimization (fixed)
File uploads documentation is patchy
Reported by: | Owned by: | ANUBHAV JOSHI | |
---|---|---|---|
Component: | Documentation | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | anubhav9042@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I've been working on a new file upload interface for my application, and I notice that since the file upload refactor and the documentation refactor, the file uploads documentation fails to adequately answer simple questions about file upload workflows - everything has to be patched together from various reference information: the "File Uploads" page, the "Managing Files", models.File/ImageField, forms.File/ImageField, and (the hardest to find) "The File Object".
I believe, first and foremost, the documentation does not adequately describe how to save uploaded files to models, ie. use of instance.field.save()
.
However more generally I think the "File Uploads" page keeps going off on a tangent about UploadedFile
APIs and UploadHandler
APIs. These should be documented in full elsewhere, so that the "File Uploads" page could simply cover common workflows:
- Uploading files via
forms.ModelForm
(far and away the most straightforward approach and worth covering first). - Saving uploaded files to a
models.FileField
, retrieving them again and deleting them. - Accessing uploaded files - what to find in
request.FILES
. - Processing uploaded files - reading chunks or lines.
- Default upload handler behaviour (with further discussion of upload handlers on some other page)
I notice one misleading comment which is tangential to this ticket. Many browsers just submit the content type for uploaded files as 'application/octet-stream'. Therefore the comment alongside UploadedFile.content_type
is misleading: "trust but verify" approach is not wrong or right but simply won't produce useful results.
Change History (14)
comment:1 by , 16 years ago
milestone: | → 1.1 |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 16 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 16 years ago
comment:4 by , 15 years ago
milestone: | 1.1 |
---|
While I agree better documentation is needed here, this ticket represents a request for a rather large chunk of it and 1.1 needs to get out the door.
comment:5 by , 14 years ago
This just came up on the mailing list, and as I started to look at the problem I found the docs in pretty much the same state today (a year on from the last update).
The required reading to work with file uploads (and File/Image model fields) is spread around on the following pages:
- http://docs.djangoproject.com/en/dev/ref/files/file/
- http://docs.djangoproject.com/en/dev/topics/http/file-uploads/
- http://docs.djangoproject.com/en/dev/topics/files/
- http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.FileField
If people are happy with the idea of taking the http/file-uploads topic and expanding there, we can probably reduce the mystery a bit by adding some additional examples. Personally, when it comes to working with models.FileField.save()
directly, my initial stumbling block was I didn't get that contents
argument needed to be an instance of django.core.files.File
rather than a regular file object. This is mentioned quietly.
comment:6 by , 14 years ago
I find myself dealing with the docs related to Django's file handling APIs a lot lately for one reason or another. It seems to be a corner of the docs that have languished for some time. As such, I'm in complete agreement that this can be improved substantially.
Organizationally, A lot of what's in topics/http/file-uploads
belongs in a reference document. It's a pet peeve of mine when the only reference for entire classes winds up in a topic or how-to guide. FileUploadHandler
and UploadedFile
ought to be spec'd out somewhere else.
With those bits moved out of the way, the topic guide can then focus on the nitty gritty of how to actually accomplish things using those APIs rather than just showing them to you.
All of the bits mentioned in the ticket description and in the comments would make worthy additions to the document. I'm happy to review patches if anyone wants to take a stab at it.
comment:7 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Cleanup/optimization |
comment:10 by , 11 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
Version: | 1.0 → master |
comment:11 by , 11 years ago
Cc: | added |
---|---|
Owner: | set to |
Status: | new → assigned |
comment:13 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
r10816 refs this.