How to add multiple views in one template of django ?
Is it possible to add more than one view in template .
I have view A that deals with file uploads , and view B that deals with file permissions . How do I put them in one template ? Both are in different apps .
I don't think this is really the best way to go about things. Views are not really meant to be used that way. They should map to requests on a one to one basis.
You might, in fact, need to write a third view which does all the things that the two other views do. Situations like this are where the class based views become very handy. I would try to break out the code that handles all the forms and processing in to separate functions, and just import those when needed.
Another Solution is to do this via ajax somehow. Load those portions of the page separately either after load, or on submit.
You should use custom middleware for that kind of things, so there's no need for different views.
Related
I basically need to make a DB query on every view within an app, in order to pass some data to my templates. Since views are not classes, but simple functions, I can't have a construct, where I can do the query.
So, structurally speaking, what is the best practice on where to put this kind of logic? I probably could just create a template tag and do the queries there, but it seems like not very well organized to me.
Firstly, views certainly can be classes: Django has offered class based views since version 1.3.
However, the best way to pass data to every template is to use a context processor.
I have subclassed Django's generic views for my project. I use them extensively to create basic CRUD views on our front-end site. Some models have just a create view, some have a read and update, etc.
This works well but I still write a line of code for each URL. ie:
url(r'^referrer/create/$',ReferrerCreateView.as_view(), name='referrer_create'),
url(r'^referrer/$',ReferrerListView.as_view(), name='referrer_list'),
url(r'^referrer/(?P<pk>\d+)/update/$',ReferrerUpdateView.as_view(),
name='referrer_update'),
I then do this for every model and the views that model has. This doesn't seem to be a very DRY approach to me. Is there a good approach to automating these urls for any generic view that has been created for a model?
The solution is to create a method that will return a list of url() calls given a set of views. Something like
views = {
'base_name': 'referrer',
'create_view': ReferrerCreateView,
'list_view': ReferrerListView,
'update_view': ReferrerUpdateView,
}
def generate_urls(views):
return [
url(r'^%s/create/$' % views['base_name'], views['create_view'].as_view(), '%s_create' % views['base_name'],
# and so on
]
Then you just need to do
urlpatterns = patterns('', *generate_urls(views))
For every set of views you have.
That being said I believe you shouldn't do this. This solution (or any different implementations) is over complicated and will add an extra layer you'll need to go through if things go wrong.
There's nothing wrong of having some boilerplate code, especially configuration code, because it makes your life much easier to debug in the future.
I have the same very concern and I shared it here before
One answer was the use of django rest framework as it implements such url patterns on its own!?! I didn't experience this solution yet.
My workaround is to have a dedicated file for crud operations for every model.
By that solution I decreased the matching time , and grouped related model pattern in one file.
BUT I understand that wont fully solve your question
I am trying to make a calendar application. So I would need to make some classes to display the calendar and add events to it. Do those classes still go in my views file or do I have to make a separate directory and import it to my views file and make then make an instance of it?
Most people put view classes into the views.py file.
If it becomes unmanageable or you need further organization, split them as necessary.
You don't need to import it into views.py - they are ultimately only used by the urls.py which don't require views live in any particular place.
If you're talking about application logic, if it's a huge class that's not necessarily related to the web HTTP response cycle, then it makes sense to place it in another file.
I'm just starting with Backbone.js. I'm building a Single Page Application and trying to figure out how I can handle this situation.
Depending on the view I'm rendering, I need to output multiple templates, meaning I have a wrapper that I use for the main template, and other 2 templates that go on other parts of the HTML.
I started by manually outputing the templates, but that got me thinking how correct that approach was, as it would require me to manually delete them whenever I navigate to other view.
The question is, How can I effeciently render multiple templates in a single view (that are appended in different places) and still have control over the deletion on the entire view and undelegating its events?
I'd check out Addy Osmani's walkthrough for developing with backbone.js.
http://addyosmani.github.io/backbone-fundamentals/
It walks through the example todo app, and then one more complicated one. What I think you want specifically is to use a framework such as Marionette.js to orchestrate and automate some of the event delegation and removal when you play with your views. If this is the case, skip to http://addyosmani.github.io/backbone-fundamentals/#marionettejs-backbone.marionette and read on about how marionette will help organizing views into regions and layouts as #NathanInMac said.
You need a layout with a couple of regions.
Then put your sub-views in these regions.
Lets say I have a website with a small application that lists the 10 newest members, or something dynamic like that. I want this to view on every page, perhaps in a sidebar. How would i go about doing this.
My thoughts on the matter. I might not get the whole django thing just yet, but when I have a url like /foo/ calling a view bar - but what info do I have to send to the template from this view. Does every view have to send the info to the template (just so I can view my app) or is there someway to call this from the template instead.
I have tried to read through the documentation, but its seems I just can't understand this.
The usual way to provide '10 newest members' type of information from other apps is via a template tag. See this article by James Bennett on best practices (although note it's a bit out of date, as it was written before the inclusion_tag and simple_tag shortcuts were available).
Create a template tag that you can call on the page
Create a context processor and inject extra context variables onto each pageload
I'm sure there are other ways of doing this but those are probably the most logical two. The first gives you more power and will waste less processing time (for pages where you don't want to display the data) but a context processor is much more simple to write (you don't have to bend over backwards to please the template_tag gods).
Both are valuable things to know so there you go. Go and learn!
"Does every view have to send the info to the template (just so I can view my app)"
Yes.
"Is there someway to call this from the template instead."
No.
Your views are just functions. Functions can call other functions. That's ordinary good design. You can still do ordinary good design in Django.
You do have the ability to provide a "context". This is still done in the views to provide additional "context" for the templates. See http://docs.djangoproject.com/en/dev/ref/templates/api/#writing-your-own-context-processors for writing your own context processor.
Nothing (well almost nothing) is done in the template except render the objects provided by the view into HTML (or XML).
If you have a page that is an amalgamation of stuff from many small apps, then you have two tiers of apps.
Independent Apps.
Composite Apps that depend on Composite or Independent Apps.
Your composite app can call other app view functions to gather data.
Your composite app template can include other app template elements to present that data.
You have all the power of Python to decompose the independent apps into "data production" functions, view functions, template components and final page templates.
An independent app Page will use a view function and a template. The view function will use the data production functions. The template will use template components.
Decomposition still works, even in Django.