I am trying to integrate zinnia into a django application. I have to adept the zinnia templates into my theme. Now I am stuck, because it seems that zinnia is using the same template to build the blog entry list, and the blog entry detail page.
This is problematic because, the list has significant different html and css as the entry single view. How do I split the templates, so that I have one that is entirely for the list and one for the entry's detail (Single Post) ?
To the best of my knowledge this isn't easily done. Here is a comment on a bug asking about this very issue:
Template Documentation #383
For me I am going to modify zinnia/_entry_detail_base.html and put my list view template code in an {% if continue_reading %} and the detail template in the else branch.
I'm currently in the process of integrating the Zinnia engine into custom templates -- I'm working on a dynamically updating homepage that shows recent entries from multiple categories, custom pages for each of those categories, and then custom templates for the entries' detail views. I've found this question's answer and this explanation to be extremely helpful.
*Keep in mind that the second link is a bit dated, and that {% load zinnia_tags %} is now {% load zinnia %}.
It's still a lot of trial and error to get things adapted properly to a custom template, but Zinnia really is amazingly customizable, and I think its default configuration tends to overshadow the fact that it works brilliantly as an underlying engine that can power just about any framework that you can sketch out on a notepad.
As the documentation notes, it's also helpful to take a look at some custom themes built for Zinnia on GitHub, just to get a feel of how the template tags are implemented, and how the default templates can be overridden. Here's the repo for a Bootstrap theme, and here's one for a Foundation theme.
Related
I need to replace same plugin template on different subpages - e.g. on frontpage I need specific slider template for latest articles, in detail article I need small list, on search result without images etc.
[note: everything about aldryn newsblog app - I don't mean my own plugin!]
*(something like custom template per plugin instance)
How to replace it ? Extending template is not quite what I need - inheritance is from bottom - from lower subtemplate to base.html - but that plugin have hardcoded lower template.
Tons of IF block in template is irrational then we think in MVC.
*( like here Render Django-CMS plugins differently on different splaceholders/templates )
Or maybe just write custom template with using hardcoded including plugins ? But using django cms placeholder editor is very useful and it'll be better to keep working in that way :///
So, I create front.html base template for frontpage,
put some plugins to placeholders - and need to replace subtemplates for this plugins only in this front.html and keep subtemplates for that plugin in other places - this is main goal.
It will be the best, when django cms / aldryn newsblog provide option "custom template" per plugin instance :|
( like this one http://www.ilian.io/django-cms-plugins-with-selectable-template/ )
If I understand your question correctly (it's late here), you need a way to override plugin templates on a plugin instance basis because hacking django templates is not the way to go (I agree).
Django CMS does allow you to override plugin templates on an instance basis.
As shown in http://docs.django-cms.org/en/develop/how_to/custom_plugins.html?highlight=get_render_template#the-simplest-plugin
In your CMSPluginBase subclass add the following:
def get_render_template(self, context, instance, placeholder):
# criteria goes here
return 'sometemplate.html'
As far as how to know which template to render when (criteria), you can do a few things.
Use the page's reverse id:
page = instance.page
templates = {
'homepage': 'plugin_home.html',
'about': 'plugin_about.html',
'contact': 'plugin_contact.html',
}
return templates[plugin.page.reverse_id]
This approach has a few drawbacks:
Relies on plugin being bound to a page. (plugins can live outside of pages)
Can only work with pages that have reverse id set and reverse ids
are unique per page which means you would have to list reverse id
for every page you want to change template for.
Use a page extension to set a category per page:
Checkout http://docs.django-cms.org/en/develop/how_to/extending_page_title.html
With this approach you can then set some sort of category to multiple pages and so you can target multiple pages in one shot like so:
page = instance.page
extension = get_page_extension(page) # Check out docs for this
templates = {
'category_1': 'plugin_category_1.html',
'category_2': 'plugin_category_2.html',
'category_3': 'plugin_category_3.html',
}
return templates[extension.category.name]
Pros:
Can target multiple pages in one shot
Cons:
Relies on plugin being bound to a page.
A bit more complex
Use a template context variable:
In your templates, depending on how you're rendering your plugins, you can
provide a context variable like so:
{% with category='category_1' %}
{% placeholder 'content' %}
{% endwith %}
or
{% with category='category_1' %}
{% render_plugin yourplugin %}
{% endwith %}
Then in your get_render_template method you can access this context variable and do the following:
# Use .get() to provide fallback
category = context['category']
templates = {
'category_1': 'plugin_category_1.html',
'category_2': 'plugin_category_2.html',
'category_3': 'plugin_category_3.html',
}
return templates[category]
Pros:
No extra models.
Can target multiple pages in one shot.
Cons:
The only one I can think of is these random {% with %} in
templates.
I completely missed the newblog part, so in order to override the newsblog plugins or any plugin, just subclass the plugin class you want to override and unregister the original and then register yours, make sure yours has the same class name.
Maybe you can make the whole template logic above into a mixin to use throughout your project.
I've always wanted to give Zinnia a look, but I'm too far into working with NewsBlog on a site right now to do it (and blogs have already been posted and whatnot). You can always just add a few extra placeholders in the template (it's not the most efficient looking thing ever, but it's no load on the framework if you add a placeholder and leave it blank), that way they aren't static, and then you can put whatever plugins you want to inside of them. You can customize each component in NewsBlog pretty easily by just adding whatever you want in the structure mode. Things get trickier when it comes to having multiple blogs that act differently, but even then, as long as you're not adding components into the static placeholders provided by NewsBlog (or as I so elegantly learned it, "don't put the stuff in the blocky-things with the pins next to them), you can create different namespace for the different blogs (either in the admin, under "Configs" in the NewsBlog section, or when creating a new page and hooking it to the NewsBlog app), and you can have different templates on different blogs.
EDIT: This is a really excellent resource for touching up NewBlog without throwing the baby out with the bathwater (after three months of learning DjangoCMS, I'm still finding myself referencing it for fine-tuning pieces of NewsBlog, and to refresh my grasp on templatetags and other things that are overwhelming and have quickly left my brain along the way): https://www.django-cms.org/en/blog/2016/02/16/build-a-website-without-knowing-python-django-part-two/
*I linked to part two, as the first part deals with how to initially setup a project, and I assumed it probably wasn't relevant. Then again, if you're using Aldryn, there are some useful bits in there that can extrapolate if you're having trouble with customizing the boilerplate (or other things you'd like to configure that an Aldryn setup handles for you -- which is super awesome most of the times, but when it's not super awesome, it's usually super frustrating :)
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'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.
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.
What is the most efficient way (in terms of programming/maintenance effort, elegance) to render a Django forms.ChoiceField as a Twitter Bootstrap dropdown using one of the django-bootstrap, django-bootstrap-form, django-bootstrap-toolkit, django-crispy-forms, etc apps? Is there explicit support for this use case in any of these apps?
Disclaimer I'm the lead developer of <a href="https://github.com/maraujop/django-crispy-forms/"django-crispy-forms (one of the apps mentioned).
I will try to explain how you do this with django-crispy-forms. You simply do in your template:
{% load crispy_forms_tags %}
{{ form|crispy }}
You can see this and more in django-crispy-forms docs. Your ChoiceField will be rendered as Bootstrap dropdown as you want.
Compared to django-bootstrap
First, a little bit of history. django-bootstrap was born after django-uni-form (the parent project from which django-crispy-forms evolved). At that time, django-uni-form was already doing Boostrap forms, but probably not in the best possible way (Bootstrap was supported by using an aditional contrib application). Thus, the author of django-bootstrap probably decided to go on its own.
Now, regarding Bootstrap support. django-bootstrap can also render forms but, instead of using a Django filter, it changes the base class of your form. So django-crispy-forms affects your templates while django-bootstrap affects your Python code.
Also, both django-crispy-forms and django-bootstrap let you do layouts. In django-bootstrap, layouts are in a Meta class within the form while in django-crispy-forms the layouts live in a subclass of FormHelper, which gives you decoupling.
django-bootstrap uses a tuple for defining a layout, while crispy-forms uses a subclass of Layout. This adds the possibility to reuse layouts, compose layouts easily, etc. Note that although crispy's encapsulation still has a list of fields inside, it adds a helpful and human-friendly API to programmatically manipulate the layout and I think enforces a good decoupling pattern.
From what I can see, layouts in crispy-forms are more powerful. It has a larger layout object collection, for example, prepended text, appended text, daterange and others are already supported while in django-boostrap these are in the TODO list.
crispy-forms has also an API for modifying layouts on the go and doing some hardcore programmatic layout building which is very nice.
crispy-forms also supports formsets of all kinds. It supports different CSS template packs, which means that if in the future the new kicking CSS pack is named 'chocolate', it will be very easy to create a new template pack for it and all your forms will be able to be rendered with 'chocolate' without code changes, just a simple setting variable.
crispy-forms also has attributes you can set in FormHelper that define nice extra functionaly you can easily turn on and off. You can also create your own custom attributes if you want.
Finally, django-crispy-forms (together with django-uni-form) has more than 67.000 downloads, which is quite good for a Django application. The project has almost 500 followers in Github, several big users, good testing coverage and several years of history and it's still actively maintained.
Compared to django-bootstrap-form
From what I can see django-bootstrap-form is only a filter for rendering a form with Bootstrap. That is something django-crispy-form covers while offering much, much more. The project was released on 21st August 2012 and looks to me like it's reinventing the wheel because several other apps cover already this use case.
Compared to django-bootstrap-toolkit
It's inspired by django-boostrap-form. From what I see in the docs, it also gives you a filter for rendering a form with Bootstrap. It apparently covers more Bootstrap stuff than forms, but I can't find more info in its docs. Last commit was 2 months ago.
I will insist that I'm obviously not the right person for a comparison that is not biased. That's why I've never written about this before. I could have published a blog post about this several times but I always dismissed the idea. However, as the fragmentation of form apps (and bootstrap-support apps) is growing, I thought this might be a good time to write down what I think.