Jeśli potrzebujesz dostarczyć niestandardowy magazyn plików - popularnym przykładem jest przechowywanie plików na zdalnym systemie – możesz zrobić to definiując niestandardową klasę magazynu. Będziesz potrzebował wykonać następujące kroki:
\nTwój niestandardow magazyn musi być podklasą django.core.files.storage.Storage:
from django.core.files.storage import Storage\n\nclass MyStorage(Storage):\n ...\nDjango musi być w stanie stworzyć instancje twojego magazynu bez żadnych argumentów. To znaczy bez jakiegokolwiek ustawienia z django.conf.settings:
from django.conf import settings\nfrom django.core.files.storage import Storage\n\nclass MyStorage(Storage):\n def __init__(self, option=None):\n if not option:\n option = settings.CUSTOM_STORAGE_OPTIONS\n ...\nTwój magazyn musi implementować metody _open() i _save() wraz z innymi metodami odpowiednimi dla twojej klasy przechowywania. Zobacz poniżej, aby dowiedzieć się więcej o tych metodach.
W dodatki, jeśli twoja klasa dostarcza lokalny magazyn plików musi przeciążać metodę path().
Your storage class must be deconstructible\nso it can be serialized when it’s used on a field in a migration. As long\nas your field has arguments that are themselves\nserializable, you can use the\ndjango.utils.deconstruct.deconstructible class decorator for this\n(that’s what Django uses on FileSystemStorage).
Domyślnie, następujące metody wywołują NotImplementedError i zazwyczaj muszą być nadpisane:
\n\nNależy jednak pamiętać, że nie wszystkie te metody są wymagane i można je celowo pominąć. Tak się składa, że możliwe jest pozostawienie każdej metody niezatwierdzonej i nadal działającej pamięci masowej.
\nNa przykład, jeśli zawartość listy pamięci backendu okazuje się być zbyt droga, możesz zdecydować się nie implementować Storage.listdir.
\nKolejnym przykładem może być backend, który jedynie obsługi zapisywanie do pliku. W tym przypadku, mógłbyś nie potrzebować implementować żadnej z powyższych metod.
\nOstatecznie, które z tych metod są zaimplementowane zależy od Ciebie. Pozostawienie niektórych metod niezaimplementowanych może w rezultacie stworzyć częściowo (prawdopodobnie zepsuty) interfejs
\nDodatkowo zazwyczaj będziesz chciał używać uchwytów zaprojektowanych specjalnie do trzymania niestandardowych obiektów pamięci. To są:
\nWymagany.
\nWywoływany przez Storage.open(), jest to aktualny mechanizm używany przez klasę do otwierania pliku. Musi on zwracać obiekt File, choć w wielu przypadkach, będziesz chciał zwrócić jakąś podklasę implementującą specyficzną logikę dla systemu pamięci
Called by Storage.save(). The name will already have gone through\nget_valid_name() and get_available_name(), and the content will be a\nFile object itself.
Powinien zwrócić aktualną nazwę pliku, który został zapisany(zazwyczaj name jest przekazany, ale jeśli pamięć potrzebuje zmienić nazwę pliku zwróć nową nazwę).
Returns a filename suitable for use with the underlying storage system. The\nname argument passed to this method is either the original filename sent to\nthe server or, if upload_to is a callable, the filename returned by that\nmethod after any path information is removed. Override this to customize how\nnon-standard characters are converted to safe filenames.
The code provided on Storage retains only alpha-numeric characters, periods\nand underscores from the original filename, removing everything else.
Returns a filename that is available in the storage mechanism, possibly taking\nthe provided filename into account. The name argument passed to this method\nwill have already cleaned to a filename valid for the storage system, according\nto the get_valid_name() method described above.
The length of the filename will not exceed max_length, if provided. If a\nfree unique filename cannot be found, a SuspiciousFileOperation exception is raised.
If a file with name already exists, an underscore plus a random 7 character\nalphanumeric string is appended to the filename before the extension.