Загрузка кастомных template tags в качестве middleware
Django, inclusion_tag, middleware
Добрый день, Дорогие пользователи EVILEG!
Большое количество функционала по формированию шаблонов перевожу на использование
inclusion_tag
и т.д.
Просто последний рефакторинг показал, что ручное прописывание в теории может сэкономить процессорное время, но нифига не экономит время разработки, что лучше повторяющиеся элементы прописать в качестве inclusion_tag и писать так
{% load my_template_tags %} {% my_tag %}
чем вручную писать все html теги
Но посетила мысль, а как запихать модуль тегов внутрь middleware, чтобы каждый раз не писать
{% load my_template_tags %}
а писать только
{% my_tag %}
Реализовывал кто-нибудь такое?
Рекомендуем хостинг TIMEWEB
Стабильный хостинг, на котором располагается социальная сеть EVILEG. Для проектов на Django рекомендуем VDS хостинг.Ол саған ұнайды ма? Әлеуметтік желілерде бөлісіңіз!
Пікірлер
- Akiv Doros
- Қар. 11, 2024, 10:58 Т.Қ.
C++ - Тест 004. Указатели, Массивы и Циклы
- Нәтиже:50ұпай,
- Бағалау ұпайлары-4
- molni99
- Қаз. 26, 2024, 8:37 Т.Ж.
C++ - Тест 004. Указатели, Массивы и Циклы
- Нәтиже:80ұпай,
- Бағалау ұпайлары4
- molni99
- Қаз. 26, 2024, 8:29 Т.Ж.
C++ - Тест 004. Указатели, Массивы и Циклы
- Нәтиже:20ұпай,
- Бағалау ұпайлары-10
вроде так не делается. точнее, ясно понятно, можно(но сложно и не очевидно), но не делается. По идеологическим причинам. по поводу времени разработки - не понял. вроде добавить load ... в pycharm-е, который умеет сканировать темплейт тэги - не сильно длительный процесс.
Поэтому и хотелось услышать стороннее мнение. Стоит ли вообще заморачиваться с middleware.
А по поводу скорости разработки, это относится к причине, когда прописывал всю вёрстку руками, в итоге получилось много дублирования, которое при поддержке проекта превращается в исправление кода во многих шаблонах, когда при наличии inclusion_tag позволит сделать исправление только в одном шаблоне. В общем исправляю накопившийся технический долг, который сформировался в то время, когда у меня ещё не было устоявшегося взгляда на формирование некоторых элементов дизайна сайта. То есть конкретно к вопросу это не относится.
А что касается наличия или отсутствия load , то согласен - это не так долго и времени не отнимает, просто размышляю над тем, как лучше сделать.
я стараюсь делать какие-то куски кода - чем-то вроде компонентов в JS фреймворках. тоесть один шаблон - законченый компонент, например одно поле формы оно может содержать лейбл, само поле, поле описания ошибки и все прочее, а всю форму собирать из этих самых компонентов. при этом получившаяся форма - тоже компонент. а данные передавать как аргументы. так, что поправив один шаблон одного компонента, он меняется везде. получилось достаточно удобно.
при этом, из-за pre-load модели инициализации, все работает быстро - каждый шаблон находится и загружается в память на этапе инициализации.
правда иногда некоторые страницы я делаю полностью на JS - иногда так оказывается проще. но тогда могут возникнуть проблемы с SEO и прочим, а мне пока не хватает квалификации настраивать server side rendering=)
А я на днях добрался до переопределения ForeignKey Field и ManyToManyField. Забодало меня настраивать виджеты в формах, чтобы autocomplite работал на фронтенде пользователя, а то в Django автокомплит для этих полей работает только в Админке. Прикрутил в переопределённых формах django-autocomplite-light, после чего поудалял настройку виджетов во всех формах, только поменял поля ForeignKey на свои кастомные с указанием шаблона url для автокомплита.