Is there a difference in how django treats a 'loaded' page/template if i use the django-template specific include-tag, or jQuerys load-function?
If you use Django's {% include %} tag, the template is constructed by the server and displayed in the browser after the construction is complete. On the other side, if you use jQuery.load(), the requested template is included on the client-side using an AJAX request after the base template has finished loading.
In both cases, the displayed result in the browser should be the same. The advantage of jQuery's method is that you can load the template later on, for example when you click a button on the page, without the need to reload the entire page in the browser. So you can handle user interaction in a more interactive way. An advantage of server-side method is that the entire DOM and content resides in the HTML file and can therefore be indexed by search engines if that should matter to you. HTML included by client-side JavaScript is not visible for search engines.
Generally speaking, if you just want to include HTML once a requested webpage gets loaded, use the server-side method using the include tag. It's more user-friendly and efficient to let the server do the template handling, especially if the templates are very large.
The ssi or include tags are included on server side (in this case by django). jQuery includes client based.
Related
Is Zurb Foundation's Interchange compatible for use with Django templates? I can't see a way to get them to work together, though the issue is just a technical one - Interchange seems to want html file paths, while Django's html templates render inline.
I suppose it would be possible to render the necessary templates each request into temporary files and hand those to Interchange, but that's not a very clean solution and would require a lot of boilerplate. I'm looking for a cleaner solution or for an alternative within Foundation and Django.
No, Foundation's interchange is javascript that runs in the browser within the HTML file produced by Django on your back-end. It's meant to be used for loading static files, mostly media, dependent on the size class of your browser view. E.g. inside and <img> tag:
<img data-interchange="[{% static 'images/my_background_small.png' %}, small], [{% static 'images/my_background.png' %}, medium]>
If you want to serve different HTML to different types of end-devices, you have to add that logic to your Django app's view, so that it uses a different template depending on the client. In general there are a few approaches:
What people do nowadays: Write responsive templates so that the same
HTML is served for mobile and desktop. For the few minor
differences, you can hide/show divs depending on the media class.
Check the device in your middleware and pass it as parameter to your views and templates so you can make decisions on it. Check django-mobile for example
Check the device in your server (apache or nginx) and add an HTTP header to your request that you can parse in your view (e.g. request.META.get('HTTP_MOBILE_SITE','no'). Example here
I have a page which is for album/picture management with 2 sections: Albums and Pictures.
When an album is selected the pictures block needs to change via AJAX to reflect the album selected.
This means the rendered pictures block needs to be provided to the Albums page as well as be available as it's own View for the AJAX source.
I understand I could solve this by making the pictures block always render from AJAX even when the album page loads, however I would like to deliver the default album pictures within the initial page load if possible. In order to do that, I'd like to render the pictures block via the same template in the Album page view as is used for the Picture AJAX View.
I'm only familiar with providing templates as a template_name property within an TemplateView object.
I guess I could simply call an instance of PictureView using inclusion_tag, and pull the data I need out of the render_to_response (I haven't tried this yet, I'm just theorizing) however that seems a bit dirty to me. I'm wondering if there's a more elegant solution to this problem?
Thanks!
jQuery, Django templates, JS templating and backbone.js should tie this together.
I would suggest having a dedicated template for the Pages block. Include this template in the Django template for your page.
For dynamic updates use a JS templating library such as included in underscore.js or moustache.js. You can change the template demlimiters used so that they are the same as djangos.
Include the raw Pages block template into a javascript template block - use the django ssi tag.
Use django-tastypie to set up an api that returns the data for Photos as JSON. Your template library can then use data to fill in the template in the JS template block and you can then replace the Photo block with this rendered HTML. Use of backbone.js should ease the tying of DOM elements and JS events.
If I understand your question correctly, I did something similar once with the subsection having its own template file, which only describes that one section of the page. I used the include tag to include it into the page template, so it loaded when the page did and then rendered that template with updated values and replaced it on the page with AJAX when the content was meant to change.
Is that an option for you?
I have a few child templates which have extraheads which include the jquery script. Sometimes they are used together. How can I have the jquery javascript file loaded only once? If it were convenient to set template variables, I could set and check one before including the line.
My advice: Just include jQuery on your base's <head> and call it a day. Saves you from having to worry if a child template uses jQuery or not and it is just a 19kb download on the first page load and that's it. If you use Google's API cloud, it may not even be any as the user might have it cached from another site.
This may not work for you, but I advice you to consider it if possible.
My usual approach to this problem is to either wrap all of my child templates in one template that takes care of my includes (JS and CSS). I then make sure my caching is set properly, so that these scripts are only downloaded once per user. In other words, I force the download of all my external scripts on the first view, then rely on caching to not redownload the JS each time.
Combining all of your JS into one file will also improve download time due to the reduction in requests that will be generated.
Another thing to note is that you mentioned putting the JS in heads. While most people do this, placing JS in the head can make your pages appear to load slower. JS files are not downloaded in parallel, so they block all other downloads. Google and Yahoo recommend placing JS at the bottom of your page where possible to improve the user experience.
See the Yahoo YSlow tool and the Google PageSpeed tool for this.
I'd mostly bite the bullet and load jQuery with every template. But if you really really really have to have this feature, then I'd recommend a custom template tag. Check out the docs, especially the part about setting a variable in the context.
You could define separate blocks for your script and for other extraheads in base template.
In base template leave block for your script blank. Fill it with link to a file when needed in templates which are extending base.
You could pass all required files as a context variable and then write a template tag that removed duplicates and loaded what was left.
You could control load order this way also.
Lets say we want a library of javascript-based pieces of functionality (I'm thinking jquery):
For example:
an ajax dialog
a date picker
a form validator
a sliding menu bar
an accordian thingy
There are four pieces of code for each: some Python, CSS, JS, & HTML.
What is the best way to arrange all these pieces so that:
each javascript 'module' can be neatly reused by different views
the four bits of code that make up the completed function stay together
the css/js/html parts appear in their correct places in the response
common dependencies between modules are not repeated (eg: a javascript file in common)
x--------------
It would be nice if, or is there some way to ensure that, when called from a templatetag, the templates respected the {% block %} directives. Thus one could create a single template with a block each for CSS, HTML, and JS, in a single file. Invoke that via a templatetag which is called from the template of whichever view wants it. That make any sense. Can that be done some way already? My templatetag templates seem to ignore the {% block %} directives.
x--------------
There's some very relevant gasbagging about putting such media in forms here http://docs.djangoproject.com/en/dev/topics/forms/media/ which probably apply to the form validator and date picker examples.
Been a while since I posted this problem. What I've been doing to solve it is:
write the javascript parts you need as a library which is served statically
call the routines in the static library from the template with your server side values
Restraint is required to write it in such a way that it acts as a client side script only; don't be tempted to try and inject values from the server at the time of serving the js. Ultimately I've found it less confusing to apply server side variables strictly in the html template.
In this way I'm able to:
keep the javascript selectors on html tags inside the same file (ie: the template)
avoid templatetags altogether
re-use each javascript library in different places, and
keep the css/js/html pieces in all the places where they're expected to be found
It's not perfect, but it's getting me by till a neater idea comes along.
For example a js library in "media/js/alertlib.js" might include:
function click_alert(selector, msg){
$(selector).click(function(){ alert(msg) })
}
and the template has:
<script type="text/javascript" src="media/js/alertlib.js"></script>
<script type="text/javascript">
click_alert('#clickme', {% message %})
</script>
<div id='clickme'>Click Me</div>
If more than one page uses a given JS file you should consider concatenating all of them together and minifying the result. This reduces net connects which will improve overall page load time. Don't forget to bump your expire time out to at least a week or two.
Have a look at Django Sekizai that has been created for just that purpose.
I think you are going to have a hard time keeping all four pieces together and applying them in a fell swoop - simply because some appear in your <head> tags and others in the <body> tags.
What have done is made sure that jQuery is loaded for all pages on my base.html (as well as my base css file) ... then, I have block tags for {% block css %} and {% block js %}. Templates that inherit the base.html file can supply their own javascript and css (and only the stuff that is needed).
I have created some template tags that create ajax functions whose output is based on the object being displayed (for example, including the object_id) -- which cuts down on re-coding.
One thing I haven't tried but am interested in is django-compress.
I want to include things like twitter status, or delicious tags, in my django templates.
These things are dynamic, yet regular. How would this be done?
There are a number of ways to handle this, so you can choose a method that best matches your own personal style or requirements:
Template context variable: as answered by Alex you can put your content into a context variable that is included in the context of every template created by every view. Django even provides a mechanism for doing this automatically, called a context processor. Pros: very straightforward. Cons: won't dynamically refresh new content on client browsers.
AJAX dynamic loading: as mentioned by Alex and Dave you can dynamically load your content using AJAX methods. As an example using jQuery, you would put a placeholder in your template something like <div id="twitterfeed"></div> and then in a javascript block in your template put $("#twitterfeed").load("{% url twitterfeed %}"); where twitterfeed is a url so named in your urls.py. Pros: will dynamically update browsers. Cons: can be tricky if you don't know Javascript.
Inclusion tag: Django provides a type of template tag called an inclusion tag, which is basically a custom template tag that can render dynamic content. In a way it's similar to a context variable, except your code to generate the content will only be called when you use the custom template tag in your template instead of being called for every view. Another benefit is the content is generated from a template of its own. You could do this with a normal context variable of course, but it's not as clean (IMHO) as using an inclusion tag. Pros: very straightforward, clean. Cons: won't dynamically refresh new content on client browsers.
The simplest approach is to use {{ mycontent }} in your template (where you want the dynamically generated content to appear) and put the correspondence between mycontent and its value in the context you use to render the template -- i.e., the most fundamental part of django's templating.
If what you mean is that you want Ajax support whereby Javascript on the page continuously refreshes such content according to what the server wants it to be at any given time, I suggest looking into dojango, the Dojo/Django integration project -- it's not yet as fully mature as each of Dojo and Django are on their own (not version 0.4 yet), but it is already usable and useful.
A common technique is to leave a placeholder div in the generated content, then fill the div in on the client side via an AJAX call from Javascript that you include in the page.
That gives you the benefit of having a cacheable (fast loading) primary page, with separate dynamic bits. Depending on how live you want the dynamic bits, you can can even cache them for shorter durations.