In inglese semplice, quali sono le viste generiche di Django?

Question

I primi due paragrafi di questa pagina spiegano che viste generici sono tenuti a rendere la mia vita più facile, meno monotono, e mi renderà più attraente per le donne (ho fatto che l'ultimo):

https://docs.djangoproject.com/en/1.4/topics/generic-views/

I Sono tutto per migliorare la mia vita, ma cosa fanno effettivamente le viste generiche? Sembra che vengano lanciate molte parole d'ordine che confondono più di quanto spieghino.

Le viste generiche sono simili al ponteggio in Ruby on Rails? L'ultimo punto elenco nell'introduzione sembra indicare questo. È una dichiarazione accurata?

Answer 1

Le viste generiche di Django sono solo funzioni di visualizzazione (normali vecchie funzioni python) che fanno cose che sono molto comuni nelle applicazioni web.

A seconda del tipo di app che si sta creando, possono evitare di scrivere molte viste molto semplici.

Ad esempio, la vista generica direct_to_template visualizza semplicemente un modello con RequestContext (il che significa che il modello ha accesso alle informazioni sulla richiesta, come l'utente corrente, ecc.).

Come semplice esempio, si può andare da scrivere cose del genere:

# urls.py 
url('^some-url/$', some_view) 

# views.py 
def some_view(request): 
    return render_to_response('template_name.html', context_instance=RequestContext(request)) 

A proprio questo:

# urls.py 
url('^some-url/$', direct_to_template, {'template': 'template_name.html'}) 

# views.py doesn't need any code for this view anymore 

Ci sono anche più complicate vista generici per le azioni comuni come "mostrando un elenco di modelli "o" aggiunta di un modello al db ".

Inoltre, poiché le viste generiche sono solo funzioni, è possibile chiamarle all'interno delle proprie funzioni di visualizzazione per eseguire "la maggior parte del lavoro", quando è necessario qualcosa che sia leggermente diverso dai casi generici.

Answer 2

Per rispondere alla seconda domanda: no, le viste generiche non sono correlate allo scaffolding in RoR. L'impalcatura, come indica il nome, è simile alla generazione del codice. Le viste generiche sono qualcos'altro.

Il mio utilizzo principale della vista generica è una sostituzione di livello superiore delle funzioni base di render_to_response. Questo è come si potrebbe scrivere una vista semplice con render_to_response:

def my_view(request): 
    return render_to_response('my_template.html') 

Ma questo è molto semplice! Ad esempio il modello non avrà accesso al contesto della richiesta, a meno che non lo passi esplicitamente.

ho quindi preferisco usare una visione generica invece:

def my_view(request): 
    return direct_to_template(request, template='my_template.html') 

Ora il contesto di richiesta sarà trasmessa! E questo è solo un inizio. Le viste generiche sono utili quando si desidera visualizzare elenchi o viste di dettaglio, ad esempio. Gestiranno l'interrogazione del database e invieranno messaggi all'utente, tra l'altro.

Le viste generiche sono quindi funzioni di alto livello che consentono di creare una risposta da una vista.

Answer 3

Le visualizzazioni generiche consentono di scrivere codice molto più breve.

Confronta:

from django.http import HttpResponse, HttpResponseRedirect, Http404 
from django.shortcuts import render_to_response, get_object_or_404, redirect 
from myapp.models import Context 

def edit(request, item_id): 
    object = get_object_or_404(Context, pk=item_id) 

    if request.method == 'POST': 
     form = ContextForm(request.POST, instance=object) 
     if form.is_valid(): 
      form.save() 
      return redirect('myapp-context-index') 
    else: 
     form = ContextForm(instance=object) 

    return render_to_response("myapp/context/edit.html", {'object': object, 'form': form}) 

con:

from django.core import urlresolvers 
from django.views.generic.create_update import update_object 
from myapp.models import Context 

def edit(request, item_id):  
    return update_object(request, 
     object_id=item_id,    
     form_class=ContextForm,    
     template_name="myapp/context/edit.html", 
     post_save_redirect=urlresolvers.reverse("myapp-context-index") 
    ) 

come le vostre opinioni normali, sono funzioni normali. È possibile configurare completamente la vista in URLconf, se lo si desidera, grazie a questo aspetto mi sembra un po 'più chiaro.

come bonus, si ottiene anche:

• Entra controlli di autenticazione (passa il login_required=True)
• messaggio di stato successo da django.contrib.messages.
• Meno codice per verificare la presenza di errori.
• Un valore predefinito ModelForm quando si fornisce un parametro model anziché form_class.

Il template_name ha un valore predefinito "appname/model_form.html", ma è un po 'troppo per me.

---

Ecco la classe form entrambi condividono:

class ContextForm(forms.ModelForm): 
    """The form for a context""" 
    class Meta: 
     model = Context 
     exclude = ('collection',) 

    def save(self, commit=True): 
     """Overwritten save to force collection_id to a value""" 
     model = super(ContextForm, self).save(commit=False) 
     model.collection_id = 1 
     if commit: 
      model.save() 
     return model