Develop Reference

Best Django practise - when to use views and when to use tags

I'm in the process of delving into Django into a little more depth - and I now have certain blocks around my website which are recycled, but not necessarily suited to a being placed in base.html and then sprinkled with {% extends /root/to/base.html %}.
So, I have a bespoke widget I have created which is utilised on certain pages but in different configurations, is it best to register and inclusion tag and reference the template you want to accompany those stored variables and arrays/lists/dictionaries etc..
For me it seems easier to define tags and then dot these around where I need them and just make edits to the template that is registered with that tag method? But is this the accepted Django standard?

In Django
a "view" is a callable that is responsible for handling a request and returning a response,
a template tag is a piece of code that will be executed in the context of rendering a template and will either push something in the template's context or render some text or markup.
Oranges and apples, really, and it should be quite clear when you want a view and when you want a template tag.
And yes, using inclusion tags (or a full-blown custom tag using a template to render some data) is "an accepted Django standard" - actually that's exactly what template tags are for.

Implementing Universal Search in a Django Application

We have a large Django application made up of a large number of different views (some of which contain forms). As with most large applications, we use a base layout template that contains the common layout elements across the applications (mainly a header and a footer), which the templates for all of our views extend.
What we are looking to do is create a universal search box in our application, accessible on every page, which allows users to perform searches across the entire application, and want to place the search box inside the header, which involves placing a form inside our base layout template. This means that every view in our application will need to be able to handle the submission of this search form. Once this search form is submitted, we will need to redirect the user to another view containing the search results.
However, we are struggling to come up with a pattern to handle this. Does anyone know of functionality built into Django that will help us to build this? Failing that, can anyone suggest a good strategy for modifying our application so that we can handle this use-case without having to modify a large number of existing views (which we don't have the resources to do at the moment)?
Please note that the focus of this question is intended to be the best way to handle the submission of a form which appears in every view, and not strategies for implementing a universal search algorithm (which we have already figured out).
Ideas Explored So Far
Our first idea was to create a base View class that implements handling the universal search form submission, and have each of our views extend this. However, this is not possible because we already have views that inherit from a number of different Django view classes (TemplateView, ListView, FormView and DeleteView being some examples), and to be able to build our own common view class would mean either writing our own version of these Django view classes to inherit from our own view base class, or re-writing a large number of our views so they don't use the Django view classes.
Our next idea was to implement a mixin that would handle the universal search form submission, in an attempt to add this functionality to all our views in a way that allows us to continue using the different Django view classes. However, this brought to light two new problems: (a) how could we do this without modifying each of our views to become a form view, and (b) how can we do this in a way that allows the form handling logic to play nicely when mixed in to existing FormViews?

This seems like such an obvious question that maybe I'm overlooking something. But as others have said your universal search form should not make a POST request to the view that rendered the current page.
Each html form has an action attribute. The attribute of your search form should point towards an URL. Probably something like /search. That url would have a view behind it that handled the POST request from the form and returned the search results. Django has URL template tags to make this easy. {% url 'myapp.views.search' %} will give you the correct url for the search view function if it lived inside the views module in myapp. So the relevant bit of html in your base template would be something like:
<form action="{% url 'myapp.views.search' %}">
<input type="text" name="qs" placeholder="Search">
</form>
If you are planning on displaying the search results on a new page there is absolutely no need to return JSON or anything like that. Just have a search view that looks like this
def search(request):
query = request.POST.get('qs', '')
results = SomeModel.objects.filter(name=query) # Your search algo goes here
return render(request, 'search_results.html', dict(results=results))

Instead of handling the form submission on every view of the application, you can implement a separate view (endpoint), which handles all the search queries. (an endpoint which returns JSON result) since you dont want to add overhead of rendering the whole page with that view. So the search query (which client side AJAX performs to the webserver) will return JSON response, and the Javascript can render that response. This way you can keep the search view isolated from the rest of the views. (Django REST will be helpful in this case)
And this search form will be included in your base template, so your search box is accessible from the entire application, and it submits to the same view. And the AJAX function will handle the server response for rendering it.

It seems like you just need to create another SearchView which takes the query and displays the results. I am not sure if the results have to be displayed differently depending on which page the search has been performed from but it does not seem like.
The form would not have anything to do with the other views. You could just hard code it in the base template.

Generic list view + site-wide data in django?

I have a view that perfectly fits the ListView in Django. Like this:
url(r'^$',
ListView.as_view(
queryset=Poll.objects.order_by('-pub_date')[:5],
context_object_name='latest_poll_list',
template_name='polls/views/index.html')),
However I on the page of the view I also would like to display content from another model. This model contains only one row of data. It's sitewide and contains the footer-text page-title etc.
What's the best solution for this? Ideally I'd like to keep the generic-model approach.

There are several methods that will solve this issue. The view is definitely not the correct place.
Template Tags
One way to use template tags is as mini-views. Whether you are requesting data from another model, or rendering an included template.
Because you can also pass parameters into the template tag, they can be customized by the context.
Context Processors
For simpler information,context processors work well. I wouldn't get too complicated with the data, as it is global and can slow down every request.
On an aside, I would also question your one-row model. My guess is that this is to allow user editing. If users access it, expect every possible way of screwing it up. For example, adding more rows. There are several Django applications for managing user-editable settings that might be useful. If the data isn't going to change often, I would make it an actual setting, or put it in a template snippet and {% include %} it.

Building a generic block-based CMS with Django

A designer recently handed me designs for a site I'm building for a client. They're great designs but I'm really scratching my head as to how I'm going to implement it on the site.
The content can very easily be broken down into blocks or chunks of data where I could allocate a textarea for text input, a couple of charfields for link-buttons, etc and sequentially render them out to the page.
The problem (eg why I'm not just pulling in Django-CMS et al) is the blocks are quite unique from each other. There are perhaps 20 different models that I would build for each block type. Rather than hack around a pre-fab CMS, I'd like to build a Page model and then just have an M2M that links to an ordered list of subclasses of my abstract Block class. I hope I'm not losing you.
I don't understand how I can do this. These questions spring to mind:
Is there a simple CMS that does all of this already? Am I wasting my time trying to figure out the physics?
My Blocks subclasses will technically be different type. Do I need generics for a M2M-through class to link to them? Is so, how do I do that?
How do I render x different forms in an inline admin context? (I'd like to have the page form with a list of the Blocks underneath)
How can the user specify the type of Block in the inline control?
Edit: Or, alternatively, what about a templatetag-based CMS?
I'm thinking of something like plonking this in my template:
{% editable 'unique_id' 'content-type' %}
A further example:
{% editable 'home-intro' 'text' %}
Then I could just stick these around the templates I want to be editable, in the way I want them to be editable and when logged in the client would see "Edit text", "Edit link", "Edit image" links which simply popped up the right field.
This would make things more locked down but the layout needs to remain solid (and the client knows nothing about HTML/CSS) so it's one or other of these methods IMO.

Couldn't you implement your 'Blocks' as Django CMS Plugins? Then each page is just constructed from a number of plugins.
Each plugin has an admin form which gets the specifics for itself, and then the page template renders the plugin as you want it.
If you look at the first page of the django-cms demo:
https://www.django-cms.org/en/tour-demo/
you'll see in (1) a highlighted plugin block - in this case a formatted text block that is edited with TinyMCE or similar. You can define your own plugins and add them to pages.

last month I published an article (for review) on how tho build a basic CMS for Jinja. This's templating language does not dffer very much from Django, which I have been using before.
You can find it here. It uses template inheritance to fill the content blocks.
https://codereview.stackexchange.com/questions/5965/review-request-jinja-cms-for-energiekantoor-nl-on-google-app-engine
Or type in Google : Jinja CMS

Django boilerplate template code

I am a django newbie and in creating my first project I have come to realize that a lot of my boilerplate code (the lists on the side of my page). I have to recreate them in every view and I am trying to stick with DRY but I find myself rewriting the code every time. Is there a way to inherit from my base views and just modify a few objects?
Thanks,
James

Yes, you'll want to look into template inheritance, which lets you share common elements between templates, and the {% include %} template tag, which lets you create reusable template "snippets" that can be included in other templates.
Edit: Re-reading the question, it sounds like you're talking about boilerplate code that you have in your view functions/methods that you're using to generate context shared by multiple templates. In that case, mipadi's answer is the right one: Look into context processors.

You might want to use a context processor for this work.

For the lists of recent articles etc, custom template tags are the thing you need. Whereas a context processor will populate your context with the lists automatically, a template tag can actually do that plus create the whole HTML markup for the column itself.

For large blocks of static html that reappear consistently you can use the include template tag:
{% include 'static/some_file.html' %}
The includes are stored in your template file system, just like templates.

If you don't decide to use context processor for some reasons (this solution looks reasonable here) you can always encapsulate some common logic into util functions and use them in your views.
You can also take a look at Generic views - this is a good way to 'stay DRY' with your code