Приложение Django, которое может обеспечить удобную для пользователя функцию многократной / массовой загрузки файлов в другие приложения

StackOverflow https://stackoverflow.com/questions/1627165

  •  06-07-2019
  •  | 
  •  

Вопрос

Я собираюсь быть честным:этот вопрос я задал в списке рассылки Django-Users на прошлой неделе.Поскольку я еще не получил там никаких ответов, я перепостирую это на Stack Overflow в надежде, что здесь это привлечет больше внимания.

Я хочу создать приложение, которое упрощает работу с пользователем, многократная / массовая загрузка файлов в ваших собственных приложениях.С удобным для пользователя я имею в виду загрузить, таких как Gmail, поддержка сервиса Flickr, ...где пользователь может выбрать несколько файлов одновременно в диалоговом окне "Обзор файла".Затем файлы загружаются последовательно или параллельно, и на странице отображается краткий обзор выбранных файлов с индикатором выполнения рядом с ними.Кнопка "Отмена" кнопка загрузки также является возможным вариантом.

Вся эта тонкость обычно решается с помощью флэш-объекта.Полные существуют решения для клиентской части, такие как:SWFUpload Загружать http://swfupload.org/ , Необычная загрузка http://digitarald.de/project/fancyupload/ , Загрузчик YUI 2 http://developer .yahoo.com/yui/uploader/ и, вероятно, многие другие.

Конечно, хитрость заключается в интеграции этих решений в ваш проект .Особенно в таком фреймворке, как Django, double so, если вы хотите чтобы его можно было использовать повторно.

Итак, у меня есть несколько идей, но я не эксперт по Джанго, ни на Флэш загрузите решений.Я поделюсь своими идеями здесь в надежде получить отзывы от более знающих и опытных людей.(Или даже просто несколько ответов типа "Я тоже этого хочу!" :) )

Вы заметите, что я делаю несколько предположений:это делается для того, чтобы держать под контролем (начальную) область применения приложения.Эти предположения конечно, спорны:

Ладно, моя идея пока что:

  • Если вы хотите массово загружать несколько файлов, у вас будет модель, в которой будет содержаться каждый файл.Тоесть.модель будет содержать одно поле FileField или одно поле ImageField.Модели с несколькими (но, конечно, конечным) количеством файловых полей/ imho, поля изображений не нуждаются в простой массовой загрузке:если у вас есть модель со 100 файловыми полями, вы делаете что-то неправильно :) Примеры, в которых вы хотели бы, чтобы я представлял массовую загрузку:

    • Приложение, в котором есть только одна модель "Брошюры" с полем file, полем title (динамически создаваемым из имени файла) и полем date_added date_added.
    • Приложение для фотогалереи с моделями "Галерея" и "Фото".Вы выбираете Галерею для добавления изображений, загружаете изображения и новые фотообъекты создаются и для выбранной галереи устанавливаются внешние ключи.

  • Было бы неплохо, чтобы иметь возможность настроить или продлить программа для вашего любимые решение вспышка загрузки.Мы можем выбрать один из трех вышеперечисленных вариантов по умолчанию, но реализовать приложение так, чтобы люди могли легко добавлять дополнительные реализации (вроде как Django может использовать несколько баз данных).Пусть это не зависит от какого-либо конкретного решения на стороне клиента.

  • Если мы должны выбрать один, чтобы начать с, может выбрать тот, с наименьшую площадь?(наименьшая загрузка материалов на стороне клиента)

  • Решения на основе Flash асинхронно (и либо последовательно, либо параллельно) ОТПРАВЛЯЮТ файлы по URL-адресу.Я предлагаю, чтобы URL был локальным для нашего общего приложения (поэтому он одинаков для каждого приложения, в котором вы используете наше приложение).Этот URL-адрес приведет к просмотру, предоставляемому нашим универсальным приложением.

  • Представление выполнит следующее:создайте новый экземпляр модели, добавьте файл , ПРИ НЕОБХОДИМОСТИ ВЫПОЛНИТЕ ДОПОЛНИТЕЛЬНЫЕ ДЕЙСТВИЯ и сохраните экземпляр.

  • ДОПОЛНИТЕЛЬНЫЙ МАТЕРИАЛ - это код, который хочет запустить приложение, использующее наше приложение.Ему не нужно предоставлять какой-либо дополнительный код, если в модели есть только поле FileField / ImageField, стандартный код представления выполнит эту работу.Но большинство приложений захотят сделать дополнительные вещи, я думаю, например, заполнить другие поля:title, date_added, внешние ключи, manytomany, ...

  • Я еще не думал о механизме для ВЫПОЛНЕНИЯ ДОПОЛНИТЕЛЬНЫХ ДЕЙСТВИЙ.Просто на ум пришел перенос общего представления приложения, но это не подходит для разработчиков , поскольку вам пришлось бы написать свой собственный шаблон URL и свой собственный вид.Затем вы должны указать решениям Flash использовать новый URL и т.д...Я думаю, здесь можно было бы использовать что-то вроде сигналов?

  • Формы /Администратор:Я до сих пор очень отрывочны о том, как все это может быть интегрированный в админке или родовой формы в Django/виджеты/...(и это показывает мой опыт отсутствия Django):

    • В случае с приложением "Галерея / Фото":Вы могли бы предоставить виджет массовой загрузки фотографий в форме сведений о галерее .Но что, если экземпляр Галереи еще не сохранен?Режим загрузки файла не сможет установить внешние клавиши для экземпляров фотографий .Я вижу, что приложение аутентификации, когда вы создаете пользователя, сначала запрашивает имя пользователя и пароль и только затем предоставляет вам увеличенную форму для заполнения адресов электронной почты, выбора ролей и т.д.Мы могли бы сделать что-то вроде этого.
    • В случае приложения только с одной моделью:Как бы вы предоставить форму в админке Django, чтобы сделать ваш массы загрузите?Вы не можете сделать это с подробной формой вашей модели, это только для одного экземпляра модели.

