Самым популярным фреймворком на Python на данный момент, является Django. И не только потому, что он бесплатный и с открытым исходным кодом, а потому что очень простой и при этом очень даже мощный.
Начнем с рассмотрения того, что нам понадобиться для выполнения наших практических заданий и конечно же создадим новый проект. Не буду говорить первый, возможно вы уже где-то читали про Django и уже создавали свой первый проект.
Начнем с самого начала. Запрос с сервера приходит на сервер и фреймворк должен как-то решить, какой код должен выполнить код. Django есть что-то типа таблицы маршрутизации, в которой вы можете указать для какого URL должна вызываться какое представление, и эта таблица находиться в файле urls.py. В этом файле вначале очень много комментариев, а самое вкусное находиться здесь:
Наверно самым популярным паттерном в Web программировании является MVC – Model, View, Controller или модель, представление, контроллер:
Конечно же вывод данных на страницу простой записью в Response не так уж и эффективно. При работе с сайтами нам чаще приходиться работать с HTML страницами и будет великолепно, если HTML и Python будут жить отдельно и даже в отдельных файлах. Как мы уже видели в предыдущей главе, в Django для этого используется паттерн MVT и HTML как раз должен жить в шаблонах, с которыми мы и познакомимся сейчас.
Из-за того, что файлы UI в Django называют шаблонами (template), возникает серьезная проблема с хорошим переводом для термина, который мы будем рассматривать сейчас.
Мы научились отображать шаблоны, но в них у нас пока находиться только статичная информация, но в реальной жизни далеко не всегда страницы статичны. Например, на моем сайте статичными страницами являются только страница О Блоге и Реклама на сайте. Все остальные отображают какие-то динамические части, которые меняются со временем или в зависимости от состояния.
Прежде чем продолжить работу над новой темой, давайте создадим новое представление, чтобы набираться практики. Надеюсь, что вы повторяете все действия за мной, потому что таким образом можно набирать опыт.
Наше представление views.py продолжает расти и в нем уже несколько методов, хотя в реальности оно пока ничего не умеет делать. Неужели в реальных приложениях представления растут до бесконечности? Если взглянуть на мой блог Flenov.info, то даже у него различных URL будет больше 20 штук, не считая админки и если поместить 20 методов в один файл, то работать с ним потом будет неудобно.
Внешние связи (foreign keys) можно отнести к тонкой настройке, о которой я говорил в предыдущей части, но так уже получилось, что она уже была слишком огромной, поэтому я решил вынести ключи в отдельную небольшую часть.
Мы уже сделали быстрый взгляд на то, как работать с админкой, а сейчас будем чуть ближе знакомиться с системой.
В 9-й части этого мануала мы познакомились с моделями, но у нашей модели было просто пару полей, у которых все параметры установлены по умолчанию, что не есть хорошо. Размер полей не имеет лимитов, поэтому поле для ввода заголовка в админке выглядит как многострочное поле, хотя обычно заголовок не должен превышать 256 символов. Кажется такие рекомендации сейчас с точки зрения SEO.
Когда мы создали новое приложение в прошлом разделе, то вместе с ним мы получили новый файл models.py – это файл, в котором мы должны описывать модель, с которой нам предстоит работать. Я смотрю, что народ еще и пишет тут бизнес логику. Тут снова прослеживается связь с Symfony, при использовании которого программисты так же часто смешивают модель данных и бизнес модель. Я наверно слишком старый и слишком вредный в этом отношении и не люблю таких вещей, а предпочитаю разделять модель данных и бизнес модель (Business Logic).
До сих пор мы работали с данными в панели администратора, которая автоматически отображала формы добавления записей и редактирования существующих данных в зависимости от того, какие сущности мы зарегистрировали. Это прекрасно, мы можем добавлять и редактировать записи в админке, но теперь бы было неплохо получить доступ к этим данных в UI.
Мы уже познакомились с одним методом, который позволяет прочитать данные из базы – это get. В 9-й части этого курса (или книги, как вам удобнее) мы создали представление, в котором читалась запись из базы данных и шаблон отображал ее. Тогда для получения записи мы использовали вот такую строку:
Мы продвинулись достаточно далеко и перед следующей большой темой – работа с формами я хотел бы сказать о небольшом, но очень важном компоненте, который я упустил. О нем желательно было рассказать где-нибудь после шаблонов и приложений и до того, как я затронул базы данных. Но я так торопился дойти до самого интересного и до баз данных, что совсем позабыл об этом моменте.
В части 15 мы создали картинку и поместили ее в приложение блога. Все, что касается блога должно быть в ресурсах именно блога.
Чтобы код лучше поддерживался его нужно делить на небольшие блоки, которые решают одну конкретную задачу. В этой работе я показываю, как делить код на отдельные приложения и отдельные методы, но то же самое можно сделать и с шаблонами. Не стоит пытаться пихать весь HTML в один и тот же файл, их тоже можно делить.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
