pratiques Projets Django - Pages 183 et 184

Question

Sur les pages 183 et 184, il y a le code suivant:

def edit_snippet(request, snippet_id): 
    snippet = get_object_or_404(Snippet, pk=snippet_id) 
    if request.user.id != snippet.author.id: 
     return HttpResponseForbidden() 
    if request.method == 'POST': 
     form = SnippetForm(instance=snippet, data=request.POST) 
     if form.is_valid(): 
      snippet = form.save() 
      return HttpResponseRedirect(snippet.get_absolute_url()) 
    else: 
     form = SnippetForm(instance=snippet) 
    return render_to_response('cab/snippet_form.html',{ 'form': form, 'add': False }) 
edit_snippet = login_required(edit_snippet) 

Pourquoi est-il nécessaire d'ajouter un attribut de données ici:

form = SnippetForm(instance=snippet, data=request.POST) 

est-ce pas l'attribut d'instance est-il suffisant?

Si la méthode de requête n'est pas POST, cela peut être n'importe quoi, mais généralement c'est une méthode GET. Pourquoi n'y a-t-il aucun attribut de données dans ce cas? Pourquoi est-il nécessaire de prendre en compte d'autres méthodes de demande? Ne pourrait-on écrire simplement:

def edit_snippet(request, snippet_id): 
    snippet = get_object_or_404(Snippet, pk=snippet_id) 
    if request.user.id != snippet.author.id: 
     return HttpResponseForbidden() 
    if request.method == 'POST': 
     form = SnippetForm(instance=snippet, data=request.POST) 
     if form.is_valid(): 
      snippet = form.save() 
      return HttpResponseRedirect(snippet.get_absolute_url()) 
    return render_to_response('cab/snippet_form.html',{ 'form': form, 'add': False }) 
edit_snippet = login_required(edit_snippet) 

Il semble plus logique pour moi de ne pas laisser l'utilisateur de modifier son extrait si la méthode de requête n'est pas POST. Pouvez-vous m'expliquer ces points?

Answer 1

La fonction "edit_snippet" gère à la fois (1) la requête GET pour afficher un formulaire pour modifier l'objet, et (2) la requête POST suivante lorsque l'utilisateur enregistre ses modifications dans le formulaire. Dans cet esprit, il est logique que le cas de non-POST remplisse simplement le formulaire à partir de la variable "snippet" qui a été extraite de la base de données; Comme vous le remarquez, il n'y a pas de paramètre "data" dans ce cas. Ce qui était dans la base de données sera affiché à l'utilisateur. Cependant, lorsque l'utilisateur enregistre le formulaire, dans le cas POST, la variable "snippet" ne contient que ce qui a été extrait de la base de données. En définissant le paramètre "data" sur le contenu des champs de formulaire (request.POST) qui ont été affichés par l'utilisateur, vous autorisez le formulaire à (1) stocker les modifications de l'utilisateur de request.POST dans l'objet, puis (2) valider ces changements.

Answer 2

C'est la façon de faire de Django: la même vue est utilisée pour afficher le formulaire pour l'édition (GET), puis pour le valider (POST).

Voir cet exemple en docs:

Le modèle standard pour le traitement d'une forme en vue ressemble à ceci:

def contact(request): 
    if request.method == 'POST': # If the form has been submitted... 
     form = ContactForm(request.POST) # A form bound to the POST data 
     if form.is_valid(): # All validation rules pass 
      # Process the data in form.cleaned_data 
      # ... 
      return HttpResponseRedirect('/thanks/') # Redirect after POST 
    else: 
     form = ContactForm() # An unbound form 

    return render_to_response('contact.html', { 
     'form': form, 
    })