Zobrazení třídy v Django

hlasů
48

Django vyhlídky na funkci, což může být problém, pokud chcete změnit jen trochu funkčnosti. Ano, mohl bych mít milion klíčových argumentů a ještě více, pokud příkazy ve funkci, ale já myslel více objektově orientovaného přístupu k.

Například, mám stránku, která se zobrazí uživateli. Tato stránka je velmi podobné stránky, která zobrazuje skupinu, ale je to stále není tak podobné, stačí použít jiný model dat. Skupina má také členy atd ...

Jeden způsob, jak by bylo upozornit výhled na metody třídy a poté rozšířit tuto třídu. Má někdo pokusil tento přístup, nebo má jakýkoli jiný nápad?

Položena 03/08/2008 v 16:55
zdroj uživatelem
V jiných jazycích...                            


9 odpovědí

hlasů
41

Vytvořil jsem a používají své vlastní generických tříd zobrazení, definující __call__takže instance třídy je disponibilní. Moc se mi to líbí; zatímco Djangovo generické pohledy umožňují určitou přizpůsobení prostřednictvím klíčových argumentů, OO obecné názory (pokud je jejich chování rozdělen do několika samostatných metod), mohou mít mnohem více jemnozrnný přizpůsobení pomocí subclassing, který mi dovoluje opakuji hodně méně. (I omrzí přepisování stejný vytvořit / update pohled logický kdykoliv musím štípnout něco Djangovo generické názory nemusí zcela povolit).

Jsem vyslán nějaký kód na djangosnippets.org .

Jedinou skutečnou nevýhodu vidím, je šíření interních volání metod, které mohou mít vliv na výkon poněkud. Nemyslím si, že to je hodně z obavy; to je vzácné, že poprava Python kód bude vaše problémové místo výkonu v webové aplikace.

UPDATE : Djangovo vlastní generické pohledy jsou nyní class-based.

UPDATE : FWIW, změnil jsem názor na názory založenými na třídě, neboť tato odpověď byla napsána. Poté, co používal je ve velké míře na několika projektech, mám pocit, že má tendenci vést ke kódu, který je dostatečně dobře DRY psát, ale velmi těžké číst a udržovat později, protože funkce je rozložena tolika různých místech, a podtřídy jsou tak závislí na každé provedení detailu nadtřídy a mixins. Teď cítím, že TemplateResponse a prohlížet dekoratérů je lepší odpověď na rozkládání kódu zobrazení.

Odpovězeno 29/08/2008 v 05:29
zdroj uživatelem

hlasů
13

Musel jsem použít pohledy na bázi třídy, ale chtěl jsem, aby bylo možné použít úplný název třídy v mém URLconf aniž by bylo nutné vytvořit instanci třídy zobrazení před jeho použitím. To, co mi pomohlo byl překvapivě jednoduchý Metaclass:

class CallableViewClass(type):
    def __call__(cls, *args, **kwargs):
        if args and isinstance(args[0], HttpRequest):
            instance = super(CallableViewClass, cls).__call__()
            return instance.__call__(*args, **kwargs)
        else:
            instance = super(CallableViewClass, cls).__call__(*args, **kwargs)
            return instance


class View(object):
    __metaclass__ = CallableViewClass

    def __call__(self, request, *args, **kwargs):
        if hasattr(self, request.method):
            handler = getattr(self, request.method)
            if hasattr(handler, '__call__'):
                return handler(request, *args, **kwargs)
        return HttpResponseBadRequest('Method Not Allowed', status=405)

Nyní mohu obě instance třídy zobrazení a použít instance jako zobrazení funkcí, nebo mohu jen poukázat na můj URLconf mé třídě a mít Metaclass vytvoření instance (a volání) třídu pohledu na mě. To funguje kontrolou první argument __call__- pokud je to HttpRequest, musí být skutečné požadavek HTTP, protože to by bylo nesmyslné attept k vytvoření instance třídy pohled s HttpRequestinstance.

