【问题标题】:Links disappear when changing to a different template更改为其他模板时链接消失
【发布时间】:2015-08-02 21:56:41
【问题描述】:

我正在尝试在 Django 中创建一个博客网站。我几乎是一个初学者,所以这个问题可能很愚蠢,但我不知道如何解决这个问题。

我的标题中有一个主导航。在 base.html 模板中,我在几个页面的菜单中创建了链接。在同一个模板中,我在侧边栏中有一个类别列表,这些类别是列出该类别中所有帖子的链接。

当我转到任何其他模板时(当我单击任何这些链接时),即使我扩展了 base.html 模板,链接也会消失。无论模板如何,我如何才能将它们保持在适当的位置?这种事情的常见做法是什么?

感谢阅读! 干杯!

编辑:代码:

<nav>
    <ul>
        <li><a href="{% url 'index' %}">HOME</a></li>
    {% for link in links %}
        <li><a href="{% url 'page' link.slug %}">{{ link.title }} </a></li>
    {% endfor %}
    </ul>
</nav>

这是在 base.html 中,但那些链接(除了硬编码的 Home 链接)在其他模板中消失了,这只是改变了内容块。

编辑 2: 这是基地的视图:

def index(request):
    posts = Post.objects.all()
    links = Page.objects.filter(menu='Y')
    categories = Category.objects.all()
    return render(request, 'main/base.html', {'posts': posts,
                                              'links': links,
                                              'categories': categories,
                                              })

解决方案: 感谢大家的帮助。这是我使用的解决方案:

from django.template import RequestContext

def base_links(request):
    header_links = Page.objects.filter(menu='Y')
    sidebar_categories = Category.objects.all()
    return  {
        'links': header_links,
        'categories': sidebar_categories,
    }

然后我添加了:

context_instance = RequestContext(request, processors=[base_links])

我的所有观点。

【问题讨论】:

  • 能否请您发布您的模板?您是否在其他模板中包含了{% extends 'myapp/base.html' %}
  • 我已经发布了链接代码。所有其他模板都扩展了 base.html 模板。
  • links 是如何传递给上下文的?
  • 我已经在帖子中添加了代码。
  • 如果您阅读有关上下文处理器的文档,您会发现您不必在视图中添加任何内容(除了确保它们使用RequestContext) - 只需将您的自定义上下文处理器添加到你的settings.CONTEXT_PROCESSORS

标签: python django templates


【解决方案1】:

在 django 中,每个“页面”都是一个视图。你的 index() 函数是你主页的视图,我敢打赌你有一个 blog_post() 或类似的东西来呈现帖子

每个视图都必须定义要使用的模板并传递渲染其模板所需的上下文(变量)。您的基本模板有一个需要links 变量的菜单,因此每个 呈现扩展基本模板的模板的视图必须links 变量传递给上下文。

简单来说 :) 您需要将 links 变量传递给您帖子视图中的上下文

小建议:不要将函数用作视图。最好使用Class Based Views

希望对你有帮助

【讨论】:

  • @pleasdontbelong:就我而言,基于类的视图是 99.99% 的用例的主要 PITA。我不明白添加无用的意外复杂性如何比 KISS“更好”。
  • “您需要将链接变量传递给您帖子视图中的上下文”:所以您建议 OP 在每个视图中复制此代码?顺便 fork 第三方应用视图?
  • @brunodesthuilliers 没有。我每天都使用 CBV,我考虑使用真正的 PITA 函数。即使在这种情况下使用 CBV,他也可以创建一个 mixin,自动在上下文中为所有实现 mixin 的视图添加 links,(但这不是辩论的地方:P)
  • “我每天都使用 CBV,我认为使用真正的 PITA 函数” => 这正是我的观点:这是一个主观意见,不是技术事实,也不是广泛认可的最佳实践.
  • wrt/ 为每个视图添加一个 mixin,这不是我认为的干净、良好解耦、可维护的解决方案。首先,它迫使您使用 CBV,然后您必须将该 mixin 传播到每个视图,包括第三方应用程序视图,以获得与这些视图所负责的完全正交的功能.使“站点全局”的东西对所有模板全局可用,而不会使您的视图因完全不相关的问题而混乱,这就是上下文处理器和模板标签的用途。
【解决方案2】:

您的模板会传递当前视图的上下文,因此您不能期望index() 视图的上下文会神奇地随处可用。

使此类数据在其他模板中可用的两种常见解决方案是

  1. 上下文处理器:

https://docs.djangoproject.com/en/1.8/ref/templates/api/#subclassing-context-requestcontext https://docs.djangoproject.com/en/1.8/ref/templates/api/#writing-your-own-context-processors

这是一个非常简单的解决方案,但也有一些缺点: - 即使对于不需要它的模板也会调用上下文处理器 - 很难知道上下文中真正可用的内容以及它的来源 - 您最终可能会遇到两个冲突的处理器,试图在上下文中设置相同的键 - 你最终可能会在处理器和视图之间发生冲突(每个都试图在上下文中设置相同的键)。

  1. 自定义模板标签:

https://docs.djangoproject.com/en/1.8/howto/custom-template-tags/

在您的情况下,如果您计划在网站的每个页面上以相同的方式呈现相同的数据,inclusion_tag() 是显而易见的选择。

就我而言,我发现自定义标签比上下文处理器更易于维护,并且使用inclusion_tag() 快捷方式它们与上下文处理器一样易于设置。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2016-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-11-21
    • 1970-01-01
    • 1970-01-01
    • 2011-10-06
    相关资源
    最近更新 更多