django-octopus icon indicating copy to clipboard operation
django-octopus copied to clipboard

I don't think anyone actually uses this, so unless there are objections I'm going to break backwards-compatibility instead of deprecating a feature

Open brmc opened this issue 8 years ago • 1 comments

The new change will remove fragment_name and fragment_suffix on the views in favor of base_template and ajax_template. This will eliminate the need for proxy templates and make things cleaner. For example currently, a view might look like this:

SomeView(OctopusDetailView):
    template_name = 'template.html'
    fragment_name = 'fragment.html'
    ...

With the following templates:

base.html

{% block content %}
{% endblock content %}

template.html:

{% extends 'base.html' %}
{% include 'fragment.html' %}

fragment.html

<h1>somethingsomething</h1>

Under the new implementation, the same functionality would be achieved like this:

SomeView(OctopusDetailView):
    template_name = 'template.html'
    base_template = 'base.html'
    ...

With the following templates:

base.html

{% block fragment %}
{% endblock fragment %}

template.html:

{% extends base_template %}

{% block fragment %}
    <h1>somethingsomething</h1>
{% endblock fragment %}

Note that base_template is a context variable in the second template.html, not a string

Any one have any thoughts?

brmc avatar Jan 21 '17 17:01 brmc

Had some trouble getting the test project working but it's running. It seems like you still have to specify two templates, but I think that's unavoidable. At least the fragment can use extends now, as long as the top level base extends base_template.

I was confused on how it worked, but figured it out: Regular request uses template_name, and sets base_template context var to base_template view attr Ajax request uses template_name, but sets base_template context var to ajax_template view attr (which defaults to 'ajax.html').

Did you look into writing a custom extends template tag?

Solanar avatar Feb 12 '17 07:02 Solanar