【问题标题】:Resolving template block structure conflicts with third-party django apps解决模板块结构与第三方 django 应用程序的冲突
【发布时间】:2011-05-09 18:11:52
【问题描述】:

在整合第三方 django 应用程序时,我通常希望它与我的 django 项目的其余部分在美学上相结合。虽然这通常是覆盖应用程序“base.html”(如果那样的话)的问题,但我们的模板结构都略有不同,因此经常出现不兼容问题。例如,假设一个应用程序定义了{% block footer %},并在其模板中将其用于各种事情。如果我已经将{% block footer %} 用于导航栏或版权信息,我不希望应用的模板覆盖我的阻止。

一个更简单的相关案例是对同一事物使用不同的块名称。例如,{% block extra-head %}{% block extrahead %}

解决此类情况的最佳方法是什么?理想情况下,重新映射块会很好,因此您可以执行诸如“将孩子的{% block footer %} 放入父母的{% block content-footer %}”之类的操作。有什么办法可以接近吗?还是只是简单地覆盖每个冲突模板的唯一解决方案?

【问题讨论】:

    标签: python django templates inheritance extensibility


    【解决方案1】:

    首先,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 上将我喜欢的模板放在一起,我已经看到了另一个 - 但到目前为止还没有任何合并围绕一个标准。可能是因为 find-replace 实际上的成本非常低,因为它能够完全按照您的意愿行事,而不会妨碍您的其他规则。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2017-01-24
      • 1970-01-01
      • 2017-10-10
      • 1970-01-01
      • 2011-04-25
      • 1970-01-01
      • 2016-03-22
      • 2019-06-12
      相关资源
      最近更新 更多