uitzicht klasse in Django

stemmen
48

Django oog wijst op een functie, die kan een probleem zijn als je wilt alleen een beetje van de functionaliteit te veranderen. Ja, ik kon miljoen trefwoord argumenten en hebben zelfs meer als uitspraken in de functie, maar ik dacht meer van een object-georiënteerde aanpak.

Bijvoorbeeld, ik heb een pagina die een gebruiker weergeeft. Deze pagina is zeer vergelijkbaar met pagina dat een groep wordt weergegeven, maar het is nog niet zo vergelijkbaar met gewoon gebruik maken van een ander datamodel. Groep heeft ook leden etc ...

Een manier zou zijn om een ​​mooi uitzicht op methoden van de klasse te wijzen en vervolgens uit te breiden die klasse. Heeft iemand geprobeerd deze aanpak of heeft een ander idee?

De vraag is gesteld op 03/08/2008 om 16:55
bron van user
In andere talen...                            


9 antwoorden

stemmen
2

Het klinkt alsof je probeert om dingen die niet mogen worden gecombineerd te combineren. Als u nodig hebt om verschillende verwerking doen naar uw mening, afhankelijk van of het een gebruiker of groep object dat u probeert te kijken dan moet je twee verschillende weergavefuncties te gebruiken.

Aan de andere kant kunnen er gemeenschappelijke uitdrukkingen u zou willen extraheren uit uw object_detail weergaven voor ... misschien kunt u een decorateur of gewoon helper functies gebruiken?

-Dan

antwoordde op 03/08/2008 om 18:40
bron van user

stemmen
9

Als je gewoon bent het weergeven van gegevens van modellen, waarom dan niet het gebruik van Django Generic Bekeken ? Ze zijn ontworpen om u gemakkelijk tonen de gegevens uit een model te laten zonder dat u uw eigen visie en dat soort dingen over het toewijzen URL paramaters van gedachten, het ophalen van gegevens, de behandeling van extreme gevallen, waardoor output, etc. schrijven

antwoordde op 07/08/2008 om 11:44
bron van user

stemmen
2

Tenzij je iets wilt een beetje ingewikkeld te doen, met behulp van de generieke uitzicht zijn de weg te gaan. Ze zijn veel krachtiger dan de naam al zegt, en als je net het weergeven van model data generieke uitzicht zal het werk doen.

antwoordde op 11/08/2008 om 23:59
bron van user

stemmen
1

Als u wilt om gemeenschappelijke functionaliteit tussen pagina's te delen Ik stel voor dat je kijkt naar aangepaste labels. Ze zijn vrij eenvoudig te maken , en zijn zeer krachtig.

Ook kunt sjablonen uitstrekken van andere sjablonen . Dit stelt u in staat om een basis template voor het opzetten van de lay-out van de pagina te hebben en dit te delen tussen andere sjablonen die de lege plekken in te vullen. U kunt nest sjablonen om elke diepte; zodat u de lay-out op aparte groepen van gerelateerde pagina's te geven op een plaats.

antwoordde op 26/08/2008 om 12:30
bron van user

stemmen
3

U kunt altijd een klasse, voorrang op de __call__functie en wijs de URL bestand naar een instantie van de klasse. U kunt een kijkje nemen op het FormWizard klas om te zien hoe dit wordt gedaan.

antwoordde op 26/08/2008 om 12:38
bron van user

stemmen
41

Ik heb gemaakt en gebruikt mijn eigen generieke uitzicht klassen, het definiëren __call__dus een instantie van de klasse is opvraagbaar. Ik vind het erg leuk; terwijl generieke uitzicht Django's mogelijk te maken een aantal aanpassingen door middel van keyword argumenten, kunnen OO generieke uitzicht (als hun gedrag wordt opgesplitst in een aantal afzonderlijke methoden) veel meer fijnkorrelig aanpassen via subclassing, waarmee ik herhaal mezelf een stuk minder hebben. (Ik moe van het herschrijven van hetzelfde te creëren / bijwerken view logica wanneer ik iets generieke standpunten Django's niet helemaal toe tweak).

Ik heb wat code bij geplaatst djangosnippets.org .

Het enige echte nadeel dat ik zie is de toename van het aantal interne methode oproepen, die van invloed kunnen de prestaties enigszins. Ik denk niet dat dit veel van een zorg; het is zeldzaam dat de uitvoering Python-code van uw prestaties bottleneck in een web app zou zijn.

UPDATE : Django's eigen generieke uitzichten zijn nu-klasse op basis.

UPDATE : FWIW, ik heb mijn mening veranderd over uitzicht op klasse gebaseerde sinds dit antwoord werd geschreven. Nadat ze op grote schaal gebruikt op een aantal projecten, heb ik het gevoel dat ze de neiging om te leiden tot een code die is geruststellend DRY om te schrijven, maar zeer moeilijk te lezen en later te handhaven, omdat de functionaliteit is verspreid over zo veel verschillende plaatsen, en subklassen zijn zo afhankelijk op elke implementatie detail van de superklasse en mixins. Ik voel me nu dat TemplateResponse en uitzicht decorateurs is een beter antwoord voor het ontleden uitzicht code.

antwoordde op 29/08/2008 om 05:29
bron van user

stemmen
1

Generic uitzicht zal meestal de weg te gaan, maar uiteindelijk ben je vrij om URL's te behandelen zoals u dat wilt. FormWizard doet dingen in een klasse gebaseerde manier, net als een aantal apps voor REST API's.

In principe met een URL die u krijgt een heleboel variabelen en plaats om een ​​callable te bieden, wat opvraagbare u is volledig aan jou - de standaard manier is om een ​​functie te geven - maar uiteindelijk Django legt geen beperkingen op wat je doet.

Ik ben het ermee eens dat een paar voorbeelden van hoe dit te doen zou goed zijn, FormWizard is waarschijnlijk de plek om al te beginnen.

antwoordde op 23/09/2008 om 20:05
bron van user

stemmen
13

Ik moest op basis van standpunten klasse te gebruiken, maar ik wilde in staat zijn om de volledige naam van de klasse in mijn URLconf gebruiken zonder steeds te hoeven de klas uitzicht concretiseren alvorens het te gebruiken. Wat hielp me was een verrassend eenvoudige 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)

Ik kan nu zowel instantiëren uitzicht klassen en het gebruik van de gevallen als view functies, of ik kan alleen maar wijzen mijn URLconf om mijn klas en hebben de metaclass instantiate (en bellen) de klasse uitzicht voor mij. Dit werkt door het controleren van het eerste argument om __call__- als het een HttpRequest, moet het een echte HTTP-verzoek, omdat het onzin zou zijn om attept aan het oog klasse instantiëren van een HttpRequestinstantie.

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'),
)

(Ik heb gepost een fragment voor deze op http://djangosnippets.org/snippets/2041/ )

antwoordde op 27/05/2010 om 14:02
bron van user

stemmen
1

U kunt de Django Generic Views gebruiken. U kunt gemakkelijk bereiken van de gewenste functionaliteit grondige Django generieke Bekeken

antwoordde op 08/10/2014 om 06:53
bron van user

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