I have a Django Wagtail application, which employs the templating machine Jinja (or Jinja2, not entirely sure, but won't make a difference for this issue).
When I e.g. want to use the templating to show the title of a blog post, I can write
{{ post.title }}
This works perfectly fine. But I cannot enforce hyphenation in this title. If the title holds a very long word, this crashes my layout on small devices. Anyone an idea how I can tell Jinja that hyphenation should be enabled?
Related
I am developing a website using Django Mezzanine.
I have some pages using a model derived from Mezzanine Page model with translatable fields (using i18n) and this works.
However I have some pages relative to some events in given countries, so they are only in one language, and they use a model derived from Mezzanine Displayable model, without translatable fields but a language attribute.
In the list I tried to put links including the language of the page (like /en/events/event/eventslug ).
I tried to add translation.activate(lang_code) to the view.
This way I get the page in the wanted language (I use {% trans %} template tags).
The problem comes when I visit the page from another language (for example if I am on the filter page in Spanish and go to an English event). Then the language switch (mezzanine form sending a POST request to /i18n/) doesn't work any more (I am locked in English)
The switch still work in private navigation for example as long as I don't visit one of this pages from another language.
How can I fix this?
I am out of ideas as of why...
Update: I changed the urlpattern so it is not i18n anymore (I think it makes more sense) but as I still need translation.activate(lang_code) for the {% trans %} tags my problem is still the same.
The problem came from the fact that if you use translation.activate(language) then you need to use translation.deactivate().
So that would have required the use of a middleware to make it work properly.
However I found the i18next module allowing to override the locale in the template, so I defined the context 'lang_code' in my view and used {% overridelocale lang_code %} in my template.
I’m planning to use the Django templating system in a slightly uncommon way. I need an app that will let me easily create simple “fill in the gap”-style forms and I decided to use Django templates with custom tags to design the forms.
Here is a sketch of what I mean:
<p>
This is the <i>form</i>. Two plus two is {% gap four 4 vier %}.<br>
The best programming language is {% case_gap Python Haskell %}.
</p>
{% if all_correct %}
You are smart.
{% else %}
<input type="submit">
{% endif %}
The idea is that the *gap tags render a text input control, look into the context to see if the answer for them was sent, and if the answer is correct, mark the text inputs green.
The question is how to implement the all_correct logic. The simple solution is to add this variable to the context and then make each *gap tag update it based on its correct answer, and, I believe, this should work with my example. But what if I want to move the {% if all_correct %} code to the top of the template, where none of the gaps were rendered, and thus none of them have validated their answers yet?
Looks like I need some way to iterate over all the *gap tags before starting to render the template and [ask them to] validate the answers, but I don’t know the internals of the templating system well enough to implement this. Or there might be a completely different and better way.
I believe I figured how to do this after reading Chapter 9 of The Django Book.
Creating of a custom template tag involves defining of two things: how to compile the tag and how to render it. The compile-function should parse the tag data and return a Node—basically a thing that has a .render(self, context) method and some other data derived from the tag text.
The solution is to create FormNode—a subclass of Node that will also have a .validate(self, context) method. Then our custom tag will be compiled to a subclass of FormNode that implements validation logic.
The next thing to do is to create FormTemplate—a subclass of Template with a super-power: before starting to render individual nodes it will validate all the nodes by iterating over them and calling validate(context) on all the subclasses of FormNode and it will set the all_valid variable in the context.
Here is my proof-of-concept implementation: https://github.com/kirelagin/django-template-forms. I believe it works pretty well.
I used the ability to instantiate a custom template engine, which was added in Django 1.8. Overall, I had to dig a little deeper than one might expect and I always had this feeling that splitting of the templating API and the django engine (which is now just one of the available backends) wasn’t complete yet. I hope that Django 2.0 will bring us new cool stuff and all the hacks I had to add will vanish.
I've been stuck for the past few hours trying to figure out why the core Polymer elements are not being displayed properly in a Django application I'm making to act as a personal webpage. The application at the moment just points to an index.html page which, if you follow the tutorial on Polymer, is up to step one.
However, the components are not loading on my page. The static files are all set up correctly, and there's subtle animation from the css files being loaded correctly, but the Roboto font and the core-elements are not being displayed. Running the site as a normal HTML file does everything correctly.
Is there a specific way to user Polymer in a Django template?
Thanks.
See Eric's answer to this on the polymer-dev mailing list: https://groups.google.com/forum/?fromgroups=#!searchin/polymer-dev/django/polymer-dev/N2R8qknalOI/58ZhC1gWFh4J
Relevant excerpt:
Django 1.5 has support for the verbatim tag. You can wrap your inlined element definitions in that:
https://docs.djangoproject.com/en/1.5/ref/templates/builtins/#verbatim
Example code snippet:
{% verbatim %}
<template repeat="{{item as items}}">
<my-element name="{{item.name}}"></my-element>
</template>
{% endverbatim %}
<script>
document.querySelector("template').model = {{items}}; // items here is filled by the server's template.
</script>
I'm pretty sure this has to do with the fact that Django uses the same {{}} in its templates as Polymer.
I'm adding this answer as a compliment to the already accepted answer.
You can force django to require a space for it's template tags. So for any django template tags you have to use {{ variable }} and for polymer you will use {{variable}}.
Here is a very simple module/app I created to "prepare" django for use alongside polymer.
https://github.com/andrewebdev/django-ostinato/blob/2c435dea23319be6e9011e7381afca2b4092b5a2/ostinato/polyprep/init.py
Credit goes to https://github.com/nebrybledu for this suggestion.
As you can read on the django reference or hacking a bit, get_flatpages can be used as follow:
{% get_flatpages as flatpages %}
{% get_flatpages for someuser as flatpages %}
{% get_flatpages '/about/' as about_pages %}
{% get_flatpages prefix as about_pages %}
{% get_flatpages '/about/' for someuser as about_pages %}
So, if I want to get a specific page I need to do it via its url or a prefix, which is somewhat rough, because my template code become data dependant, I meant, if I change the url of certain flat page then it is necessary to change my template code too.
A more flexible idea would be including an identifier to each page, addable through e.g. the 'Advanced options' section, so that the page can be refered via its identifier, thus we could do something like this:
{% get_flatpages 'about' as about_pages %}
Which is more flexible and less data dependant, no matter what url the page has, note we could change the page's url without changing the template code.
Is there something like that in the framework?, of course I could customize this app or to use a third-party app, but this isn't the point ;-)
Have you any other idea to deal with?
No, I don't believe there's any support for what you're asking for in Django at present. The docs you linked to for flatpages say:
A flatpage is a simple object with a URL, title and content. Use it for one-off, special-case pages, such as “About” or “Privacy Policy” pages, that you want to store in a database but for which you don’t want to develop a custom Django application.
My reading of this is "this is the bare minimum we're providing, and if you want any more you'll have to code it yourself". I agree that your proposal of allowing pages to be referred to by a symbolic name (which perhaps defaults to their URL) is more flexible, but you're probably better off raising an issue for it or discussing on the mailing list than hoping a dev happens upon your question on StackOverflow.
In the short term, you could look at some of the pre-built CMS-like Django apps. Django-page-cms is relatively lightweight (it's a relatively small app itself but does have a bunch of dependencies) and you could accomplish what you're after: each page is referred to by its slug (aka url / name), but you can define aliases / redirects to given pages for arbitrary URLs.
I have a simple (I hope so) question about the structure of a typical Django website. I have to restructure my site using some "Django-powered" pages mixed to other typical static pages.
I'd like to have a few templates and a lot of pages using these templates.
My question is:
What is the best way to provide different content for each page?
What I'm thinking right now is having different pages in my URL conf using the same templates and modifying the content within the View. But it's so unnatural to "hard-code" my content within the View, I suppose.
Is there a way to define content areas in my template and, for example, edit them within the Admin panel?
There must be better ways, I think.
Thank you!
Edit
Maybe Flatpages could help in my task. But does exist a way to add "content areas" tied to specific parts of the templates? I can fine only the main content area.
How are your "content areas" different than django's template blocks? You can define something like this in your layout file:
base.html
{% block overridable %}Default content{% endblock overridable %}
And in your templates, you extend it like this:
view.html
{% extends "base.html" %}
{% block overridable %} Overrided by view {% endblock overridable %}
You can use generic views, and I would heartily encourage you to. They're great. Check out the django docs for generic views. But as for different pages requiring a different template, yeah, that's how websites work.
Django is not "file-light" - it works by combining lots of small files. You're quite right to be averse to hard-coding HTML in your view controller - that's generally bad practice. You're going to have a template for each view, but really, how many views do you have? Even in a large application, the number of views that can't be handled by either a built-in or custom-made generic view is going to be pretty low.