Currently working on a e-commerce project (with django-oscar), I have an issue regarding products display on the basket template.
I use the {% regroup %} tag because I have several types of products : standalone, parent or children. Each basket line corresponds to a product, and if several of them are children sharing the same parent product, I want them to be regrouped under their common parent. However, I want standalone products to stand on their own.
My queryset is the following :
in_stock_lines = request.basket \
.all_lines() \
.order_by('product__parent', 'date_created') \
.filter(attached_to=None, product__product_class__name='Produit standard', is_customized=False)
In basket.html:
{% regroup in_stock_lines by product.parent as parent_list %}
{% for parent in parent_list %}
{% if parent.grouper %}
{% include "basket/partials/_basket_non_customized_product.html" %}
{% else %}
{% include "basket/partials/_basket_non_customized_standalone_product.html" %}
{% endif %}
{% endfor %}
The thing is that I don't want the regroup to act in the {% else %} part, because they are standalone products and are not supposed to be regrouped. But as their product.parent, i.e. the grouper is None, they are.
Is there way to prevent the {% regroup %} to act for a certain grouper value ? I could make two distinct queries in my views.py to separate standalone products from the others, and not include their template in the {% regroup %}, but I would like to avoid to make two queries if it can be.
Any help appreciated ! This is my first question on Stackoverflow, sorry if I miss some basic rules about the way I ask it.
I don't think that is something you can do in the template directly. Django deliberately limits the 'tools' available in its template language to discourage putting too much logic in the templates.
Whilst you could do the work in views.py, as what you're doing is quite presentational, I would suggest a custom template tag (more specifically an inclusion tag) is probably what you want.
You should be able to avoid multiple queries as the grouping logic is quite simple. I'd suggest looking at collections.defaultdict for simple grouping.
Related
I am running through this wired issue. I hope I can describe it well.
The case:
Suppose that I am having the following types or identifiers:
classes = ['classa','classb','classc','classd']
and I am also having for each of the above class, these two subclasses:
subclasses = ['suba','subb']
Now, I am going to retrieve data points from the databased filtered on those classes and sub classes using a function in my model name it get_data_filtered(a,b) as follows:
context['custom-data'] = (
{c: {subc: self.get_object().get_data_filtered(c,subc)} for c in
classes for subc
in subclasses})
When printing this context to the console on the view level, everything is fine. However, when passing it to the template and accessing it there, no data is retrieved!
When viewing the template using Django Debug Toolbar, the template context shows this:
context['custom-data']:'<<triggers database query>>'
The syntax in the template level is similar to:
{% for i in custom-data.classa.suba %}
....
{% endfor %}
My analisis
I think the queryset never got evaluated this way. I also tried to put .all() and list(...) but getting nothing useful!
Can the queryset got evaluated this way?
If there is a better way to achieve such task please advice.
Django version: 2.2
I figured out that I was not accessing the context in the template level properly. The access shall be by keys just as follows:
{% for c,subcdict in custom-data.items %}
{% for subckey,objlist in subcdict.items %}
{% for obj in objlist %}
<p>{{ obj.prop }}</p>
{% endfor %}
{% endfor %}
{% endfor %}
Thanks for #moh369 observations in the post comments.
I'm using django-haystack for a search page on my site, and I want to order all the results by their content type. Is there a way I can do that?
To make it simpler, suppose I have a single application and several classes.
Thanks in advance
Not sure what you mean by content type, but if you are talking about group by models, I have this working
{% with page.object_list as results %}
{% regroup results|dictsort:"verbose_name_plural" by verbose_name_plural as grouped_objects %}
{% for ct in grouped_objects %}
{{ ct.grouper }}
{% for result in ct.list %}
<p>
{{ result.object }}
</p>
{% endfor %}
{% empty %}
<p>No results found.</p>
{% endfor %}
{% endwith %}
from How to order search results by Model:
You can do
SearchQuerySet().order_by('django_ct').
As a warning, this throws out
relevancy. The only way to keep
relevancy & group by model is either
to run many queries (one per model -
usually performant thanks to query
caching) or to run the query and
post-process the results, regrouping
them as you go.
from searchindex api:
Haystack reserves the following field
names for internal use: id, django_ct,
django_id & content. The name & type
names used to be reserved but no
longer are.
You can override these field names
using the HAYSTACK_ID_FIELD,
HAYSTACK_DJANGO_CT_FIELD &
HAYSTACK_DJANGO_ID_FIELD if needed.
One very annoying thing with strict MVC is that you can make the smallest processing in template. While it's usually a good practice, in this case it gets in the way:
I make a for loop on a queryset of a lot of objects and display some attributes;
Attributes are properties, making heavy processing (I don't want to trigger them twice).
At the end I need to display a total of the value of these attributes.
I now I have to do the sum once in the view, then reloop (and call the properties again) to display. I can improve that by loopring once in the view and caching the results, but then I get more code just to bypass this limitations, and I use more memory.
At this stage of the project, it's not THAT a big deal. Performance is not the issue yet at all. But I really like to know is there is a solution for this.
My best bet is to write a template tag that does the job, but it's such a chore :-) Do you know somebody that would have done that already?
E.G:
Ideal, it sould be something like:
{% for object in object_list %}
- {% sum_in_and_print object.property total %}
{% endfor %}
total {{ total }}
that would display:
- 2
- 3
- 1
total 6
I don't see how it's a chore. Check if the destination variable is in the context, and if not, initialize it with an empty-constructed object of the class of the first element in the list, then accumulate.
As an alternative to calculating the sum in a view or template, what about QuerySet.Annotate(total_x=Sum('x')), to have the database take care of the calculations?
Aside: I believe trying to solve the actual problem sometimes warrants not answering the direct question when there is not an obvious answer.
I'ts quite hard tag to write nicely. You will have to take care if evaluation order is ok (sum may be displayed above data). That you can have many sumup sections (maybe data too). You will need probably following structure:
{% raport %}
{% sumup %}
...
{% endsumup %}
{% data %}
...
{% enddata %}
{% sumup %}
...
{% endsumup %}
{% endraport %}
EDIT:
Also you will have hard times, to parse multilevel structure:
{% raport %}
{% sumup %}
...
{% endsumup %}
{% data %}
{% raport %}
{% sumup %}
...
{% endsumup %}
{% data %}
...
{% enddata %}
{% sumup %}
...
{% endsumup %}
{% endraport %}
{% enddata %}
{% sumup %}
...
{% endsumup %}
{% endraport %}
I don't know what project your're developing, but if you already require users to have JavaScript, you may check jQuery.calculation plugin. This is a great tool to shift all dumb calculations to the client side.
Look into a different templating system like Mako. Mako especially allows full python code to run within the template.
Is there a compelling reason you're not doing this in the view?
What could be easier than:
total = sum([o.property for o in object_list])
Even if your goal is to use generics, you can always wrap it in a view function.
Let me add that I think the functionality you specifically want: to output a variable and add it to some arbitrary variable -- is such a unique one that absolutely you'll want to write your own template tag for it.
Fortunately, this is very easy.
Update
As I said in the question the property
trigger HEAVY processing. I don't want
to trigger them twice...
So you could try this instead:
rendered_object_list = []
for o in object_list:
rendered_object_list.append({
'field1': o.field1,
'field2': o.field2,
'property': o.property
})
total = sum(o['property'] for o in rendered_object_list)
You process it once, in the view, then when you output it in the template, it's a dictionary, with everything in the dictionary already processed.
In this excellent Google Tech Talk by Jacob Kaplan-Moss, Jacob says that they added support for the include template tag despite previous dogmatic objections, and says that people shouldn't use it.
Does anyone know why? A quick search didn't show anything that would explain why. There's nothing relevant in the now-fixed ticket where support for an include tag was added. I use include tags liberally to avoid repeating myself, which seems like a good idea, but maybe I'm missing some core reason why those who know think it's bad.
I suppose he wants to encourage template reuse by inheritance (using extends) rather than by composition. Perhaps the implication is that if you can't organise your templates this way, the dogmatic opinion is that your site is organised poorly. (For example, if you are reusing a navigation menu, shouldn't it always be in the same place in the page structure? Why should each individual page decide where to put it?)
By the way, using include doesn't do much to help you stay DRY, because any context that the included template requires must be passed from all the views that use it.
By contrast, using a custom inclusion template tag allows you to execute arbitrary Python code at the point where the tag is included, rather than in the view (or by shoving it into a model just to make it easier to access in the template).
As a trivial example, I wanted to show a list of users' avatars. Using include, it looks like this:
{% for user in users %}
{% with user.gravatar_url as avatar_url %}
{% include "foo/bar/avatar.html" %}
{% endwith %}
{% endfor %}
With a custom tag:
{% for user in users %}
{% gravatar user.email %}
{% endfor %}
Using the custom inclusion tag meant that the Gravatar hashing logic no longer had to be a concern of the User model, nor of the view function.
This said, I think are are some situations where you inevitably have similar data in the context of multiple templates, you don't need to do anything fancy with it, you just want to display some of its attributes so you don't want to write a function to make it work.
For example, I wrote a blog application (who hasn't?) which had two types of archive view: a basic sequential, X-posts-per-page one, and a monthly archive view. Both templates obviously had a list of posts in their context, both used exactly the same summary template fragment to show a title and excerpt from each post, but each template presented them in a slightly different context. So I used:
{# in archive_index.html #}
{% extends "base.html" %}
{# some stuff specific to sequential archives here #}
{% for post in posts %}
{% include "post_summary.html" %}
{% endfor %}
{# probably more stuff specific to sequential archives #}
And...
{# in archive_monthly.html #}
{% extends "base.html" %}
{# some stuff specific to monthly archives here #}
{% for post in posts %}
{% include "post_summary.html" %}
{% endfor %}
{# probably more stuff specific to monthly archives #}
It really seems that in this case, composition makes more sense than inheritance. In fact it was difficult at first to imagine how inheritance would work here at all. Well, it's still possible:
{# in base_archive.html #}
{% extends "base.html" %}
{% block archive_header %}{% endblock %}
{% for post in posts %}
{% include "post_summary.html" %}
{% endfor %}
{% block archive_pagination %}{% endblock %}
Now, the two different archives extend this and just inject their unique stuff into the blocks:
{# in archive_monthly.html #}
{% extends "base_archive.html" %}
{% block archive_header %}
<h1>Archive for {{ month }}</h1>
{% endblock %}
{% block archive_pagination %}
{# previous/next month links here #}
{% endblock %}
I'll leave imagining what archive_index.html looks like as an exercise for the (no doubt bored) reader.
Phew! It feels smart to have come up with a way of doing the same thing using both composition and inheritance, but is the latter just bending over backwards to conform to the dogma that Jacob Kaplan-Moss mentioned?
Having just watched the video (yes, all 1 hour 5 minutes of it, just so I could finish answering this question), I don't think Jacob would be enormously bothered. It sounded like an off-the-cuff comment, maybe a reference to which technique you ought to consider first.
I find django's template language very limiting. Following along with django's DRY principle, I have a template that I'd like to use in many other templates. For example a patient list:
{% for physician in physicians.all %}
{% if physician.service_patients.count %}
<div id="tabs-{{ forloop.counter }}">
{% include "hospitalists/patient_list.html" %}
</div>
{% endif %}
{% endfor %}
The problem is that the patient_list template is expecting a list of patients named patients. How can I rename physician.service_patients to patients before including the template?
Thanks,
Pete
Use the with tag:
{% for physician in physicians.all %}
{% if physician.service_patients.count %}
{% with physician.service_patients as patients %}
<div id="tabs-{{ forloop.counter }}">
{% include "hospitalists/patient_list.html" %}
</div>
{% endwith %}
{% endif %}
{% endfor %}
You might also upgrade to creating a custom tag:
{% for physician in physicians.all %}
{% if physician.service_patients.count %}
{% patient-list physician.service_patients %}
{% endif %}
{% endfor %}
Although custom tags involve writing Python code, there are shortcuts that make it easy to use an existing template file as a tag: Django Inclusion Tags
When you have "functionality" (specifically an if-condition) inside a loop, you have an opportunity to move this into the view function.
First
This construct
{% for physician in physicians.all %}
{% if physician.service_patients.count %}
{% endif %}
{% endfor %}
Is so common that you have several ways to avoid it.
Change your model. Add a patients" method and use it instead of the default query set that you get with a on-to-many relationship. This method of your model has theif service_patients.count` test, removing it from your template.
This eliminates the {% if %} from your template, reducing it to {% for %} and the actual HTML, which cannot easily the eliminated.
Change your view function. Write a few lines of code to create a list of physicians with service_patients instead of a simplistic collection of physicians. This code in your view function has the if service_patients.count test, removing it from your template.
This eliminates the {% if %} from your template, reducing it to a {% for %} and the actual HTML, which cannot easily be eliminated.
The point is to get rid of the {% if %} so that you're simply cutting and pasting the {% for %} and the actual HTML. By keeping your template to just the HTML (which cannot be eliminated), the only overhead is the {% for %}
Second
It appears that you want to reuse an {% include %} construct in slightly different contexts.
It's not at all clear what the problem with this {% include %} file is. It is "expecting a list of patients named patients" seems superficially silly. Fix it, so it expects physician.patients.
Perhaps you want to use this same list twice. Once with a list called 'patients' and once with a list called 'physician.patients'. In this case, consider (a) simplifying or (b) writing a template tag.
It appears that you have a patient list that is sometimes a stand-alone page, and other times is repeated many times on a much more complex page. Repeating a list of details embedded in some longer list is not really the best page design. Django doesn't help you with this because -- frankly -- it's not easy for people to use. Hence option (a) -- consider redesigning this "patient list within a physician" list as too complex.
However, you can always write a template tags to create really complex pages.
Summary
There's a really good reason why the Django template language has limited functionality. All of your functionality should be either an essential feature of your model, or a feature of the current application that uses the model.
Presentation is simply the translation of objects (and querysets) into HTML. Nothing more
As way, you can try to use in quality templating language jinja. It is more flexible.