libjpeg PIL photologue Джанго

Question

Так что я смотрел вверх и вниз хорошее решение для отображения изображений, аудио, средства массовой информации в целом с Джанго:

Из того, что я нашел там следующие решения:

1. Фото:

Невозможно заставить работать. Ему нужны PIL и libjepg.

Я попытался установить оба варианта, но столкнулся с различными проблемами сборки.

Кто-то на StackOverflow рекомендовал мне эту ссылку:

http://appelfreelance.com/2010/06/libjpeg-pil-snow-leopard-python2-6-_jpeg_resync_to_restart/

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

Судо гт -Rf построить

И я не чувствую себя достаточно уверенно, чтобы выполнить команду Судо гт.

Также я думал, что для этого нужно быть более простым способом, поскольку КАЖДЫЙ блог должен отображать медиа.

2. Джанго сам говорит:

Пусть Apache сделать дисплей и использовать это:

(r'^site_media/(?P<path>.*)$', 'django.views.static.serve', 
     {'document_root': '/pathtomedia/', 'show_indexes': True}), 

для развития, но не для производства.

Так что же все используют для производства?

3. Другое:

мне удалось отобразить изображения через os.listdir, urllist и шаблон:

allimg= os.listdir("/pathtomyimages/") 
urllist = ['/site_media/Imagedir/%s' % url for url in allimg] 
return render_to_response('picture_display.html', 
     {'allimg': allimg}) 

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

Я слышал, что решение paginator может быть решением.

Так что теперь мой вопрос:

Что является лучшим, самым простым и надежным решением для отображения медиа в Джанго в разработке и в производстве?

Что вы используете?

Пожалуйста, помогите мне!

Спасибо за внимание.

Answer 1

django-photologue - приложение для управления изображениями и коллекциями изображений для вашего проекта, но напрямую не связано с обслуживанием статических носителей.

Поскольку «наилучшие», «самые простые» и «надежные» - это довольно субъективные термины в зависимости от ваших конкретных потребностей, я рекомендую вам сначала понять, почему распространять обычные медиафайлы из Django не является обычной практикой. Короткий общий ответ заключается в том, что Django должен быть загружен в каждый процесс веб-сервера, который обрабатывает запрос, и это будет использовать нетривиальный объем памяти. При обслуживании медиафайла вы (обычно) просто возвращаете файл с диска. Так как никакой прикладной логики не требуется, вы получаете ненужные служебные данные как из памяти, необходимой для запуска Django в процессе, так и для дополнительной обработки кода, которая будет выполняться для Django для сопоставления пути запроса к представлению, загрузки файла и сбрасывания его в ответ. Веб-серверы (Apache, Nginx и т. Д.) Уже очень хорошо подходят для возврата файлов с диска. Именно поэтому рекомендуется, чтобы ваш веб-сервер обрабатывал статические мультимедийные файлы. Запрос никогда не должен передаваться в промежуточное ПО WSGI или Django.

Существует много вариантов, но есть некоторые, которые, вероятно, будут распространенными решениями. Например, если вы решили использовать Apache в качестве своего веб-сервера, вам нужно настроить его так, чтобы запросы на ваш медиа-путь обрабатывались напрямую Apache, а все остальные запросы передавались Django. Apache + mod_wsgi - довольно распространенный выбор AFAICT. Прочитайте это внимательно:

http://docs.djangoproject.com/en/1.2/howto/deployment/modwsgi/#howto-deployment-modwsgi

Это не строго необходимо настроить отдельный веб-сервер в качестве документов рекомендуется. Вы можете использовать тот же экземпляр Apache для Django и media, когда вы начинаете работу.

Answer 2

Это учебник на самом деле мое :)

sudo RM -rf build, все это делает на самом деле заставить удалить все предыдущие сборки, которые в основном означает, что он очищает ничего общего с сборками.

надеюсь, что это поможет