2013-05-29 12 views
5

Przede wszystkim chcę, aby oba widoki używały dokładnie tego samego adresu URL, ponieważ nie chcę, aby mój URLConf był bardziej skomplikowany. Chcę mieć osobne widoki dla GET i POST, aby mój kod był czystszy. Kod jest coś takiego:Jak pisać osobne widoki dla GET i POST

def view2 (request): 
    # handle POST request, possibly a ajax one 
    return HTTPRESPONSE(json_data, mimetype="Application/JSON") 

def view1 (request): 
    if method == POST: 
     view2(request) 
     # What should I return here??? 

    else: 
     # handle GET 
     return render(request, template, context) 

Moje pytanie dotyczy linii # What should I return here???. Jeśli nie umieścić tam zwrot, występuje błąd:

nie wraca odpowiedzi HTTP

Ale ja już powrócić odpowiedzi HTTP w View2. Jak mogę to sprawić?

+0

Powinieneś 'powrotnej view2 (żądanie) '. View2 zwrócił swój wynik do wywołującego (który jest 'view1'), ale wywołujący również musi go zwrócić. – J0HN

Odpowiedz

4

Trzeba powrócić wyniki View2:

def view1 (request): 
    if request.method == 'POST': 
     return view2(request) 
    else: 
     # handle GET 
     return render(request, template, context) 
+0

Aha, dziękuję! – Philip007

6

Inną, prawdopodobnie nieco bardziej przejrzysty sposób będzie za pomocą class-based views

from django.views.generic import TemplateView 

class View1(TemplateView): 
    def get(self, request, *args, **kwargs): 
     """handle get request here""" 

    def post(self, request, *args, **kwargs): 
     """handle post request here""" 

    def head(self, request, *args, **kwargs): 
     """handle head request here. Yes, you can handle any kind of requests, not just get and post""" 

Oczywiście można dodać wspólnych metod, __init__ (co jest bezużyteczne, chyba że jesteś pewien, co robisz), zastosuj login_required (zobacz this SO question) i prawie wszystko, co możesz zrobić z widokami django (np. zastosuj oprogramowanie pośrednie, uprawnienia, itp.) i klas Pythona (np. dziedziczenia, metaclasses/dekoratorzy, etc.)

Ponadto, jest tam cała masa generycznego widzenia opartego klasy pochodzące z Django do rozwiązywania wspólnych takimi sytuacjami stronie listy, strony szczegółów, Edycja strony itp

+1

Naprawdę podoba mi się ta odpowiedź. Dzięki temu kod jest bardzo przejrzysty i łatwy w utrzymaniu. – Dunatotatos