Building a django app with some mostly static pages at the front of the site e.g. about.html faq.html
that kind of thing
I was looking at how urls.py work and I created this.
('(.+\.html)$', direct_to_template),
It seems to do exactly what I needed. Now for any new .html page I add to the root of my templates folder it just works. templates/about.html templates/faq.hml
I can also use things like this in my templates
{% include "_menu.html" %}
Now someone has kindly pointed out Django FlatPages and suggested maybe I use them instead. If I'm not connecting to the db are there any disadvantages to the way I'm doing it.
Seems to me like its a better way to do it than FlatPages because it uses the db and isn't quite as elegant (haven't actually used flatpages in practice though)
If you're ok editing template files directly and manually adding new ones to your urls.py file, then stick with what you've got. Flatpages is useful if you want to be able to edit page content from the admin interface or any web-based editing tool you might care to design, or perhaps more to the point: if you want non-technical users to be able to edit the content.
I would suggest moving one step further. If your static content doesn't change frequently and doesn't make use of Django's templates then don't use Django to serve them. Use a light weight server such as Nginx instead.
If you do make use of Django's template features without requiring any dynamic content from the database then you can stick with direct_to_template.
One advantage to using FlatPages is that you can use the Django templates to for headers, sidebars, footers (to maintain a consistent site appearance) while still using mostly plain HTML for the page content. That is offset by the need to store the page content in a database table.
My advice? If what you're doing is meeting your needs, stick with what works.
Related
I've started working on a django project that has couple apps that are used entirely through templatetags through other apps. Voting app, comments app..etc
Although am faced with a challenge when it comes to rendering assets for that particular templatetag (css,js).
I already have a base.html with blocks for css and js but how would I be able to access them using templatetags to append related assets. Currently am heavily relying on inclusion templates and I did a lot of research and it seems impossible to touch blocks.
any advise? even if I would change the approach of using blocks am open to any suggestion
it seems perfectly reasonable to tell the users of your library (app) that they must include your css/js somewhere in their template. E.g. django crispy-forms does this. Just give them some sample code to include in their base template
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 have just learnt about Django apps. I want to know that within one site, if I make different apps. like, users, profiles, polls, blogs,comments, jobs , applications then how can I manage them to make them intereactive? And is it how the concept of app should be? I want to have things loosely coupled that's why asking? Rails work on the way of REST, so do Django support that also with the use of apps? May be my questions seems a bit ambiguous because I am new to django and some of my concepts are still messed up.
Please tell what ever you know.
The general idea is that apps should be as loosely coupled as possible. The goal is to have completely self-contained functionality. Now, of course, that's not always possible and many times it even makes sense to bring in functionality from another app. To do that, you simply import whatever you need. For example, if your "blogs" app needed to work with your Comment model in your "comments" app you'd simply add the following to the top of the python file you're working in:
from comments.models import Comment
You can then use Comment as if it were defined right in the same file.
As far as REST goes, Django's views are much more fluid. You can name your view whatever you like; you need only hook it up to the right urlpattern in urls.py. Django views can return any content type, you just prepare the response and tell it what mimetype to serve it as (the default is HTML).
I'm working on a Django site with a basic three column design. Left column navigation, center column content and right column URL specific content blocks.
My question is about the best method of controlling the URL specific content blocks in the right column.
I am thinking of something along the lines of the Flatpages app that will make the content available to the template context if the URL matches a pre-determined pattern (perhaps regex?).
Does anyone know if such an app already exists?
If not, I am looking for some advice about the best way to implement it. Particularly in relation to the matching of patterns to the current URL. Is there any good way to re-use parts of the Django URL dispatcher for this use?
Django CMS is a good suggestion, it depends on how deep you want to go. If this is just the beginning of different sorts of dynamic content you want then you should go that way for sure.
A simple one-off solution would be something like this:
You would just need to write a view and add some variables on the end of the URL that would define what showed up there. Depending on how fancy you need to get, you could just create a simple models, and just map the view to the model key
www.example.com/content/sidecontent/jokes/
so if "jokes" was your block of variable sidecontent (one of many in your sides model instances) the urls.py entry for that would be
(r'^content/sidecontent/(?P<side>)/$,sides.views.showsides),
and then in your sides app you have a view with a
def showsides(request, side):
Sides.objects.get(pk=side)
etc...
For something like this I personally would use Django CMS. It's like flatpages on steroids.
Django CMS has a concept of Pages, Templates, and Plugins. Each page has an associated template. Templates have placeholders where you can insert different plugins. Plugins are like mini-applications that can have dynamic model-based content.
Although Django-CMS is an interesting suggestion, there are quite a few projects that do specifically what you've requested - render blocks of content based on a URL. The main one that I know about is django-flatblocks.
I've got an existing Django site, with a largish variety of templates in use. We've agreed to offer a custom-skinned version of our site for use by one of our partners, who want the visual design to harmonize with their own website. This will be on a separate URL (which we can determine), using a subset of the functionality and data from our main site.
So my question is: what's the best way to add reskin functionality to my site, without duplicating a lot of code or templates?
As I see it, there are several components which need to work together:
URL: need to have a different set of URLs which points to the partner-branded version of the site, but which can contain all the standard path info the site needs to build pages.
Template 'extends': need to have the templates extend a different base, like {% extends 'partner.html' %} instead of {% extends 'base.html' %}
View logic: need to let the views know when this is the partner-branded version, so they can change the business logic appropriately
My idea so far is to put the partner site on a subdomain, then use a middleware to parse the domain name and add 'partner' and 'partner_template' variables to the request object. Thus, I can access request.partner inside my views, to handle business logic. Then, I have to edit all my templates to look like this:
{% extends request.partner_template|default:'base.html' %}
(According to this answer, 'extends' takes a variable just like any other template tag.)
Will this work properly? Is there a better way?
If you are using different settings.py for the different sites you can
specifiy different template loading directories. (Which may default to your unskinned pages.)
Personally I'm not convinced by having different business logic in the same view code, that smells like a hack to me - the same as extensive conditional compilation does in C.
So to sum up.
Use django.contrib.sites and different settings.py
Get a clear idea, how much this is a new app/website using the same data, or just different css/templates.