I am starting out in Django and haven't been able to find an answer to this question in tutorials or elsewhere. It seems like a simple feature, so I wonder if I am not understanding - so anyone that can explain it clearly would be greatly appreciated.
Say I have a site with 5 different pages via Django templates. If I write a small app that renders a poll (like the django tutorial), but I don't want that app to have its own url, just to feature, for example, in a sidebar of 2 of the 5 pages. The poll app has nothing to do with the other pages/apps.
My first thought was to go to those 2 pages' templates and include the template for the poll app - {% include "poll.html" %} ... I then found out this renders only the html as is, but I need to reference the database models to render a list of polls.
Inheritance doesn't quite make sense to me in this instance...
So, what would be the best practice way of doing this? For me, this is the whole idea of plug and play apps that Django is good for, but can't figure out how to just plug it in to other templates! I really just want to know the simple theory behind doing this, because it seems like a key feature.
Thanks!
Template tags - specifically, inclusion tags - are what you want.
Related
I'm currently writing django project and got confused when it came to separation into apps. Project consists of posts and categories which are kept in one app, also there is a 'main' app which handles user profile view, login, logout and registration. Now I'm trying to implement user-to-user messages and I'm wondering if it should be kept as separate app.
If Message model is kept in application 'messages' how do I realize show_messages view?
1) It seems that it should be stored in 'main' app since it's linked by my_profile view. It would just get all Message instances form 'messages' app and render template extending profile.html or including from 'messages' app a partial template responsible only for messages listing. But why would I then need separate application just to hold one model there with some helper functions?
2) Secondly I wonder about placing show_messages view in 'messages' app but then I would need to use template which extends template from other application which again seems to be violation of self-containment rule. Also all "accounts/" urls are currently kept in main.urls so I feel wrong about adding "accounts/profile/messages" rule to messages.url.
3) Finally I think about moving Message model with all helpers and templates to 'main' app since messages are designed to work with User models and views therefore forcing additional separation seems useless.
Thanks for reading my thoughts, I'll appreciate all clues and explanations.
When I first started working with Django, I found the answers on this SO question to be particularly helpful, regarding app/project layout: Projects vs Apps
Many of the answers are useful, but this one is particularly pithy:
Try to answer question: "What does my application do?". If you cannot answer in single sentence, then maybe you can split it to several apps with cleaner logic?
I've read this thought somewhere soon after I've stared to work with django and I find that I ask this question my self quite often and it helps me.
Your apps don't have to be reusable, they can depend on each other, but they should do one thing.
Interdependence of apps isn't always problematic. For example, in a lot of my projects I have a separate app that is used solely for creating dynamic menus. In order to work properly, I need to import the specific models of that site into that app -- so I couldn't just drop it into another site, unaltered, and expected it to work. Nonetheless, the other 90% of the code in that app is completely reusable, and it's easier for me to move the relevant code to a new project if its already spun out into a separate app -- even though that app only holds a templatetag and a template.
Ultimately, a django site would technically run just fine with ALL models/views/etc in one big, unwieldy app. But by breaking your project down into "this app performs this specific function" you're probably going make managing your code a lot easier for yourself.
Regarding the 'url' point in 2, there's no reason not to subspace URLs. You are already doing this in a django project already -- mostly likely your main urls.py has an include() to another app, such as your main.urls. There's no reason your main.urls can't also have an include() to your messages app.
I'm new to Django and I'm trying to wrap my head around how these apps are supposed to be organized. I have the following questions:
Are apps like divs that are generated separately?
Can we have apps within apps?
Can we have apps that when clicked on, change other apps with javascript?
Right now I just have one views.py file and it loads all of its content through different function calls.
So right now I'm faced with if I should break up my views.py into smaller apps.
Am I going about Django the correct way?
Are apps defined like the they are in picture below, or are apps supposed to act more like a page?
What if I want a header, breadcrumbs, and footer for all my pages? I'm super confused #.#
Apps have nothing whatsoever to do with divs. Django is not a CMS (although it can be used to create CMSs) and doesn't dictate the layout of your templates.
The usual way to handle different blocks on the page that need different logic to populate them is via custom template tags. James Bennett has a good writeup on this, although the syntax is rather out of date so refer to the first link for that.
I'm looking at porting a custom-written PHP CMS into Django. One of the features the CMS currently has is an image upload function. I write an article, tag it with information, then choose a photo for it. If the system has any photos which have been added to articles with tags in common with the new one, it will suggest the photo for that article too. If there are no matches then a new image can be added.
In case this doesn't make sense, let's say I tag an article as Bruce Springsteen, The Beatles and Led Zeppelin. Next time I add an article with the tag The Beatles, it should suggest I use the image added for the first article.
What would be the best Django-applicable way to implement this? I've looked at the Photologue app and have integrated it, and I know it has tagging support (the problem here is that I'm using django-taggit, whereas Photologue supports django-tagging). One approach could be simply building it myself -- when a user uploads an article, I run a hook after they save it to associate the tags with the image. I'm just not sure how to then autosuggest an image in the admin tools based on that info.
Any ideas/approaches greatly appreciated.
This is almost certainly something you're going to have to build yourself. Django has a moderate number of libraries out there (that you've clearly already found). Unlike other solutions, it doesn't have a lot of things that get you 100% to your desired solution (whereas something like Drupal might get you 100% of the way there).
What you will probably need to do (at a high level) is something like this:
Create an AJAX view that takes the current tags as an argument and does a query on the existing posts to see what tags match and returns images from those posts.
Use jQuery/javascript on your view to call your AJAX view on the page as tags are added
Use jQuery to update a <div> on your page and show all the images that your view returned
Here is a similar example that might help get you started.
You might look into django-ajax as a helper library for your requests, but it definitely isn't necessary.
The hook between the your image module and any other django module can be implemented using django's contenttypes framework which also provides some useful instance methods for returning related/hooked objects.
I have developed some code that builds on the contrib comments app, such as handlers for ajax requests. This code is in a separate application, which we can call 'comments2'. the url configuration of the project is structured in such a way that all calls to /comments are directed to this app's views. This works without problems.
Very recently I made a new page that shows comments flagged as inappropriate.
I conceived that it was best done by writing an inclusion templatetag, and wrote one. It works like this:
{% display_flagged_comments 'market' %}
This tag is placed inside the main app's relevant template.
As seen in the code above, I pass what model (Market in this case) the comments belongs to so that the comments2 app remains generic.
I have three issues here that I need guidance on:
First, I feel that the model argument being inside quotes ('market') make the code somewhat less elegant. In the code the argument is converted to a model:
#template tag
def show_comments(modelname):
model = ContentType.objects.get(model=modelname)
... # get comments and return them
Second, since all requests with /comments are directed to comment2 app, I need to devise a different url for this page (it sits inside the main app), such as /managecomments. I find doing that also inelegant.
Third, I want to know if I followed a correct path or is there a better way to implement what I'm trying to do.
Thanks in advance.
The ContentTypeManager has somewhat solved your first problem for you. You can use the method get_for_model, which accepts both a class or an instance. Read more at the contettypes docs.
I've written an entire app pretty successfully in Django but I have this nagging question that I think I know the answer to but I just want to make sure.
One of the things I really liked about Django was the data model and the ability to not have to do "obvious" stuff. For example, we use the admin interface extensively in our app. The fact that I don't need to write an edit screen for every model and keep it up to date every time the model changes is really nice.
What I'm puzzled by is that I wanted to have one part of the app render "read-only" versions of the models. Essentially I want exactly what I have in the Admin interface but without editable widgets. Now I notice, from the Django code, that that admin interface actually goes through and substitutes the widgets to use the editable ones so I know that non-editable is certainly there.
But as far I can tell, there is no way to just say "render this object" and have Django do the "obvious" thing and render it just like it does for the admin interface but with non-editable fields. I find this hard to believe since it seems like a) this is easier than the admin stuff and b) I know the widgets are already there. But I've looked all over and even the Django examples seem to always create a template and spell out exactly what the page should look like.
Writing a template is probably a good idea in general but early on in development when things are changing it would be better to have something that just does something basic given the information available in the model.
Am I missing something? Sorry if this is a stupid question.
Could be that most non-toy sites want a custom layout/html anyway?
Or, are you looking for Databrowse?
I used something like this: http://www.djangosnippets.org/snippets/937/
There are other similar things around if you google for 'django read-only admin' or similar.
Never underestimate how flexible the Django Admin is...