Урегулирование конфликтной структуры шаблонных блоков со сторонними приложениями django - PullRequest
3 голосов
/ 09 мая 2011

При подключении стороннего приложения django я обычно хочу, чтобы оно эстетически интегрировалось с остальной частью моего проекта django. Хотя обычно это вопрос переопределения приложения «base.html» (если таковой), мы все структурируем наши шаблоны немного по-разному, поэтому часто возникают несовместимости. Например, предположим, что приложение определяет {% block footer %} и использует его для различных целей в своих шаблонах. Если я уже использую {% block footer %}, например, для навигационной панели или информации об авторских правах, я не хочу, чтобы шаблоны приложения переопределяли мой блок.

Более простой, связанный случай будет использовать разные имена блоков для одной и той же вещи. Например, {% block extra-head %} против {% block extrahead %}.

Как лучше всего разрешать подобные ситуации? В идеале было бы неплохо переназначить блоки, чтобы вы могли делать такие вещи, как «положить {% block footer %} дочернего элемента в {% block content-footer %} родительского». Есть ли способ приблизиться к этому? Или единственное решение просто переопределить каждый конфликтующий шаблон?

1 Ответ

1 голос
/ 10 мая 2011

Во-первых, наследование html должно идти:

my-sitebase.html
 |-- app-base.html
   |-- app-foo-template.html

Я думаю, это то, что вы имели в виду, но формулировка была немного двусмысленной.Возможно, вы сможете просто отредактировать app-base.html.

Во-вторых, повторно используемое приложение, которое переопределяет что-то вроде {% block footer%}, почти умышленно вызывает проблемы у всех, кто его использует - вы должны пометитьчто в трекере проблем провайдера.

Если приложение делает что-то с {% block footer%}, это должно быть сделано в области app-base.html, поэтому вам нужно изменить его только один раз при интеграции сВаш сайт.

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

Была предпринята пара попыток создатьстандартный шаблон наследования, я собрал один шаблон, который мне нравится для шаблонов на djangoslingshot.com, и я видел еще один - но до сих пор не было никакого слияния вокруг стандарта.Скорее всего, потому что поиск-замена на самом деле очень низкая цена за то, что вы можете делать именно то, что вы хотите, без чьих-либо правил, мешающих вам.

...