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
Related
I have a latest news block on a page. It's a piece of markup in a template and some logic fetching the last n news in a view.
How can I make a reusable component of it (like some CMS have) which I can include in a template like this:
{% component "latest_news" "5" %}
for building a block with 5 last news.
Seems Inclusion tags is quite good for this purpose, but I wonder may be is there some build-in component-like feature in Django?
The closest to CMS's components functionality in Django is Inclusion tags
In 2021, I have come across the following projects:
https://pypi.org/project/django-render-partial/
https://pypi.org/project/django-components/
I have used django-render-partial pretty extensively, and I like that the interface allows your partials to be used in templates, or hooked directly up to a urls.py.
django-components looks pretty cool, because it allows you to package CSS and JS files with the use of a Media class (similarly to Django forms), but it fractures the "everything is a view" pattern provided by django-render-partial.
I used django_components which saved me a lot of pain, it supports creating reusable components with dynamic components name, and it also allows passing HTML fragments to the components.
I want to move some parts of a main template into partials which shall not need django rendering (i.e. pure html/js) and use them in a ng-view in the main template.
However, the partials have Django formsets (using crispy) in them i.e useless without Django rendering.
Moreover, I do not want to write the complete formset HTML by hand.
How can I do this?
Maybe you have a less or sass file too. This file, like your form, it's unusable without preprocessing.
Review code from https://www.djangopackages.com/grids/g/asset-managers/ for inspiration and look at https://docs.djangoproject.com/en/dev/howto/static-files/ to learn how to do it.
Hard part is not do it because its easy make a static finder. Hard part is do it in development staging in a transparent way.
You can request your partials from the server and put them into the $templateCache yourself using the filename as a key.
This way, when a partial .hmtl file is request, it will get the django rendered HTML.
$http.get('myForm.html', {cache:$templateCache});
You'll want to eagerly load these partial templates, as if the partial template is not in the cache, then it'll request the static html.
Hope this helps
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.
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.
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.