Når du bygger en bakside for et nettsted eller en tjeneste, til og med en som virker beskjeden ved første øyekast, kan du raskt oppdage at det er alt annet enn. Selv et "enkelt" nettsted viser seg å være en bikube av kompleksitet. Brukeradministrasjon, datadesign, skjemainnleveringer, sikkerhet, - å implementere alt dette for hånd blir kjedelig.
Når du vet at du trenger alt pluss kjøkkenvasken, for de store webprosjektene, er det best å vende deg til et rammeverk som følger med batterier (og ladere) inkludert. Her er fem tunge nettrammer for Python som kommer med alt du trenger for å bygge robuste webapplikasjoner og deretter noen.
CubicWeb
CubicWeb blir fakturert som "et semantisk rammeverk for webapplikasjoner som favoriserer gjenbruk og objektorientert design." Det er et spennende system - som bemerket av Rick Grehan da han gjennomgikk det for tilbake i 2011 - som understreker bruken av abstraksjoner og gjenbrukbare byggesteiner med kode kalt "kuber". Faktisk kan CubicWeb være for abstrakt eller idiosynkratisk for noen utviklere, og dens utviklingshastighet og funksjoner setter andre rammer.
Kuber er programvarekomponenter som har et skjema (datamodell), enheter (programmeringslogikk) og visninger. Ved å samle flere kuber, som hver utfører sin egen oppgave, kan du komponere programvareapplikasjoner ved å bruke din egen kode og andres kode.
I sin kjerne tilbyr CubicWeb grunnleggende stillas som brukes av alle web-apper: et "lager" for datatilkoblinger og lagring; en “nettmotor” for grunnleggende HTTP-forespørsel / respons og CRUD-handlinger; og et skjema for modellering av data. Alt dette er beskrevet i Python-klassedefinisjoner.
For å sette opp og administrere forekomster av CubicWeb, jobber du med et kommandolinjeverktøy som ligner det som ble brukt for Django. Et innebygd malsystem lar deg programmere generere HTML-utdata. Du kan også bruke en kube som gir verktøy for web-UI, som for eksempel for Bootstrap HTML-rammeverket.
Selv om CubicWeb støtter Python 3 (siden versjon 3.23), ser det ikke ut til å bruke Python 3s native async-funksjonalitet. En rundkjøringsmåte å inkludere async ville være å bruke cubicweb.pyramid-modulen til å bruke Pyramid-rammeverket som webserveren, og tegne på en gaffel Pyramid som bruker async-konstruksjoner. Det er også mulig å utføre oppgaver asynkront med kuben-kuben. Men alt mer greit virker utilgjengelig for nå.
For å hente eller manipulere vedvarende data i en CubicWeb-app, bruker du Relation Query Language (RQL), som bruker vagt SQL-lignende syntaks, men er mønstret etter W3Cs SparQL. CubicWebs begrunnelse for dette er igjen abstraksjon: RQL gir en svært frakoblet rute for å knytte ulike datakilder sammen.
Fordi CubicWeb har mange avhengigheter, er det best å bruke det pip install å hente dem alle. Du må kanskje også utføre en viss mengde manuell tilpasning av lokalmiljøet. Dette er i motsetning til andre rammer der du kjører pip install eller å slippe rammekoden i en undermappe til et annet prosjekt er alt som kreves. Eller du kan bruke en Docker-container for å få ting til å kjøre.
CubicWeb refererer til den lange dokumentasjonen som "boka". Forfatterne av boka har tatt seg tid til å forklare CubicWebs uvanlige tilnærming, demonstrere hvordan man bygger noen grunnleggende applikasjoner, inkluderer API-referanser, og generelt går ut av deres måte å være spesifikk.
CubicWeb er fortsatt under aktiv, hvis sakte, utvikling. Planene for CubicWeb 4.0 er blitt overveid siden 2012, men det er ennå ikke tilbudt noen tidslinje for å levere den.
Django
I tiåret og endringen siden Django første gang dukket opp, har det blitt et av Pythons mest utbredte rammer for å lage webapplikasjoner. Django kommer med stort sett alle batterier du trenger, noe som gjør det mer egnet for å bygge store applikasjoner enn små.
Django brukte mange år på å sitte på versjon 1.x. Da Django 2.0 ankom i slutten av 2017, falt den kompatibilitet med Python 2 til fordel for Python 3.4 og nyere. Django 3.0, utgitt i desember 2019, krever Python 3.6 eller bedre, og legger til støtte for den nye asynkrone ASGI-standarden for Python-webapplikasjoner.
En sentral del av Djangos appell er distribusjonshastighet. Fordi Django inneholder så mange brikker du trenger for å utvikle den gjennomsnittlige webapplikasjonen, kan du komme deg raskt. Ruting, URL-parsing, databasetilkobling inkludert en ORM (objekt-relasjonskartlegger), skjemavalidering, angrepsbeskyttelse og mal er alt innebygd.
Du finner byggesteiner for de vanligste scenariene for nettapplikasjoner. Brukeradministrasjon finnes for eksempel på de fleste nettsteder, så Django tilbyr det som et standardelement. I stedet for å måtte lage ditt eget system for sporing av brukerkontoer, økter, passord, pålogginger / pålogginger, administratortillatelser og så videre, gir Django disse funksjonene naturlig. De kan brukes som de er eller utvides for å omfatte nye brukstilfeller med minimalt med arbeid.
Django har sunne og trygge standarder som hjelper med å beskytte webapplikasjonen din mot angrep. Når du plasserer en variabel i en sidemal, for eksempel en streng med HTML eller JavaScript, blir ikke innholdet gjengitt bokstavelig med mindre du eksplisitt angir forekomsten av variabelen som sikker. Dette eliminerer i seg selv mange vanlige skriptsaker på tvers av nettsteder. Hvis du vil utføre skjemavalidering, kan du bruke alt fra enkel CSRF-beskyttelse til fullstendige felt-for-felt-valideringsmekanismer som returnerer detaljert feilmelding.
En funksjon som er like rik og bred som Django, ville ikke vært mye bra uten robust dokumentasjon som følger med. Django-dokumentasjonen driller seg inn i alle aspekter av rammeverket fra flere vinkler. Arbeide med Python 3 eller andre smaker av språket, gjøre sikkerhetsrett, implementere vanlige webapplikasjonskomponenter (som økter eller paginering), generere nettstedskart - de er alle dekket. API-ene for hvert lag i applikasjonen - modell, visning og mal - er også beskrevet i detalj.
Med stor kraft kommer imidlertid stor kompleksitet. Django-applikasjoner har rykte for å være topptunge, fulle av mange bevegelige deler. Selv en enkel Django-app krever en hel del konfigurasjon for å komme i gang. Hvis målet ditt er å gjøre litt mer enn å sette opp et par enkle REST-sluttpunkter, er Django nesten helt sikkert overkill.
Django har også sine særegenheter. For eksempel kan sidemaler ikke bruke callables. Eksempel: Du kan bestå {{user.name}} som en komponent i en mal, men ikke {{user.get_name ()}}. Det er en av måtene Django sørger for at maler ikke utilsiktet skyter deg i foten, men disse begrensningene kan være skurrende hvis du ikke er forberedt på dem. Mens det er løsninger, har de en tendens til å ta en toll på ytelsen.
Fra og med versjon 3.0 har Django lagt til støtte for asynkrone visninger. Dessverre er det ennå ikke støtte for asynkronisering i andre deler av Django-stakken, som ORM. Men du kan distribuere Django ved hjelp av ASGI for å dra full nytte av asynkroniseringsvisninger.
Web2py
I verden av Ruby-programmering er Ruby on Rails de facto nettrammeverket. DePaul University informatikkprofessor Massimo Di Pierro ble inspirert av Rails til å lage et nettrammeverk i Python som var like enkelt å sette opp og bruke. Resultatet er Web2py.
Web2pys største attraksjon er det innebygde utviklingsmiljøet. Når du konfigurerer en forekomst av Web2py, får du et webgrensesnitt, i hovedsak en online Python-applikasjonseditor, der du kan konfigurere appens komponenter. Dette betyr vanligvis å lage modeller, visninger og kontrollere, hver beskrevet via Python-moduler eller HTML-maler. Noen få eksempler på apper kommer med Web2py ut av esken. Du kan ta dem fra hverandre for å se hvordan de fungerer, eller utnytte dem som startmaler for å lage dine egne apper.
Utviklere distribuerer vanligvis Web2py ved å laste ned kildekoden og bygge videre på den. Men for mindre tekniske brukere på Windows eller MacOS, tilbyr skaperne av Web2py versjoner som egentlig er frittstående servere. Last ned, pakk ut og kjør en av disse versjonene, så får du en lokal webserver med en forhåndskonfigurert kopi av Web2py innebygd. Dette er en fin måte å få et bein på å lage en Web2py-app, som deretter kan distribueres andre steder etter behov.
Web2pys nettgrensesnitt ble bygget med Bootstrap 4, så det er lett å se for og lett å navigere. Nettleseredigereren er ingen erstatning for en fullverdig IDE, men den er utstyrt med nyttige hjelpemidler som linjenummerering og Python-syntaksmarkering (inkludert automatisk innrykk). Også inkludert er et raskt webgrensesnitt til Python-skallet, slik at du kan samhandle med Web2py fra kommandolinjen - en fin konsesjon til eksperter.
Dataabstraheringssystemet som brukes i Web2py fungerer litt annerledes enn Djangos ORM og andre ORMer inspirert av det (som Peewee). Disse systemene bruker Python-klasser for å definere modeller, mens Web2py bruker konstruktorfunksjoner som definere_tabell for å instantiere modeller. Forskjellene vil sannsynligvis bare skjære hvis du er vant til den andre veien; de burde ikke lure nykommere. Det er ikke sannsynlig at du vil ha noen problemer med å koble Web2py til en dataleverandør, da den snakker med nesten alle større eksisterende databaser.
En virkelig nyttig databaserelatert funksjon i Web2py er muligheten til å generere et diagram over modellene, slik at du kan visualisere hvordan modellene dine forholder seg til hverandre. Du må imidlertid installere PyGraphviz-biblioteket for å aktivere den funksjonen.
Web2py leverer mange andre profesjonelle komponenter: internasjonaliseringsfunksjoner, flere hurtigbuffermetoder, tilgangskontroll og autorisasjon, og til og med fronteffekter (for eksempel en datovelger i skjemaer) via integrert støtte for jQuery og AJAX. Kroker for ekstern og intern mellomvare er også inkludert, selv om du ikke har lov til å bruke mellomvare for å erstatte kjerne Web2py-funksjoner. Imidlertid er det foreløpig ingen eksplisitt bruk av Pythons async-funksjonalitet i Web2py, selv om det er en planlegger for håndtering av langvarige oppgaver.
Det er ikke rart at Web2pys dokumentasjon blir referert til som "boka". For det første dekker det en svimlende mengde materiale på Web2py, Python og distribusjonsmiljøene som brukes til begge deler. For det andre er den skrevet i en svært tilgjengelig, fortellende stil. For det tredje snakker den grundig om vanlige scenarier for applikasjonsbygging. Det er for eksempel et helt kapittel om å bruke jQuery til å bygge AJAX-applikasjoner.
Weppy
Weppy føles som et halvt merke mellom den minimale enkelheten i Flask og fullstendigheten til Django. Mens du utvikler en Weppy-app, har Flash rett, kommer Weppy med mange funksjoner som finnes i Django, som datalag og autentisering. Dermed passer Weppy til apper som spenner fra ekstremt enkle til beskjedent sofistikerte.
Ved første øyekast ser Weppy-kode ut som Flaskekode eller Flaskekode. Få instruksjoner er nødvendig for å få et grunnleggende nettsted med én rute i gang. Ruter kan beskrives gjennom funksjonsdekoratører (på den enkle måten) eller programmatisk, og syntaksen for å gjøre dette hugger tett på Flask / Bottle. Mal fungerer omtrent det samme, bortsett fra mindre variasjoner i syntaksen.
Weppy står i kontrast til de mindre rammene ved å inkludere noen funksjoner de bare inneholder som plugin-moduler eller tillegg. For eksempel har verken Flask eller Bottle et innebygd ORM eller et datastyringssystem. Weppy inkluderer en ORM, om enn en basert på pyDAL-prosjektet i stedet for den langt mer populære SQLAlchemy. Weppy støtter til og med skjemamigrasjoner, som Django støtter som en del av ORM (Djangos migrasjonssystem er også mye mer automatisert). Mens Weppy har en utvidelsesmekanisme, er listen over offisielt godkjente tilleggsprogrammer liten, langt mindre enn katalogen med utvidelser for Flask.
Rammeverk med lettere vekt som Weppy brukes ofte til å bygge RESTful APIer, og Weppy er utstyrt med bekvemmelighetsfunksjoner for det formålet. Sett en @service dekoratør på en rute, og dataene du returnerer blir automatisk formatert etter ditt valg av JSON eller XML.
Weppy inkluderer andre funksjoner som virker mer i tråd med et større rammeverk, men er implementert uten bulk. Eksempler inkluderer datavalideringsmekanismer, skjemahåndtering, responsbuffering og brukervalidering. I alle disse tilfellene tar Weppy en "akkurat nok" tilnærming. Funksjonene som tilbys er ikke så komplette som du kan finne i Django og andre tungvektsrammer, men en utvikler trenger ikke å investere mye arbeid i å gjøre dem nyttige, og de kan alltid utvides etter det.
En annen tungvekts rammefunksjon som finnes i Weppy er støtte for internasjonalisering. Strenger i maler kan oversettes i henhold til lokale filer som følger med applikasjonen, som er enkle Python-ordbøker. Valg av språk kan også angis ved å analysere nettleserforespørselen (det vil si HTTP-overskriften Godta-språk) eller ved å binde en oversettelse til en bestemt rute.
Weppys dokumentasjon har samme smak som selve rammeverket. Det er rent, lesbart og skrevet for å bli konsumert av mennesker. Bortsett fra det vanlige “hei verden” -eksemplet, inneholder det en fin gjennomgangsveiledning som lar deg lage et mikrobloggingssystem som et startprosjekt.
Langsiktige planer for Weppy inkluderer støtte for asynkronisering og stikkontakter som førsteklasses enheter. Weppys utviklere planlegger å introdusere disse funksjonene i versjon 2.0, og deretter kreve Python 3.7 eller bedre for alle fremtidige versjoner av Weppy.
