2👍
A general good practice to define views with a template_name
kwarg. This allows a the default template to be overridden. This is common in generic views.
#my reusable view
def list_items(request, template_name="items.html"):
items=Item.objects.all()
return render_to_response(template_name,
{'items': items},
context_instance=RequestContext(request))
#some other view
from my.reusable.views import list_items
def list_special(request, template_name="spectial_items.html"):
return list_items(request, template_name=template_name)
0👍
Your question is little too generic.
The general way of doing it involves:
- Extend templates of the reusable apps
- Pass the new template name to the view (Reusable apps should accepts that argument)
- Also pass
extra_context
to the reusable-generic-view - Use your own view to create an
extra_context
and return the reuse-able view, from your view.
- [Answered ]-How to display a ForeignKey as RadioSelect options from DetailView in Django?
- [Answered ]-Django rest framework does not show utf8 words
0👍
usually each application should provide views for the basic functionality – where the application takes full control over the user and the page.
functionality which can be displayed in the basic page layout (e.g. ‘last 5 posts in my blog’) would be a perfect use case for template tags – i usually use simple inclusion tags. so you wouldn’t combine multiple views into one template, but always have one view which handles the request, and everything around can be aggregated using template tags.
- [Answered ]-Limiting the number of displayed instances of a model in Django Admin
- [Answered ]-Restrict foreign key values according to request.user in django
- [Answered ]-Django URL explanation
- [Answered ]-Why does django.utils.importlib.import_module not import the correct app? And how does the variable change?
Source:stackexchange.com