Вероятно, есть еще десятки вопросов, на которые нужно ответить, прежде чем Я смогу хотя бы начать работать с этим приложением.Поэтому, пожалуйста, скажи мне, что ты думаешь!Подарить мне вход!Что тебе нравится?Что нет?Что бы вы сделали по-другому? Обоснованна ли эта идея?Где этого нет?

Спасибо!

Это было полезно?

Решение

Я только что выпустил простое приложение для этого около месяца назад: django-uploadify (загрузить).

По сути, это тег шаблона Django, который действует как оболочка для очень изящного Загрузить (требуется jQuery).Использовать его так же просто, как добавить это в свой шаблон...

{% load uploadify_tags }{% multi_file_upload ‘/upload/complete/url/’ %}

Тег запускает события (по 1 на файл) как на стороне клиента, так и на стороне сервера (сигнал Django), чтобы указать, когда был получен входящий файл.

Например, предположим, что у вас есть модель "Media", которая обрабатывает все загруженные пользователем файлы...

def upload_received_handler(sender, data, **kwargs):
    if file:
        new_media = Media.objects.create(
            file = data,
            new_upload = True,
        )
        new_media.save()

upload_recieved.connect(upload_received_handler, dispatch_uid=‘whatever.upload_received’)

Посмотрите на Вики для получения информации о том, как его настроить и создать обработчики сигналов (клиент / сервер).

Что касается вашей концептуальной реализации, описанной выше, то вот несколько моментов для рассмотрения:

  • Автоматическое создание приложением экземпляра "Файловой модели", вероятно, не так надежно, поскольку у людей, возможно, уже есть свои собственные модели, с которыми они работают
  • Если вы хотите реализовать какой-либо тип безопасности или аутентификации, вам нужна открытая система и меньше типа "автоматического создания"
  • Я действительно думаю, что сигналы / события - это способ справиться с этим, а также с частью "ДЕЛАЙ ДРУГИЕ ВЕЩИ" из того, что ты упомянул.
  • Мой вывод состоял в том, что многократная загрузка никогда не может на самом деле быть виджетом формы в том смысле, в каком Django реализует виджеты формы.1 файл, скорее всего, будет представлен 1 экземпляром модели (с некоторыми исключениями), что означает, что в конечном итоге мы имеем ситуацию, когда 1 виджет может представлять N экземпляров модели.Однако Django настроен так, что виджет представляет 1 значение для 1 поля в 1 экземпляре.Для большинства вариантов использования это просто не подходит в качестве виджета (следовательно, почему я пошел по пути тега шаблона).
Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top