Opened 8 years ago
Last modified 8 years ago
#27357 new New feature
Variant of FilePathField that uses a Storage backend
| Reported by: | Curtis Maloney | Owned by: | nobody |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | 1.10 |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | yes |
Description
It seems inconsistent that our FilePathField doesn't use abstracted storage unlike pretty much all other file access.
Change History (2)
comment:1 by , 8 years ago
| Needs documentation: | unset |
|---|
comment:2 by , 8 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
Tentatively accepting, though a design proposal and a description of the use case is needed.
Note:
See TracTickets
for help on using tickets.
The
FilePathFieldform field looks coupled to the file system (os.walk(), etc). Maybe it would be enough to try to add a storage agnostic file path form field and allow developers to use it withmodels.FileField. Whilemodels.FilePathFieldtakespath,math,recursive,allow_files, andallow_foldersarguments, it's not doing anything with them besides passing them to the form field.