When I make a request to https://graph.facebook.com/me -- I get a large JSON object with lots of good data in it.
However, I want to also get the user's cover photo (if it exists). Is there a way to do this, while also retaining the default fields?
For instance: https://graph.facebook.com/me?fields=cover -- returns just the cover image.
If I use one field, do I need to specify exactly the other fields that I need?
You need to either itemise all the fields you want, or accept the defaults, there's no way to get 'defaults + these other fields'
Related
I want that my users can fill a post form partially, save as draft and then edit, finish and publish it. So the draft can have some required (text) fields empty. However I want the fields secure to store in the database (so, no special character, etc).
What's the best (or a good way) way to do this?
I think these solutions:
1) make two different models, one with required=False fields or
2) fill the empty text field with a temporary string ('draft'), then delete it e redraw as needed while edit, publish, save the draft. Or
3) deactivate the validation (novalidation, I'm not sure this works).
or what else?
I'm looking to the second way because the first I think will give me problems to manage two models and the third maybe is not secure.
PS I'm using ajax to call the views.
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.
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! :)
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.
As far as I know (I haven't looked into the django's admin source code deeply enough to figure out) Django's admin translates GET query parameters directly to the query filter conditions.
I was wondering, is this approach secure enough to be used in user-facing application? I have a list of data, that has to accept arbitrary WHERE clauses, and I'm thinking of implementing it by converting the GET parameters into a dictionary so that it can be passed into the filter() method of the queryset.
Yes.
The input will be escaped, so there can be no SQL injection attacks or anything similar. However the input might be invalid for the field(s) you are searching on. Or it may make no sense at all, so it is a good idea to do some form of validation (like the input date must be bigger than some other date, the input value must be smaller than X, etc)
However, if you want to display the data you received from the user as part of a page, you need to make sure to escape it properly. Documentation on the autoescape tag
I think the correct answer is "No, it's not safe"
http://www.djangoproject.com/weblog/2010/dec/22/security/
Django just released security fixes to 1.2.4 and 1.3b1 preventing users from constructing arbitrary query filter. With sufficient knowledge of the underlying data model and usage of regular expressions, arbitrary information, such as user's password hash, can be extracted.