class MyView(View):
    def __init__(self, arg=None):
        self.arg = arg
    def GET(request):
        return HttpResponse(self.arg or 'no args provided')

@login_required
class MyOtherView(View):
    def POST(request):
        pass

# And all the following work as expected.
urlpatterns = patterns(''
    url(r'^myview1$', 'myapp.views.MyView', name='myview1'),
    url(r'^myview2$', myapp.views.MyView, name='myview2'),
    url(r'^myview3$', myapp.views.MyView('foobar'), name='myview3'),
    url(r'^myotherview$', 'myapp.views.MyOtherView', name='otherview'),
)

(I vysláni úryvek pro to na http://djangosnippets.org/snippets/2041/ )

Odpovězeno 27/05/2010 v 14:02
zdroj uživatelem

hlasů
9

Pokud jste prostě zobrazování dat z modelů, proč ne používat Django Generic Views ? Jsou navrženy tak, aby vám nechal snadno zobrazit data z modelu, aniž by museli napsat svůj vlastní názor, a tak o mapování paramaters URL k zobrazení, načítání dat, řešení případů EDGE, renderování výstupu atd

Odpovězeno 07/08/2008 v 11:44
zdroj uživatelem

hlasů
3

Vždy se můžete vytvořit třídu, přepsat __call__funkci a přejděte na soubor URL na instanci třídy. Můžete se podívat na FormWizard třídy vidět, jak se to dělá.

Odpovězeno 26/08/2008 v 12:38
zdroj uživatelem

hlasů
2

Pokud chcete udělat něco trochu složité, pomocí generických názory jsou způsob, jak jít. Jsou mnohem silnější než jejich název napovídá, a pokud jste právě zobrazení datového modelu generických výhled bude dělat svou práci.

Odpovězeno 11/08/2008 v 23:59
zdroj uživatelem

hlasů
2

Připadá mi, že se snažíte kombinovat věci, které by neměly být kombinovány. Pokud potřebujete provést zpracování různých podle vašeho názoru v závislosti na tom, zda se jedná o uživatele nebo skupiny objektů se snažíte prohlédnout pak byste měli použít dvě různé funkce zobrazení.

Na druhou stranu mohou existovat společné idiomy byste chtěli získat z vašich object_detail zobrazení typu ... možná byste mohli použít natěrač nebo jen pomocné funkce?

-Dan

Odpovězeno 03/08/2008 v 18:40
zdroj uživatelem

hlasů
1

Můžete použít Django Generic Views. Můžete snadno dosáhnout požadované funkce důkladné Django obecné pohledy

Odpovězeno 08/10/2014 v 06:53
zdroj uživatelem

hlasů
1

Generické zobrazení bude obvykle způsob, jak jít, ale nakonec máte možnost zpracovávat URL však budete chtít. FormWizard dělá věci v cestě třídy bázi, jak dělat některé aplikace pro REST API.

V podstatě se URL dostanete spoustu proměnných a pro poskytování volatelný, co splatných na požádání vám poskytne, je zcela na vás - standardní způsob je poskytnout funkce - ale nakonec Django klade žádné omezení na to, co děláte.

Souhlasím, že ještě několik příkladů toho, jak to udělat, by bylo dobré, FormWizard je pravděpodobně místem, kde začít ačkoli.

Odpovězeno 23/09/2008 v 20:05
zdroj uživatelem

hlasů
1

Chcete-li sdílet společnou funkčnost mezi stránkami doporučuji vám podívat se na vlastní značky. Jsou poměrně snadno vytvářet , a jsou velmi silné.

Také šablony mohou rozšířit z jiných šablon . To vám umožní mít základní šablonu pro nastavení rozvržení stránky a sdílet mezi ostatními šablonami, které vyplnit prázdná místa. Můžete vnořit šablony do libovolné hloubky; což vám umožní určit rozložení na samostatných skupin spojených stran na jednom místě.

Odpovězeno 26/08/2008 v 12:30
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more