| Pyramide | |
|---|---|
| Type | Webapplikationsramme _ |
| Udvikler | Ben Bangert, James Gardner |
| Skrevet i | Python |
| Operativ system | Cross platform |
| Første udgave | december 2010 _ |
| nyeste version | |
| Licens | BSD |
| Internet side | pylonsproject.com |
Pyramid ( engelsk pyramid - pyramid) er en softwareramme (ramme) til udvikling af open source webapplikationer skrevet i Python som en del af Pylons -projektet [2] .
Skabelsen af Pyramid var påvirket af rammer som Zope , Pylons og Django . Pyramidekoden blev udviklet i repoze.bfg-projektet, og navnet blev ændret som følge af sammenlægningen af BFG- og Pylons-projekterne. [3]
Pyramidedesignet er baseret på følgende principper [4] :
Til forsvar for deres design skrev forfatterne af Pyramid et ret stort dokument, som har til formål at aflive myterne om rammen. For eksempel efterfølges kritik af MVC -modellen i Pyramid af en detaljeret forklaring om, at MVC er "langt ude" til webapplikationer. Følgende citat [5] karakteriserer godt tilgangen til terminologi i Pyramid:
Vi mener, at der kun er to ting: ressourcer (ressource) og synspunkter (udsigt). Ressourcetræet repræsenterer webstedets struktur, og visningen repræsenterer ressourcen. Skabeloner _
i virkeligheden kun en implementeringsdetalje af en eller anden visning: strengt taget er de ikke påkrævet, og visningen kan returnere et svar (svar) uden dem. Der er ingen "controller" (controller): den eksisterer simpelthen ikke. En "model" er enten et ressourcetræ eller en "domænemodel" (såsom SQLAlchemy- modellen ), som slet ikke er en del af rammen. Det forekommer os, at vores terminologi er mere fornuftig i betragtning af de eksisterende begrænsninger af webteknologier.
Originaltekst (engelsk)[ Visskjule]...[Vi] siger, at der er to ting: ressourcer og synspunkter. Ressourcetræet repræsenterer en webstedsstruktur, visningen præsenterer en ressource. Skabelonerne er egentlig kun en implementeringsdetalje af enhver given visning: en visning behøver ikke en skabelon for at returnere et svar. Der er ingen "controller": den eksisterer bare ikke. "Modellen" er enten repræsenteret af ressourcetræet eller af en "domænemodel" (som en SQLAlchemy-model), der er helt adskilt fra rammen. Dette forekommer os som en mere fornuftig terminologi i betragtning af de nuværende begrænsninger på nettet.
De vigtigste fordele ved Pyramid er [4] :
Selvom det ikke er svært at skrive en Pyramid-applikation (projekt) fra bunden, har Pyramid værktøjerne til at initialisere koden for en ny applikation i henhold til den valgte skabelon, eller, i Pyramid-terminologi , stilladser [ 7 ] . For eksempel inkluderer distributionen rammestrukturer for projekter, der bruger ZODB eller SQLAlchemy .
Et projekt er en mappe, der indeholder mindst én Python -pakke .
Typisk mappestruktur for et lille projekt:
Mit Projekt/ | -- CHANGES.txt | -- development.ini | -- MANIFEST.in | -- mitprojekt | | -- __init__.py | | -- statisk | | | -- favicon.ico | | | -- logo.png | | ` -- pylons.css | | -- skabeloner | | ` -- mytemplate.pt | | -- tests.py | ` -- views.py | -- production.ini | -- README.txt | -- setup.cfg ` -- setup.pyOvenstående struktur, som følger af dokumentationen, bør ikke ændres meget, da dette kan forhindre andre udviklere i hurtigt at navigere i projektkoden [8] . Et projekt i vækst kan dog kræve nogle ændringer. For eksempel kan visninger, modeller (hvis de bruges) og tests opdeles i moduler og overføres til henholdsvis visninger, modeller og testundermapper (husk at forsyne dem med en fil __init__.py).
Projektet kan for eksempel være i en buildout (f.eks. i src-mappen), der sætter alle de nødvendige komponenter sammen. Det er ikke nødvendigt, at et pyramideprojekt består af en enkelt pakke. Projektets størrelse er kun begrænset af udviklernes tilstrækkelige viden om Pyramid's muligheder [9] .
Pyramid kan arbejde med enhver WSGI -server. Projekter oprettet fra forudbyggede rammer bruger Waitress-serveren.
Hver indkommende anmodning til Pyramid-applikationsserveren (anmodning) skal finde en visning (visning), som vil behandle den.
I Pyramid er der to grundlæggende tilgange til at finde den rigtige type til den anmodning, der behandles: baseret på matching (matching), som i de fleste lignende rammer, og bypass (traversal), som i Zope . Derudover kan begge tilgange med succes kombineres i én ansøgning.
Det enkleste eksempel med indstilling af en rute (lånt fra dokumentationen):
# Her er config en forekomst af pyramid.config.Configurator config . add_route ( 'idea' , 'site/ {id} ' ) config . add_view ( 'mypackage.views.site_view' , rutenavn = 'ide' )Brugen af bypass illustreres bedst med et lille eksempel:
fra wsgiref.simple_server import make_server fra pyramid.config import Konfigurator fra pyramid.response import Svar # Klassen for en eller anden ressourceklasse Resource ( dict ) : pass # Ressourcetræ (hardkodet) i rodfabrikken def get_root ( anmodning ): returner ressource ({ 'a' : ressource ({ 'b' : ressource ({ 'c' : ressource ()})})}) # View-to-invoke, der kan vise ressourceressource (i kontekst) def hello_world_of_resources ( kontekst , anmodning ): output = "Ressource og dens børn: %s " % kontekst retur Svar ( output ) if __name__ == '__main__' : config = Konfigurator ( root_factory = get_root ) config . add_view ( hello_world_of_resources , context = Ressource ) app = config . make_wsgi_app () server = make_server ( '0.0.0.0' , 8080 , app ) server . tjene_for evigt ()I dette eksempel er traversalhierarkiet hårdkodet ind i metoden get_rootved hjælp af indlejrede ordbøger, mens rigtige applikationer skal bestemme den nødvendige adgang med nøgler (metoden __getitem__hjælper med at organisere en sådan adgang). Koden indeholder også en rodfabrik , hvorfra gennemkørslen af noderne (noden) i ressourcetræet faktisk begynder. Visningen , der kan kaldes, er repræsenteret af hello_world_of_resources. For at sige det enkelt, baseret på URL'en på anmodningen, krydser Pyramid hierarkiet og finder ressourcen og anvender den "bedste" visning for at ringe til den (i vores eksempel er den den eneste). [ti]
Konfiguration af et program, det vil sige angivelse af indstillinger, der påvirker dets drift, kan gøres i Pyramid på to måder: imperativ og deklarativ.
Imperativ konfiguration udføres ved at kalde konfiguratorens metoder lige før applikationen starter.
Deklarativ konfiguration er givet af udsigtsdekoratører. Inden lanceringen "scannes" applikationen for konfigurationsparametre ved hjælp scan()af konfiguratormetoden. Eksempel fra dokumentation:
fra pyramid.response import Svar fra pyramid.view import view_config @view_config ( navn = 'hej' , request_method = 'GET' ) def hej ( anmodning ): returnere svar ( 'Hej' )Begge konfigurationsmetoder er fuldstændigt udskiftelige. [elleve]
De, der ønsker det, kan bruge ZCML til at konfigurere ved at installere den passende pakke.
I Pyramid kan du bruge forskellige motorer til at generere HTML. Så Chameleon og Mako er inkluderet i leveringen. [12] Ud over dem kan du inkludere andre, såsom Jinja2 .
Arbejdet med formularer kan for eksempel gøres ved at bruge Peberkorn-Colander-Deform treenigheden.
En af de enkleste applikationer til Pyramid [13] :
fra wsgiref.simple_server import make_server fra pyramid.config import Konfigurator fra pyramid.response import Svar def hello_world ( request ): return Response ( 'Hej %(name)s !' % request . matchdict ) if __name__ == '__main__' : config = Konfigurator () config . add_route ( 'hej' , '/hello/ {navn} ' ) config . add_view ( hello_world , route_name = 'hej' ) app = config . make_wsgi_app () server = make_server ( '0.0.0.0' , 8080 , app ) server . tjene_for evigt ()| Python | |
|---|---|
| Fællesskab | |
| Implementeringer | |
| Andet |
|