I've seen a SO post on this but can't seem to find it.
My results are rendering in my template with the object_name as
{'sessions__sum': 29649}
instead of just
29649.
How can I show just the sum? Thank you.
Update
I realize, out of lack of knowledge, I may not have asked my question correctly, so below is my view and a screenshot of my template, rendered in the browser. Hopefully this will help clear things up.
view
year_weekly_filter.filter(created__week_day=1).aggregate(Sum('sessions'))
monday2014 = year_weekly_filter.filter(created__week_day=2).aggregate(Sum('sessions'))
Template
{{ monday2014 }}
ScreenShot - how its rendering in the browser
You should note that: "aggregate() is a terminal clause for a QuerySet that, when invoked, returns a dictionary of name-value pairs." - Django Docs
If you just want a single value to be returned to a variable and not a dict, use .get like so:
monday2014 = year_weekly_filter.filter(created__week_day=2).aggregate(Sum('sessions')).get('sessions__sum',0)
Do you mean the {{object}} in the template is rendered by the dictionary object?
In this case, the key is accessed in this way.
{{object.sessions__sum}}
and you may get help in this and the related documentation is here.
I don't have enough points to add a comment, so I leave my guess here.
Related
I was watching the new Boston Django tutorials. I know they are older, but he explains them well. I’m having trouble with one thing though.
He made a url
url[r’(?P<album_id)[0-9]+]
I know in Django 2.0 it’s a better way to do this. That’s not the question
His view looks like
def details(request,alblum_id):
return HttpResponse("<h2>The detail for the album ID:" + str(album_id) + "</h2>")
My question is how does Django know to get the id of the object from album_id if he never declared it. He just typed in a random variable?
is the "_id" part important for Django ? and that's how it knows the get the id of the database reference?
I understand i need to look at the view, I'm just confused on how Django knows to actually get the ID of the database reference. in the view it looks exactly like what i typed above. he just passed album_id beside request inside the parameters. I am still confused on how Django knows that "album_id" means go find the id of the database object. is that built in ?
link : [https://www.youtube.com/watch?v=mWofrhTwGWQ&list=PL6gx4Cwl9DGBlmzzFcLgDhKTTfNLfX1IK&index=12][1]
The view that is specified on the URL line takes the id most likely as a parameter then use that to look up in the database.
Essentially you need to look at the view to understand what he is doing.
The template change_list_results.html recieves a parameter which is called results. It contains every record (in db) in a raw_html for printing it in change_list.html.
I want to change the view which controls this results, for returning into it every value of the recod´s tables (as object) instead of a raw_html within it ( kind of ).
Someone knows where is this parameter sending to the template?
Thanks mates.
Found it. If someone want to know you must to override the inclusion tag called result_list over change_list_result.html. Cheers
Somewhere in my code, I hit a bug. I put a breakpoint to try and see what is happening. When I inspect the object "foo" in the console I get:
foo.toString() > "<App.Foo:ember661:174009>" // all good
foo.get('isLoaded') > true
foo.get('isValid') > true
Yet:
foo.get('name') > null // Whereas it definitely has a name.
When I look at the Network tab in the developer tools, I can see that it is still "finishing" to load the record. For the corresponding URL, it says: "pending".
What is this model state? How do you know when a model is "fully" ready?
UPDATE: per my comment to Mike, I should have added that I am inspecting this record within a registerBoundHelper function. So I guess there is a context issue that I am missing. Indeed:
... foo template ...
{{ name }} // properly set to a value
{{ my_helper this }}
... helpers ...
Ember.Handlebars.registerBoundHelper('my_helper', function(foo) {
return foo.get('name'); // name property is null!!
});
I must be missing something obvious?
Thanks,
PJ
What is this model state?
Can't tell given the info you provided, but to find out from console you could try this:
foo.stateManager.get('currentPath') > should be something like "rootState.loaded.saved"
Then have a look at states.js source code for details on that state.
How do you know when a model is "fully" ready?
Depends what you mean by fully and ready. Some tricks to help you see what's what:
Show me the raw data for a model
foo.get('data')
foo.get('data.attributes')
Get console log output when the record transitions between states
record.set("stateManager.enableLogging", true)
Answering my own question, in case it helps someone else...
This strange behaviour came from a context issue for the helper. It was pretty "deep" in a view (several nested levels down) and I am using a combination of {{partial}} and the new {{render}} that you can now use multiple times (on master). I'd lie if I were to say I am totally clear with what was happening, but I tried various contexts switches and it ended up working.
So I guess if you hit something like that, double check your helpers's context...
While learning with Django by Example, I have found something I don't yet know and haven't found any reference for it. I'm sure it is well documented somewhere, but I haven't found out how to search for it. Also, I apologize if I'm reasking an already answered question, I haven't found it here either.
What I would like to understand is the "admin: ..." syntax, which I met in several contexts:
In a template .html file:
Add Todo items
In a view function:
return HttpResponseRedirect(reverse("admin:todo_item_changelist"))
I have gone through the djangoproject tutorial and the first 8 chapters of djangobook, and I didn't meet it there. I know, though, that in a reverse function a view function may be passed, and that {% %} template tags 'do something', but I have only seen dotted syntax used for these cases, so far. May it be that for referencing admin features, instead of the dotted syntax, we use this colon?
I would really appreciate some brief explanation on what it does.
It's URL namespace. Admin docs:
https://docs.djangoproject.com/en/2.2/ref/contrib/admin/#admin-reverse-urls, general URL namespace docs: https://docs.djangoproject.com/en/2.2/topics/http/urls/#url-namespaces.
from django docs:
If you'd like to retrieve a namespaced URL, specify the fully qualified name:
{% url 'myapp:view-name' %}
This will follow the normal namespaced URL resolution strategy, including using any hints >provided by the context as to the current application.
I have a custom filter user_tz which takes user as an argument. It works fine everywhere, but when I tried to use this filter in the regroup tag it fails saying that user does not exist.
The code:
{% regroup proj_messages.object_list by created_on|user_tz:user as proj_message_list %}
This is the error I am getting:
Caught an exception while rendering: Failed lookup for key [user] in u"Today's tasks".
Thanks,
Masood Ahmed
Strangely even I came across this exactissue.
Though later I had to change my code, i couldn't get on its solution. Apparently what happens is something like as follows.
Whatever you write in templates, is splitted as Nodes, Variables etc. Variables, at time of rendering is searched in context available to that instance. And please note that, for regroup tags, the context available, is just that object_list, which you passed as first argument. Not the usual context(which contains 'user' in your case), which is global to whole template. So, it is unable to find any other variable you specified, which is not in you object_list.
Thus, in your case, the context available to regroup is an object from proj_messages.object_list. And so the resolver code is able to find variable created_on in context, but not user. And that is what throwing the template exception here.
Considering this just imagine, what would happen, if your object_list too, have had the user attribute. In that case there wont be any KeyError, but user passed to the filter, would be not at all the user variable you intended to pass.
Edit on request:
There is not direct way, to pass the user to the such use of filter in regroup tag. But a kind of hack will obviously work. Note, its just a hack. Make each individual entity/object of proj_messages.object_list to contain that user variable from view or using an extra filter on object_list from template.
But better than that, if you want user to be available anywhere, from outside the context, i would like you to consider yet another hack. Check out, http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser .