Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
Can someone please explain me why is highly recommended to use Django forms to get an html object instead of direct accessing from request.POST or request.GET?
In short: forms make retrieving and validating less error-prone, and often will perform a lot of logic that would otherwise require (a lot of) boilerplate code.
The items in request.POST (or request.GET) are send by the browser, so you can in no way guarantee that the items will (all) be present, and in the expected format.
Indeed, request.POST['somefield'] can raise a KeyError in case the POST request does not contain an key-value pair with somefield as key. Of course you can wrap this in a try … except …, but that easily will generate a large amount of code for a form with multiple items.
Even if the item is present in the request.POST, it is not per see in the expected format. For example if you use a number field (<input name="somefield" type="number">), you expect a number. But one can easily "forge" a HTTP request, where somefield contains 'blabla' or 'forty-two' instead. Django can validate the format of the fields. For an IntegerField [Django-doc] for example, it will require the value to be an optional minus sign followed by a sequence of digits.
A Django form will also "clean" the values. THis means that if you use an IntegerField, and later you access form.cleaned_data['somefield'], it will not have as type a string, but an int. You thus do not have to do the conversion yourself explicitly. This means that you can immediately add the values of two IntegerFields together for example, whereas if you do it yourself, these are first strings, and adding these together would concatenate the strings.
If cleaning or validating somehow fails, and a field contains an error, then a Form can explain what the error(s) are. You can access form.errors, which is a dictionary-like object that maps the names of the fields to a list of problems. It also makes it more convenient to list multiple errors. For example if a password should be at least 10 characters, and contain an uppercase, you can report both problems.
A ModelForm [Django-doc] also makes creating and updating an object more convenient. It has a .save() method for that. This thus will create a new record at the database in case the .instance wrapped in it was not yet saved, or update the record otherwise. It furthermore also will save ManyToManyFields (at least if you do not set commit=False). This is a tricky task since in order to save the objects in the many-to-many relations, you first need to create the object at the database side.
Finally you can also use a form to easily render it at the HTML side. There are Django apps like django-crispy-forms [GitHub] that can give the form another look. It thus makes it convenient to render the form, and easily change the appearance if you change your mind.
Related
I have a complex many-to-many relationship defined. The cross-reference table is an entity, so I have Contact with a One-To-Many to ContactList, and List with a One-To-Many to Contact List. Contact List contains listID, contactID, and a few Booleans. The relationships seem to work well and on the backend I can get a list of contacts on a review list using the Spring-Data-Jpa findByContactListsIn(Set).
However, I am trying to build a list of contacts in Freemarker, and show whether they were in the current list.
Before I made an Entity out of ContactList, I had a standard Many-To-Many relationship between them, and I was able to do something like this in my .ftl:
<#if list.contacts?seq_contains(contact)>
But I needed to add some data to ContactList specifically, so I needed it to be more complicated. How can I do something similar now? I tried:
<#if list.contactLists?seq_contains(contact)
But of course that always returns false, because it is comparing two different entity types. Is there a way to find if a contact is in one of the contactList objects?
I suppose I could do some back-end trickery, but I am looking for a front-end solution to this.
Don't use ?seq_contains for finding generic object at all. It doesn't call Object.equals, instead it works like the == operator of the template language, which only allows comparing strings, numbers, booleans and dates/times, otherwise it gives you an error. Unfortunately it won't fail in your case, because POJO-s are also strings (and their string value is what toString() returns). This is an unfortunate legacy of the stock ObjectWrapper (scheduled to be fixed in FM3); not even a quirk in the template language. Ideally you get an error there. Instead, now it silently compares the return value of the toString()-s...
Your data-model should already contain what the template should actually display. FTL is not a programming language, so if you try to extract that from the data-model in it, it will be a pain. But, that the data-model contains that data can also mean that some objects in the data-model have methods that extract the data you need. As a last resort, you can add objects that just contain helper methods.
Update: Returning to ?seq_contains, if you need the Java semantics and list is a Java Collection, you can just use the Java API: list?api.contains(contact).
I am trying to add a simple "required" validation rule to a file input in a form. Logically, it should fail if the no file has been inputted (and the input is thus null). However, it manages to pass without issues, because the HTTP request ignores and thus doesn't validate the file when it is null....which defeats the purpose of having a "required" rule at all.
Even stranger, the code I'm working with allows for multiple files grouped up with "name='file[]'", and even here it ignores whatever inputs are null. For example, if I have 5 file inputs and only fill in 3 of them, the resulting array in the HTTP request will only have the 3 non-null inputs, regardless of order.
So I'm aware of what the issue is, but not really how to resolve it. Does anyone know how to force Laravel to recognize and thus validate null file inputs?
Should I treat all api response as "resource" and return a JSON object or simple array would be appropriate as well ?
for instance are all of the below responses valid?
GET /rest/someresource should return collection of ids
[{id:1},{id:2}]
{{id:1},{id:2}}
[1,2]
GET /rest/someresource?id>0 search for ids bigger than zero and return collection of ids
[{id:1},{id:2}]
{{id:1},{id:2}}
[1,2]
Collection Resources
It is acceptable to return an array of resources - either a list of ids, or object structures - such a thing is commonly known as a 'collection' resource.
See http://51elliot.blogspot.com.au/2014/06/rest-api-best-practices-4-collections.html for an examination of resources and collections.
While not required by REST, it's common to use a plural noun to refer to a collection resource - e.g.
/rest/someresources
REST also requires the use of defined media types, and there are a couple available to assist with collections, e.g.:
Collection+json
Provides a structure with meta data around a list of items wherein you define the structure of each item as your resource
HAL
provides a structure with embedded collections and embedded resources
And many more
All provide a defined structure for including hypermedia links for your resource, or each resource in your collection - and if you are doing REST this is one of the things that the spec says you MUST do (even though many people don't).
Your Proposed Json Structures
Some more specific comments on your proposed json structures:
Option 2 is not valid json. Consider:
{{id:1},{id:2}}
A json object must have a name:value pair, e.g.
{somename:{id:1},someothername:{id:2}}
would be valid - but not very useful!
Also - strictly for json, the name should be enclosed in quotes. the value may be enclosed in quotes if it is a string.
So if you don't want to use a commonly used media type as referenced above, your options are 1 or 3. which should be:
[{"id":1},{"id":2}]
[1, 2]
Both are valid, however option 1 will give you more flexibility to add more properties to each element of the array if you decide in the future you would like to return more than an id. e.g. at some point in the future you might decide to return:
[{"id":1,"name":"fred"},{"id":2,"name":"wilma"}]
Option 3 will only ever be able to return a list of ids.
So personally I would go with option 1.
Depends on how RESTful you're aiming to be.
In addition to what #Chris Simon said, I'll add that if the server would only return IDs at GET /rest/someresource, the client would have to repeatedly call something like GET /rest/someresource/{id} in order to obtain data (it can display on the UI), right? This in turn would just increase the load on the server. If the id would be enough, you can probably get away with the proposed solution.
Also, once you decide you'd better be consistent.
Given that the 2nd option is not even valid, and the last is pretty limiting, I'd also go for the first option, JSON.
Just to make it clear we are talking about different representations of the same resource here:
By GET /rest/someresource both [{id:1},{id:2}] and [1,2] are valid responses, but you should make clear which one you want to see, e.g. with the prefer header. So by Prefer: return=minimal you would return [1,2] and if the header is not present, then [{id:1},{id:2}]. Just make sure that the prefer header is registered by the vary header, or you will have caching troubles.
By GET /rest/someresource?id>0 you filter your collection. So either the /rest/someresource?id>0 URI identifies a different filtered collection resource or it identifies the same collection resource, but with the filter query string your client indicates that it is waiting for a filtered representation of the resource and not the full representation. You can use the same by the minimal representation if you don't want to use the prefer header: GET /rest/someresource?return=minimal.
Note that if you want your client to query again, then you should send them hyperlinks in your response. The REST client must get the URIs (or URI templates) from these hyperlinks and it should not start to build URIs on its own.
The Box v2 REST API appears to contain methods that return "full objects". That is, they return all the fields and properties of the object requested with one "simple" call.
When trying the official .Net SDK, it appears that if you don't specify fields by name in the "FoldersManager" or "FilesManager" (for example), you get minimal details of the objects returned.
Is there a way to make the request return all fields/properties? I realize maybe ItemsCollection is one you'd want to retrieve specifically, but the rest should really be included in one call (like the REST capability).
Thanks for any ideas!
-AJ
If no fields are specified in the request, the default fields are returned in the response (ie. what the API decides is the most commonly used fields). If a field is specified the API returns all required fields along with the specified fields (usually type, id, and etag).
There is currently no simple flag that will return all fields as this would likely be abused out of convenience. The only way to return all fields is to manually specify all of the fields you are looking for. If using any of the official SDKs, these fields names can usually be found in the object models
HTH
So I've read that you cannot expect a default order when requesting json. I've seen this in action making a call to a little api that I built, that will return a jumbled, random order of elements each time I make a different call.
How does a site like ticketfly's api ( call it here http://www.ticketfly.com/api/events/upcoming.json?venueId=57 ) always ensure that the json returned is in a specific order?
The event ids always first, etc.
Thanks for shedding some light on the situation.
If you are in control of the endpoint API then you can hardcode the order in which you render the properties. Though I have to ask why exactly do you need the JSON properties in a particular order? You will finally be accessing the properties via there property names so the order in which they appear in the JSON should not ideally matter.
EDIT : Since your bosses insist on this (what can one say now?):
You can try and see if any of the following suits your needs:
Try hardcoding the display order in the view's representation. This means you will need to echo/print each property name explicitly in the view script. In PHP it could be something like echo $variable_representing_json["id"]; and so forth. Note that with this approach you needn't change the original JSON representation.
If you want the original JSON representation to be changed then depending on how you are doing the process it varies in difficulty:
If it's string concatenation that you are using to represent the json then hard-code the order in which the json properties get concatenated in the string.
In some languages the display order of properties is actually a representation of the order in which the properties were defined. In simple words if $var is an empty json representation then you should define $var["id"] = {some_val} first to display it first.
If you are using a framework for processing the JSON data it may have its own quirks irrespective of how you define your representation. In such cases you will have to try and see if you can work around the issue or if it gives any helper methods.