2010-01-14 2 views
13

фона:Как Django Apps связывает статические носители?

Я начинаю использовать Django в первый раз, что и мой первый набег на веб-разработки. Я просто застрял во всем «обслуживании статических медиа». Проведя некоторое время на всех документах и ​​вопросах StackOverflow, я думаю, что понимаю, как он должен работать (т. Е. MEDIA_ROOT, MEDIA_URL, обновление файла urls и т. Д.).

Мой вопрос:

Итак, вот часть я не уверен. Приложения Django должны быть «подключаемыми», т. Е. Я могу перенести приложение из одного проекта в другой. Итак, как эти приложения собирают статические носители?

Например, допустим, что у меня есть приложение «foo», в котором есть шаблоны, которые загружают некоторые файлы css/image. Где я должен помещать эти файлы, чтобы они автоматически включались после включения приложения?

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

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

Кроме того, если это так, существует ли стандартный способ сбора всех моих статических носителей, чтобы было легко узнать, что мне нужно для обслуживания? (I.e., стандартно ли иметь папку с именем «media» или что-то внутри приложения?).

Спасибо,

ответ

9

Конвенции поставить статические СМИ в любом медиа/APPNAME/или статическом/APPNAME/внутри приложения (по аналогии с шаблонами).

Для использования приложений в вашем проекте, которые поставляются со средствами массовой информации, я настоятельно рекомендую использовать django-staticfiles. Он автоматически будет обслуживать медиа (включая медиа в приложениях) в разработке через представление, которое заменяет django.views.static.serve, и оно поставляется с командой управления build_static, которая будет копировать носители из всех приложений в один каталог для работы на производстве.

Обновление: django-staticfiles имеет become part of Django 1.3. Теперь он ожидает, что приложения будут жить в подкаталоге «static /» приложения, а не «media /». И команда управления теперь «собирает».

+0

Теперь это правильный подход, как и Django 1.3. –

+1

Обратите внимание, что https://github.com/jaddison/django-cachebuster/ предоставляет очень полезный тег {% static%} для Django 1.3 – Eli

2

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

Как это работает с ним в том, что она обслуживает своих СМИ через самого Джанго - видеть источник для urls.py:

url(r'^%s/m/(.*)$' % _PREFIX, 'debug_toolbar.views.debug_media'), 

В общем, это плохая идея (вы не хотите, чтобы служить статическим файлы через Django), в this comment from the documentation:

[Порции статические файлы через Django] является неэффективным и небезопасно. Не используйте это в настройке . Используйте это только для разработки .

Очевидно, панель инструментов django-debug используется только для разработки, поэтому я считаю, что ее метод развертывания имеет смысл, но это очень исключение.

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

+0

И как мне избежать именования столкновений/ссылки на него в моем коде? Если у меня есть, скажем, приложение «foo» с медиа-папкой и «бар» с медиа-папкой, то как я могу ссылаться на папку внутри шаблонов приложений, не вызывая проблем? –

+1

Если ваше приложение называется «foobar», обратитесь к своему медиа с помощью '{{MEDIA_URL}} foobar/myawesomejs.js'. Попросите своих пользователей настроить символическую ссылку на 'foobar' в своем медиа-каталоге. –

+0

Я думаю, что мой ответ ниже (с использованием django-staticfiles) - лучшее решение для всех сторон; тем более, что похоже на что-то, основанное на staticfiles, может быть включено непосредственно в Django 1.3. –

2

Я обычно помещаю приложения в медиа./ Приложение/имя_приложение/статические (мои приложения находятся в подпапках приложений)

то я что-то похожее на виртуальном хосте в Apache:

AliasMatch ^/apps/([^/]+)/static/(.*) /home/django/projectname/apps/$1/static/$2 
<DirectoryMatch "^/home/django/projectname/apps/([^/]+)/static/*"> 
     Order deny,allow 
     Options -Indexes 
     deny from all 
     Options +FollowSymLinks 
     <FilesMatch "\.(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf|txt|htm|html|json)$"> 
       allow from all 
     </FilesMatch> 
</DirectoryMatch> 

я также иметь это в моем urls.py для Дева сервера (использовать только для отладки):

def statics_wrapper(request, **dict): 
    from django.views import static 
    return static.serve(request, dict['path'], document_root = os.path.join(settings.BASE_DIR, 'apps', dict['app'], 'static'), show_indexes=True) 
urlpatterns += patterns('', (r'^apps/(?P<app>[^/]+)/static/(?P<path>.+)$', statics_wrapper)) 

это очень удобно, потому что статика URL просто отображаются в файловой системе, например:

http://wwww.ecample.com/apps/calendar/static/js/calendar.js находится в [base_dir]/Apps/Календарь семинаров соток/статический/JS/calendar.js

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

Смежные вопросы