I have a model with tons of (10-20) fields, some of which are Textarea fields.
All of the textare fields should have a certain size (which differs from the default). I could set them all using the widget dictionary in the Meta class, but then i'd have to set them one by one, which seems unnecessary redundant.
Is there any better way to solve this?
Update:
Since it was suggested in the comments to use database normalization, I'm going to flesh out my case a little bit:
I have an model object which has the main purpose of taking in a lot of user data (i.e. an "application"). The benefit of just writing out every question to the user as one field is that I can easily create a model form for it and display and edit the data in the admin (which is good for my crm people as well).
I could create a dictonary like model for every field of the form but I'm not sure how I would go about actually using a ModelForm for creating it.
On the basis of your data, I can only offer this approach:
from django import forms
textarea_fields = ['field1', 'field2']
form = YourForm()
for field_name in [f for f in form.fields.keys() if f in textarea_fields]:
form.fields[field_name].widget = forms.Textarea()
Related
I have a form with some Model(Multiple)Choice fields that have so many options that I would like to trim down the available options based on user responses on the front-end, and then populate the select options through AJAX.
I am a little confused as to when Django will query the database in this case, and what are considered the best practices for Django ModelChoice fields that are populated with AJAX data.
Originally, I had been doing things like this:
contact = forms.ModelChoiceField(queryset=aRelatedModel.objects.all())
or a restricted queryset:
contact = forms.ModelChoiceField(queryset=aRelatedModel.objects.filter(somefield = someValue))
So, my question is, when does the DB get queried for ModelChoice options?
The confusion stems from another form I did, where I had a ModelChoiceField with the ability to add new options dynamically. In that case, unless I instantiated the ModelChoiceField after saving the new option, I would get an error. This makes me feel like the database is queried on form instantiation. But, given the lazy nature of Django querysets, it seems like it would also make sense that the DB is not queried until you iterate over said list (ie, when printing the form options).
So, in this kind of case is there a way to avoid potentially needless DB queries? What is the best practice for ModelChoiceFields that will be populated with AJAX data?
I've seen mentions of:
contact = forms.ModelChoiceField(queryset=aRelatedModel.objects.none())
...but never any explicit explanation on why to use this.
Edit:
In that case, I had a form with
field = forms.ModelChoiceField(queryset = relatedModel.objects.all())
Subsequently in the view, I naively did:
myForm = modelForm(request.POST). This produced an error if I instantiated the form before first saving the dynamically added field. After adding the field, and then calling modelForm(request.POST) I no longer had an "invalid choice" error - presumably because the dynamically added field was now included in the modelForm queryset.
I am not sure how that is relevant to the question, however. The question is when a modelForm's queryset is populated with data from the DB.
Can I add additional fields to ModelSerializer subclass?
By saying 'additional field', I mean some fields don't belong any models in database, which any effort that try to map those fields to exist model fields will fail. The reason I need to include those fields is for design purpose. I need to those fields' value to do the validation and creating a new instance eventually.
I know there is a kwarg in ModelSerialzer called 'context'. By putting all the additional information into 'context', it will work. However, I want to know is that possible to create additional fields?
I have tried adding 'write_only=True', which doesn't work. The only left option is to override default restore_object method to create the instance with my will.
Any other ideas?
As you have not posted any code I can only give you a generic answer, but if I understand you correctly, you wish to add a custom field to a ModelSerializer thats not part of your model...
In DSF you can do this very esaily (read here):
In this case you just want a simple read-only field, so instead just use:
custom_field = Field(source='get_whatever')
In terms if validation after that please read the DRF guide here
I have a model called "occurrence" which tracks occurrences of species at different sites. The model has 4 fields.
refID (foreign key to the reference source of data)
siteID (foreign key to site)
speciesID (foreign key to species)
abundance (integer)
I know I could create a model-form to add an entry. But modelforms would be tedious because, most of the time I want to enter data for dozens or hundreds of species with the same combination of siteID and refID. I have created my own data entry form in the template to select a refID and siteID, and use jQuery to add new lines for speciesID and abundance. Thus, I have a single refID + siteID combination, with many speciesIDs + abundance lines. Then, the idea is to iterate over all the added lines and save all the occurrences in the view.
The problem is that validation of this form is quite difficult, as I have to do everything "manually" in the view. This seems like it might be a common problem, so I wonder.....
Am I missing a pre-existing Django solution here?
Probably you're, as far as I understand your question.
have a look at Formsets
The simple solution to this problem turned out to be using a modelform to save a single instance at a time. I made the refID and siteID fields "sticky" by passing back the saved values for those fields to the reloaded form using the "initial" argument to the modelform. This way, I can use all the built in form validation.
I've got a hierarchical model structure and have defined by own field types using OneToOneFields as described here.
I'm now writing a view customiser which takes any Model within this hierarchy and creates a form on-the-fly with checkboxes for each field to toggle visibility. Now I would like to remove the fields that link the models together (i.e. all those described using parent_link=True) but the property seems to have vanished from the fields in question, much to my displeasure. (I'm doing this because no-one would wish to view a Parent Relationship in the views I have composed).
My question is therefore, does anyone know how to locate that property at runtime?
I have a requirement where one user creates an 'instance' of an object via a ModelForm. Another user of a different group has access to read all of the fields of the form, but has to update only one field. Think of a student who creates an exam object. Then a teach pulls up the exam and just needs to put in a grade, the rest of the exam is read only.
What's the best way to do that? Should I just query for the object, and display each field individually, then create a form (not a ModelForm?) for just the one field?
Should I just query for the object, and display each field individually, then create a form (not a ModelForm?) for just the one field?
This is probably the best way to go about it. Note you can use a ModelForm for the teacher form, see the Django documentation on using a subset of fields on a model form. You will have to display all the other fields manually in your template, but you should probably have a separate template for this view (I would use separate views as well).
You could find some code for a read only field on Django Snippets, but generally it's better to be explicit about what fields you are updating from each view. This is likely to be more trouble than it's worth.