| Pyramid | |
|---|---|
| Sorts | Webbapplikationsramverk _ |
| Utvecklaren | Ben Bangert, James Gardner |
| Skrivet i | Pytonorm |
| Operativ system | Cross plattform |
| Första upplagan | december 2010 _ |
| senaste versionen | |
| Licens | BSD |
| Hemsida | pylonsproject.com |
Pyramid ( engelsk pyramid - pyramid) är ett mjukvaruramverk (ramverk) för att utveckla webbapplikationer med öppen källkod skrivna i Python som en del av Pylons- projektet [2] .
Skapandet av Pyramid påverkades av ramverk som Zope , Pylons och Django . Pyramidkoden utvecklades i repoze.bfg-projektet, och namnet ändrades som ett resultat av sammanslagningen av BFG- och Pylons-projekten. [3]
Pyramiddesignen är baserad på följande principer [4] :
Till försvar för sin design skrev författarna till Pyramid ett ganska stort dokument, som är avsett att skingra myterna om ramverket. Till exempel följs kritik mot MVC- modellen i Pyramid av en detaljerad förklaring om att MVC är "långsökt" för webbapplikationer. Följande citat [5] kännetecknar väl inställningen till terminologi i Pyramid:
Vi tror att det bara finns två saker: resurser (resurs) och synpunkter (vy). Resursträdet representerar webbplatsens struktur och vyn representerar resursen. Mallar _
i verkligheten bara en implementeringsdetalj av någon vy: strängt taget krävs de inte, och vyn kan returnera ett svar (svar) utan dem. Det finns ingen "kontroller" (kontroller): den existerar helt enkelt inte. En "modell" är antingen ett resursträd eller en "domänmodell" (som SQLAlchemy- modellen ), som inte alls ingår i ramverket. Det förefaller oss som om vår terminologi är mer rimlig med tanke på webbteknologiernas befintliga begränsningar.
Originaltext (engelska)[ visaDölj]...[Vi] säger att det finns två saker: resurser och synpunkter. Resursträdet representerar en webbplatsstruktur, vyn presenterar en resurs. Mallarna är egentligen bara en implementeringsdetalj av en given vy: en vy behöver inte en mall för att returnera ett svar. Det finns ingen "kontroller": den finns bara inte. "Modellen" representeras antingen av resursträdet eller av en "domänmodell" (som en SQLAlchemy-modell) som är helt separat från ramverket. Detta förefaller oss som mer rimlig terminologi, med tanke på webbens nuvarande begränsningar.
De främsta fördelarna med Pyramid är [4] :
Även om det inte är svårt att skriva en Pyramid-applikation (projekt) från grunden, har Pyramid verktygen för att initiera koden för en ny applikation enligt den valda mallen, eller, i Pyramid-terminologi , byggnadsställningar [ 7 ] . Till exempel inkluderar distributionen ramstrukturer för projekt som använder ZODB eller SQLAlchemy .
Ett projekt är en katalog som innehåller minst ett Python -paket .
Typisk katalogstruktur för ett litet projekt:
MyProject/ | -- CHANGES.txt | -- development.ini | -- MANIFEST.in | -- mittprojekt | | -- __init__.py | | -- statisk | | | -- favicon.ico | | | -- logo.png | | ` -- pylons.css | | -- mallar | | ` -- mytemplate.pt | | -- tests.py | ` -- views.py | -- production.ini | -- README.txt | -- setup.cfg ` -- setup.pyOvanstående struktur, som följer av dokumentationen, bör inte ändras mycket, eftersom detta kan hindra andra utvecklare från att snabbt navigera i projektkoden [8] . Ett växande projekt kan dock kräva vissa förändringar. Till exempel kan vyer, modeller (om de används) och tester delas upp i moduler och överföras till underkatalogerna för vyer, modeller och tester (kom ihåg att förse dem med en fil __init__.py).
Projektet kan till exempel vara i en buildout (säg i src-katalogen) som sätter ihop alla nödvändiga komponenter. Det är inte nödvändigt att ett pyramidprojekt består av ett enda paket. Storleken på projektet begränsas endast av utvecklarnas tillräckliga kunskap om Pyramids kapacitet [9] .
Pyramid kan fungera med vilken WSGI -server som helst. Projekt skapade från förbyggda ramverk använder Waitress-servern.
Varje inkommande begäran till Pyramid-applikationsservern (begäran) måste hitta en vy (vy), som kommer att behandla den.
I Pyramid finns det två grundläggande tillvägagångssätt för att hitta rätt sort för den begäran som behandlas: baserat på matchning (matchning), som i de flesta liknande ramverk, och bypass (traversal), som i Zope . Dessutom kan båda metoderna framgångsrikt kombineras i en applikation.
Det enklaste exemplet med att ställa in en rutt (lånat från dokumentationen):
# Här är config en instans av pyramid.config.Configurator config . add_route ( 'idea' , 'site/ {id} ' ) config . add_view ( 'mypackage.views.site_view' , route_name = 'idé' )Användningen av bypass illustreras bäst med ett litet exempel:
från wsgiref.simple_server import make_server från pyramid.config import Konfigurator från pyramid.response import Svar # Klassen för någon resursklass Resource ( dict ): pass # Resursträd (hårdkodat) i rotfabriken def get_root ( förfrågan ): returnera Resurs ({ 'a' : Resurs ({ 'b' : Resurs ({ 'c' : Resurs ()})})}) # View-to-invoke som kan visa resursresurs (i sammanhang) def hello_world_of_resources ( kontext , begäran ): output = "Resurs och dess underordnade: % s " % kontextretur Svar ( output ) om __name__ == '__main__' : config = Konfigurator ( root_factory = get_root ) config . add_view ( hello_world_of_resources , context = Resurs ) app = config . make_wsgi_app () server = make_server ( '0.0.0.0' , 8080 , app ) server . serve_forever ()I det här exemplet är traverseringshierarkin hårdkodad i metoden get_rootmed hjälp av kapslade ordböcker, medan verkliga applikationer måste bestämma nödvändig åtkomst med nycklar (metoden __getitem__hjälper till att organisera sådan åtkomst). Koden innehåller också en root factory , från vilken korsningen av noderna (noden) i resursträdet faktiskt börjar. Vyn som kan anropas representeras av hello_world_of_resources. För att uttrycka det enkelt, baserat på webbadressen till förfrågan, korsar Pyramid hierarkin och hittar resursen och tillämpar den "bästa" synen för att ringa på den (i vårt exempel är den den enda). [tio]
Att konfigurera en applikation, det vill säga ange inställningar som påverkar dess funktion, kan göras i Pyramid på två sätt: imperativ och deklarativ.
Imperativ konfiguration utförs genom att anropa konfiguratorns metoder precis innan applikationen startar.
Deklarativ konfiguration ges av vydekoratörer. Före lansering "skannas" applikationen efter konfigurationsparametrar med hjälp scan()av konfiguratormetoden. Exempel från dokumentation:
från pyramid.response import Svar från pyramid.view import view_config @view_config ( namn = 'hej' , request_method = 'GET' ) def hej ( förfrågan ): returnera Svar ( 'Hej' )Båda konfigurationsmetoderna är helt utbytbara. [elva]
De som vill kan använda ZCML för att konfigurera genom att installera lämpligt paket.
I Pyramid kan du använda olika motorer för att generera HTML. Så, Chameleon och Mako ingår i leveransen. [12] Utöver dem kan du inkludera andra, till exempel Jinja2 .
Att arbeta med formulär kan till exempel göras med hjälp av treenigheten Pepparkorn-Durkslag-Deform.
En av de enklaste applikationerna för Pyramid [13] :
från wsgiref.simple_server import make_server från pyramid.config import Konfigurator från pyramid.response import Svar def hello_world ( request ): return Response ( 'Hej %(name)s !' % request . matchdict ) if __name__ == '__main__' : config = Configurator () config . add_route ( 'hej' , '/hello/ {namn} ' ) config . add_view ( hello_world , route_name = 'hej' ) app = config . make_wsgi_app () server = make_server ( '0.0.0.0' , 8080 , app ) server . serve_forever ()| Pytonorm | |
|---|---|
| gemenskap | |
| Genomföranden | |
| Övrig |
|