解决模板块结构与第三方 django 应用程序的冲突
当合并第三方 django 应用程序时，我通常希望它能够与我的 django 项目的其余部分美观地集成。虽然这通常是覆盖应用程序“base.html”（如果是的话）的问题，但我们的模板结构都略有不同，因此经常会出现不兼容性。例如，假设应用程序定义了 {% block footer %} 并在整个模板中将其用于各种用途。如果我已经使用 {% block footer %} 作为导航栏或版权信息，我不希望应用的模板覆盖我的块。
一个更简单的相关案例是对同一事物使用不同的块名称。例如，{% block extra-head %} 与 {% block extra-head %}。
解决此类情况的最佳方法是什么？理想情况下，最好重新映射块，这样您就可以执行诸如“将子级的 {% block footer %} 放入父级的 {% block content-footer %}”。有什么办法可以接近那个吗？或者是简单地覆盖每个冲突模板的唯一解决方案？
When incorporating a third-party django app, I typically want it to be integrated aesthetically with the rest of my django project. While this is typically a matter of overriding the apps 'base.html' (if that), we all structure our templates a little differently, so incompatibilities often arise. For instance, suppose an app defines {% block footer %} and and makes use of it for a variety of things throughout its templates. If I am already using {% block footer %} for, say, a nav bar or copyright info, I don't want the app's templates to override my block.
A simpler, related case would be using different block names for the same thing. For instance, {% block extra-head %} versus {% block extrahead %}.
What's the best way of resolving these sorts of situations? Ideally, it would be nice to remap blocks, so you could do things like "put the child's {% block footer %} in the parent's {% block content-footer %}". Is there any way to get close to that? Or is the only solution to simply override every conflicting template?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，html继承应该去：
我想这就是你的意思，但措辞有点含糊。您也许可以只编辑 app-base.html。
其次，覆盖诸如 {% block footer %} 之类的可重用应用程序几乎会故意给使用它的任何人带来麻烦 - 您应该在提供商的问题跟踪器中标记这一点。
如果应用程序确实对 {% block footer %} 执行了任何操作，则应在 app-base.html 区域中完成，因此在将其与您的网站集成时只需更改一次。
最后，递归查找替换实际上只需很少的努力。如果您不使用允许这样做的 IDE，Text-Crawler 是免费的，闪电快速且良好的非 IDE 解决方案。
已经进行了几次创建标准继承模式的尝试，我在 djangoslingshot.com 上整理了一个我喜欢的模板，并且我已经看到了另一个 - 但到目前为止，还没有围绕标准进行任何合并。可能是因为查找-替换实际上是一个非常低的成本，其好处是能够准确地做您想做的事情，而不会受到其他人的规则的阻碍。
First, the html inheritance should go:
I think this is what you meant, but the wording was a bit ambiguous. You might be able to just edit the app-base.html.
Second, a reusable app that overrides something like {% block footer %} is almost willfully causing trouble for anyone who uses it -- you should flag that in the provider's issue tracker.
If the app does do anything with {% block footer %} that should be done in the app-base.html area so you only have to change it once when integrating it with your site.
Finally, a recursive find-replace is actually very little effort. If you don't use an IDE that allows this, Text-Crawler is free, lightning fast, and a good non-IDE solution.
There have been a couple of attempts to create a standard inheritance pattern, I put together one that I like for the templates at djangoslingshot.com and I've seen one other -- but so far there hasn't been any coalescence around a standard. Likely because find-replace is actually a very low cost for the benefit of being able to do exactly what you want without someone else's rules getting in your way.