I have a model and Form being exposed via a Standard List View and the model has a number of calculated values which would also be useful to expose via the same List View. I don’t need the values to be sortable or even displayable, but there are features on the form when displayed which can be greatly improved by having these values available.
Including the name of the property in the field List on the Form that the List View uses doesn’t work - it generates an error : django.core.exceptions.FieldError: Unknown field(s) (xxxxxxx) specified for yyyyyyy
The only solutions I have found seem to be out of date (ie they don’t work on django 4.0.6.
The inbuilt Admin views seem to have this solved at least in part (you just add the field to the display list in the admin form for that model), but the standard List View can’t cope.
Is there a good way to solve this ?
Please show one example of what you’re talking about here for a model, along with what you’ve tried in the view.
Which bit of code did you want me to include - The ListView, the related Single Item Form, the Model or what : I am not trying to be awkward , but it isn’t clear what you are asking for.
The problem is as described - how do I make the Generic ListView make use of a field which is as a property on a model, or an annotation on the queryset : Either way results in an error (although the error is subtly different if you use an annotation).
The only way I can see it to drop the ListView entirely, and hand craft a template based on a query set - but that makes handling edits difficult (though not impossible).
You’re trying to display and handle a form in a ListView?
If so, that’s a mistake - ListView isn’t the base class you want to use in this situation. You’d want to build this on one of the FormView classes, and add the listing as additional context data. (Otherwise, you’re needing to add a lot of additional functionality to methods in the ListView that really aren’t designed or intended to handle. Or, in the ideal case, you’d be creating your own CBV combining the features of both if you’re doing this in multiple places with different combinations.)
No worries - I’d much rather you ask for clarification than to post a lot of what isn’t needed.
I’d like to see:
-
The model. It doesn’t need to be the complete model. Maybe just the fields needed for the calculation of the calculated field, along with the methods used to calculate those fields.
-
The view. Either version is fine, as long as you post the complete error with traceback from the server console.
-
The template. Enough to show where in the template you are trying to render these values, and enough context for me to understand where the variables being referenced are defined.
What I mean is that if you’re passing a variable in the context named qs, where qs is a queryset to be displayed as a list of items, and, you have a tag like {% for item in qs %}, then I’d need to see that tag included to be able to understand where the variable item is coming from. Otherwise, if I see a variable reference {{ item.name }}, I have no way of knowing what item is.
If you’re interested in posting both versions (“property” and “annotation”), I’ll certainly try to identify the cause of the error in each.
My experience in working with cases like this is that the error is not occurring because of what someone is trying to do, but because of how it is trying to be done. It’s not that the idea is flawed, but there’s some detail that hasn’t been accounted for in the implementation. (You can find hundreds of examples here where errors are being caused by something small being overlooked or misunderstood.)
Keith,
Thank you for your interest in this problem but i am going to close this - I realised I could have gone down the route of a Generated Field but I have only just discovered they exist, and even then I am not sure that they would help.
I did realise that I didn’t need all of the features (and complexities of the List View) what i needed was a simply class that would mimic the DetailVIew/UpdateView/ListView (pretty simple functionality) with the added ability to support a separate query set that would drive a read-only list. The code for that (with one or two wrinkles) is actually pretty simple and without the need to use the Generic Views.
I now have a nicely formatted list to the left of my screen which lists the instances available to the user, and the right panel can show the details or a form for the instance selected from the left, and not a generic view in sight.