I have a field that I want to check if it's unique in my store. There are tons of tutorial on how to do this, but for my particular uniqueness it depends on the value of another value in the form. I need to check if the combined value is unique. Anyone have an idea on how to do this? The only solution I can think of is using a computed property (two fields combined), and having a validator on that. That seems kind of messy though.
I was able to get around this by adding the other field as an option.
Related
I have a page where I'm displaying the results of a queryset to the user.
What i'd like to do is allow the user to click on a link in order to apply a filter.
Currently what I do is have the links pass "get" parameters to the page in order to apply filters. The filters can be references to other models or custom filters (e.g. an unassigned filter)
In order to provide a decent user experience the implementation needs to do a few things
in the view:
check that the filter parameter passed is valid
check what type of filter it is (based on other models or a custom filter) in order to apply the correct condition to the queryset
(optional) a way to make the filters cumulative (i.e. you can keep adding filters)
in the Template:
display the correct resultset based on the filter choosen
when displaying the filters, recognize which filter we have applied so that the current applied filter is displayed as text not a hyperlink.
I'm thinking this must be common enough that someone must have like a design pattern or best practice figured out for this other than the obvious whack of if/else statements in the view and the template.
is there?
I find the way the Django admin handles this kind of functionality a great pattern. If you're not familiar, check out the list_filter option in the admin. It's similar to what you're describing, but yours is a bit more generic. Perhaps this will help you ponder some ideas?
First, for the actual querystring chunk, you're simply passing the Django-ORM lookup key and value pair. e.g., ?sites__id__exact=1, tags__in=words, etc. Since you want to allow for cross-model lookups, you'd need to provide another parts in the string to include the model name, not too tough.
For checking if the filter is valid, you can simply ensure that the model/field lookup is valid. By splitting the parts of each QS chunk, you can identify the model, the fieldname, the lookup, and the value. Then, use Django's built-in functionality to validate that fieldname exists on model. You can do this with ForeignKey's too. Here's how Django does it
You can keep adding filters pretty easily to this. You'll be providing your view and the form that's displaying these filters with some context, so it'll persist and re-populate for the user. Also, you could just as easily persist the query string. Basically, you'd have the same read / parsing functionality here at all times, nothing really different.
I think the keys are automating and keeping it as DRY as possible. Don't succumb to a bunch of if statements. It's really easy to pass these lookups into the ORM, safely too, and it's really easy to catch bad lookups and provide the user with a meaningful error message.
I hope that helps you on your path! :)
Before I start on this project I want make sure what I am proposing is feasible. There is an unusual requirements I have to satisfy.
The model and formModel fields have to support a comment field on every field. I would like to be able to access them by object.field and object.field.comment. At first glance, this looks like I should have a separate type of comment and then somehow link it to correct field but is there a way to create a custom modelField that stores data in more then one database field from one or more form inputs? I would think there would have to be a custom widget to support this too?
If anyone has any ideas or examples of anything like this please respond.
I think this is the answer to my question. I have not tried it yet, but from the description it looks like what I need. https://docs.djangoproject.com/en/dev/ref/forms/widgets/#multiwidget
I am developing an application in Django and I am curious on how I can go about adding a model such that only 1 row is only ever present (i.e. Singleton).
As an example, I'd like to maintain a set of boolean flags of the application i'm running as to whether: it's on or off (so I can manually turn it on or off, perhaps even per module).
I can't see any part of the docs explaining a good way to go about setting this up.
Any suggestions?
Not sure from you explanation in what context you require this but I have a model which holds a number of key/value pairs used in validator checks and other things. The keys are all needed by each implementation of the project but the values will differ between projects. The values should be maintainable by an admin user. The values usually do not need to change very much once set. Given that, I decided to put them in a model. It is a bit weird but simple enough.
You should be able to limit write access to the model to the one row for either your app or your users through your code.
only ever reference the first row in the QuerySet
row = MyVariables.objects.all()[0]
Test if there are rows first. if you think there might accidentally be more than one record then make sure it is ordered (but that should never happen if you did (1) correctly.
There are a couple of apps already dealing with this, check out http://djangopackages.com/grids/g/live-setting/
I'm also a bit confused on your goal, but I'd recommend looking at the Model Instance section of the docs. You should probably look at customizing the validation or cleaning of the model.
If your goal is to only have 1 row flagged in the table for your model: during the validation you can run a query to see if any other row is flagged, and update them to be not flagged. (or delete them).
This question Unique BooleanField value in Django may be helpful.
I have a list of categories, each of which has a metacategory. I then create some select multiple fields to allow a user to filter which objects he wants to see. This gives me a dictionary like this:
filter={'genres':[id1,id2...],'parts':[id9,id11...],...}
Now i want to store that to the user profile, so the user immediately gets his last search results when returning to the page.
I know i could do this with a M2M field, but that would involve to recreate the filer dictionary, so i would prefer to store the dictionary. Is this a bad idea? Why? If not, what would be a good way to do it?
As already mentioned pickling is one option. Personally I would choose a JSONfield (you can find them easily just Google) as the format is more readable which can be nicer for debugging.
It's worth pointing out that it's hard to query models based on data stored in dictionaries. It looks like that won't be an issue for you though.
First option is to just pickle the dictionary and store that. For this you can use django-picklefield.
I might be inclined to stick this in a Cookie though: it's not sensitive (I assume), the user may never return, it's not something that I need to store.
I was wondering if there is already a way to create a separate autoincrement-ID-per-user field in Django?
Basically, I'm storing many related models and I need the IDs generated to be autoincrement per user.
I don't want to change how id works, just need a new field that I can add which is unique=True per user.
Any suggestions (other than overriding save and implementing it myself)?
No, there's no such field, but I wonder why you think you need it. The ID is really just for the model's internal use, you shouldn't ever care what it is.
For example, if you want to know how many related items there are for a user then you would just use the count() method on the related queryset. If you want something to be unique per user, you can use the unique_together meta property.
Can you given an example of a use case for a per-user unique id?
Edited in response to comments: to get the object from a URL as you mention, you just need to do:
myuser.myobject_set.all()[7]