search
top

10 трудностей при изучении Django.

“Чем дальше в лес, тем больше дров”

На написание данного поста подтолкнула статья 10 Django Trouble Spots for Beginners. Это вольный перевод этого материала с множеством “отсебятины” показавшейся мне важной при изучении . Естественно проблем при изучении джанго всплывает гораздо больше чем 10 :-). Описанные проблемы в основном возникают на самых ранних этапах обучения и, особенно при переходе c PHP.

1. это не CMS. Он не умеет из коробки делать то, что делають Wordpress, ModX и другие CMS, но на можно сделать куда более сложные приложения за кратчайшие сроки. У очень функциональная админка, но настройка и разработка на джанго это не совсем так просто как пишут все гораздо сложнее, чем в CMS, потому что это НЕ CMS.

2. У начинающих возникает много проблем с первоначальной настройкой среды разработки на локальном компьютере. Какую IDE выбрать, какие модули python ставить и как это делается, а если учесть что большинство разработчиков мигрируют c PHP и никогда не программировали на python, то это вызывает немало трудностей. И тут не поможет NIMP и Денвер :-). Попробуйте для разработки использовать PyCharm, это великолепная IDE сэкономит вам кучу времени и нервов.

3. Если вы новичок в , то наверняка вас ставили в тупик терминология “проекты” и “приложения”, куда что “совать” и зачем так все запутывать. Конечно же, в итоге все становится на свои места и вы понимаете что проект - это только просто набор (обёртка) для приложений, которых он может содержать великое множество. Думаю, будет корректно сравнить термин “приложение” с гораздо более понятным для большинства термином “плагин/модуль” как в обычных CMS. В отличие от модулей обычных движков в большинстве случаев джанго приложения выполняют только 1-2 функции и могут быть с лёгкостью портированы в другие ваши проекты на . Например, вы строите клон YouTube для этого необходимо создать проект, “MyTube”, который будет содержать приложения, такие как “видео”, “комментарии”, “рейтинги”, “блог”, и т.д.

4.Наследование шаблонов. Наследование шаблонов одна из приятных плюшек в , но у вас уйдет немало времени, что бы понять это. Если сравнивать с движками(CMS), то мне показалось что идея шаблонов в некоторых моментах наиболее близка к системе шаблонизации в ModX(чанки, фильтры, простейшая логика на phx очень напомнили base.html, {% block %}, фильтры, {% if %}, {% else %} и т.д. в джанго) думаю, кто знаком с ModX и меня поддержат. Для тех же, кто работал с другими движками, возможно, возникнет небольшая трудность с пониманием джанго шаблонов.
Для начала создаётся основной шаблон base.html, их может быть несколько для разного функционала сайта, в нем делает блоки header, content, footer …..
<div>
{% block content %}
<p>Если в дочерних шаблонах это блок будет использоваться, то текст здесь перезапишиться</p>
{% endblock %}
<p>Этот же текст будет виден на всех станицах сайта без разницы, какие блоки используются</p>
</div>

В дочернем шаблоне подключаем основной шаблон, и блок content.
{% extends base.html %}

{% block content %}
Этим текстом мы перезапишем текст в блоке content основного шаблона!
{% endblock %}

5. Разделение кода от медиа файлов (фото, js, css ….), это необходимость. сам по себе не предназначен для отдачи статики, на продакшен серверах этим занимаются вэб серверы nginx, apache и поэтому важно, что бы вся статика хранилась в одном месте (обычно это папка media в корне проекта). Вот самая обычная структура джанго проекта:
MyProject
- app
- app2
- media
- javascript
- stylesheets
- images
- ……….
….
для разработки можно использовать исключительно , а отдачу статики можно организовать, написав в urls.py

from .conf import settings
if settings.DEBUG:
urlpatterns += patterns(”,
(r’^robots.txt$’, ‘.views.static.serve’, {’document_root’: settings.MEDIA_ROOT, ‘path’: “robots.txt”}),
(r’^favicon.ico$’, ‘.views.static.serve’, {’document_root’: settings.MEDIA_ROOT, ‘path’: “favicon.ico”}),
(r’^media/(?P<path>.*)$’, ‘.views.static.serve’, {’document_root’: settings.MEDIA_ROOT}),
)

в шаблоне к статическим файлам обращаемся, например так
<img src=”/media/{{ images }}” width=”200″ height=”300″ alt=”">

6. Работа с БД. Так как встроенная в команда syncdb умеет только вносить информацию из моделей в базу данных. Возникает вопрос, как добавлять или удалять полей в уже существующие модели. Тут на помощь придёт South. Умеет:
– отслеживание изменений в модели и создание миграций
– независимость от движков БД (заявлена поддержка 5 разных типов БД)
– создание миграций только для выбранного приложения (application)
– сообщение о возможных конфликтах при комите миграций от других разработчиков

7. Несколько блоков на странице. Поначалу очень сложно понять как же вывести разную информацию на одной странице(допустим верхнее меню, sidebar с облаком тегов и в footer последние комментарии). По логике кажется, что для каждого блока надо делать свою функцию/представление во views.py, но в urls.py нельзя добавить больше одного представления, что же делать?? Эта мысль будоражит мозги начинающих джангистов. Оказывается надо дочитать документацию до конца и там чёрным по белому написано, что для вывода дополнительных блоков надо использовать Template Tags. Вот прекрасный пример кода

8. Аутентификации пользователей. Для аутентификации пользователей лучше всего использовать сторонние библиотеки, например -registration.

9. Установка приложений сторонних разработчиков. Часто при установке “чужих” приложений в консоль валится куча ошибок, в большинстве случаев они указывают на отсутствие нужных модулей python для данного приложения. Единственный способ корректно установить приложение это прочитать его документацию и обратить внимание на требуемые модули питона. Установка модулей происходит через pip или устаревший easy_install.

10. И самая популярная проблема это
- Аааааааааааааааааааааааа, я них……на не понял в этом , вернусь обратно к PHP, Wordpress.
Уважаемые начинающие джангисты, читайте внимательно документацию спрашивайте на форумах, комюнити очень лояльное к новичкам.

Удачной вам разработки.

Связанные записи

blog comments powered by Disqus
top