Programmering

5 store og kraftfulde Python-webrammer

Når du bygger en backend til et websted eller en tjeneste, selv en der ved første øjekast virker beskeden, kan du hurtigt finde ud af, at det er alt andet end. Selv et "simpelt" sted viser sig at være en bikube af kompleksitet. Brugeradministration, datadesign, formularindsendelser, sikkerhed - implementering af alt dette manuelt bliver kedeligt.

For de store webprojekter, når du ved, at du har brug for alt plus køkkenvasken, er det bedst at henvende sig til en ramme, der følger med batterier (og opladere) inkluderet. Her er fem tunge webrammer til Python, der kommer med alt hvad du behøver for at opbygge robuste webapplikationer og derefter nogle.

CubicWeb

CubicWeb faktureres som "en semantisk ramme til webapplikationer, der favoriserer genbrug og objektorienteret design." Det er et spændende system - som bemærket af Rick Grehan, da han gennemgik det tilbage i 2011 - der understreger brugen af ​​abstraktioner og genanvendelige byggesten af ​​kode kaldet "terninger". Faktisk kan CubicWeb være for abstrakt eller idiosynkratisk for nogle udviklere, og dens udviklingshastighed og funktion sætter andre rammer.

Kuber er softwarekomponenter, der har et skema (datamodel), enheder (programmeringslogik) og visninger. Ved at samle flere terninger, der hver udfører sin egen opgave, kan du komponere softwareapplikationer ved at genbruge din egen kode og andres kode.

I sin kerne leverer CubicWeb grundlæggende stilladser, der bruges af enhver webapp: et "lager" til dataforbindelser og lagring; en “webmotor” til grundlæggende HTTP-anmodning / respons og CRUD-handlinger; og et skema til modellering af data. Alt dette er beskrevet i Python-klassedefinitioner.

For at opsætte og administrere forekomster af CubicWeb arbejder du med et kommandolinjeværktøj svarende til det, der bruges til Django. Et indbygget skabelonsystem lader dig programmatisk generere HTML-output. Du kan også bruge en terning, der indeholder værktøjer til web-UI'er, såsom den til Bootstrap HTML-rammen.

Selvom CubicWeb understøtter Python 3 (siden version 3.23), ser det ikke ud til at bruge Python 3s native async-funktionalitet. En rundkørsel til at inkludere async ville være at bruge cubicweb.pyramid-modulet til at bruge Pyramid-rammen som webserveren og trække på en gaffel af Pyramid, der bruger async-konstruktioner. Det er også muligt at udføre opgaver asynkront med cubicweb-worker-terningen. Men alt mere ligetil synes utilgængeligt for nu.

For at hente eller manipulere vedvarende data i en CubicWeb-app bruger du Relation Query Language (RQL), som anvender svagt SQL-lignende syntaks, men er mønstret efter W3C's SparQL. CubicWebs begrundelse for dette er igen abstraktion: RQL giver en stærkt afkoblet rute til at forbinde forskellige datakilder.

Da CubicWeb har mange afhængigheder, er det bedst at bruge det pip-installation at hente dem alle. Du skal muligvis også udføre en vis mængde manuel tilpasning af det lokale miljø. Dette er i modsætning til andre rammer, hvor kører pip-installation eller alt det, der kræves, er at slippe rammekoden i en undermappe til et andet projekt. Eller du kan bruge en Docker-container til at få tingene til at køre.

CubicWeb henviser til sin lange dokumentation som "bogen". Forfatterne af bogen har taget sig tid til at forklare CubicWebs usædvanlige tilgang, demonstrere hvordan man bygger nogle grundlæggende applikationer, inkluderer API-referencer og generelt går ud af deres måde at være specifik.

CubicWeb forbliver under aktiv, hvis langsom, udvikling. Planer for CubicWeb 4.0 er blevet mullret siden 2012, men der er endnu ikke tilbudt nogen tidslinje til levering.

Django

I årtiet og forandringen, siden Django første gang dukkede op, er det blevet en af ​​Pythons mest udbredte rammer til oprettelse af webapplikationer. Django leveres med stort set ethvert batteri, du har brug for, hvilket gør det mere velegnet til opbygning af store applikationer end små.

Django tilbragte mange år ved version 1.x. Da Django 2.0 ankom i slutningen af ​​2017, faldt den kompatibilitet med Python 2 til fordel for Python 3.4 og nyere. Django 3.0, der blev udgivet i december 2019, kræver Python 3.6 eller bedre og tilføjer support til den nye asynkrone ASGI-standard til Python-webapplikationer.

En vigtig del af Djangos appel er implementeringshastighed. Fordi Django indeholder så mange stykker, du har brug for til at udvikle den gennemsnitlige webapplikation, kan du komme i bevægelse hurtigt. Routing, URL-parsing, databaseforbindelse inklusive en ORM (objekt-relationskort), formvalidering, angrebsbeskyttelse og skabeloner er alle indbyggede.

Du finder byggesten til de mest almindelige scenarier for webapplikationer. Brugeradministration findes for eksempel på de fleste websteder, så Django tilbyder det som et standardelement. I stedet for at skulle oprette dit eget system til sporing af brugerkonti, sessioner, adgangskoder, log-in / log-outs, admin-tilladelser og så videre, giver Django disse funktioner indbygget. De kan bruges som de er eller udvides til at omfatte nye brugssager med minimalt arbejde.

Django har fornuftige og sikre standardindstillinger, der hjælper med at beskytte din webapplikation mod angreb. Når du placerer en variabel i en sideskabelon, såsom en streng med HTML eller JavaScript, gengives indholdet ikke bogstaveligt, medmindre du eksplicit angiver forekomsten af ​​variablen som sikker. Dette eliminerer i sig selv mange almindelige scripting-problemer på tværs af websteder. Hvis du vil udføre formularvalidering, kan du bruge alt fra simpel CSRF-beskyttelse til fuldblæst felt-for-felt-valideringsmekanismer, der returnerer detaljeret fejlfeedback.

En funktion, der er så rig og bred som Django, ville ikke være meget god uden robust dokumentation, der passer til den. Django-dokumentationen borer ind i alle aspekter af rammen fra flere vinkler. Arbejde med Python 3 eller andre varianter af sproget, gøre sikkerhed rigtigt, implementere almindelige webapplikationskomponenter (som sessioner eller paginering), generere sitemaps - de er alle dækket. API'erne for hvert lag i applikationen - model, visning og skabelon - er også beskrevet detaljeret.

Med stor kraft kommer der imidlertid stor kompleksitet. Django-applikationer har ry for at være top-tunge, fyldt med mange bevægelige dele. Selv en simpel Django-app kræver en hel del konfiguration for at komme i gang. Hvis dit mål er at gøre lidt mere end at oprette et par enkle REST-endepunkter, er Django næsten helt sikkert overdreven.

Django har også sine særheder. F.eks. Kan sideskabeloner ikke bruge callables. Eksempel: Du kan bestå {{user.name}} som en komponent i en skabelon, men ikke {{user.get_name ()}}. Det er en af ​​måderne, som Django sikrer, at skabeloner ikke utilsigtet skyder dig i foden, men disse begrænsninger kan knuse, hvis du ikke er forberedt på dem. Mens der er løsninger, har de en tendens til at tage en vejafgift på ydeevnen.

Fra version 3.0 har Django tilføjet support til asynkrone visninger. Desværre er der endnu ikke understøttelse af asynkronisering i andre dele af Django-stakken, som ORM. Men du kan implementere Django ved hjælp af ASGI for at drage fuld fordel af async-visninger.

Web2py

I en verden af ​​Ruby-programmering er Ruby on Rails de facto-webrammen. DePaul University datalogiprofessor Massimo Di Pierro blev inspireret af Rails til at skabe en webramme i Python, der på samme måde var let at opsætte og bruge. Resultatet er Web2py.

Web2pys største attraktion er dets indbyggede udviklingsmiljø. Når du opretter en forekomst af Web2py, får du en webgrænseflade, i det væsentlige en online Python-applikationseditor, hvor du kan konfigurere appens komponenter. Dette betyder typisk at oprette modeller, visninger og controllere, hver beskrevet via Python-moduler eller HTML-skabeloner. Et par eksempler på apps leveres med Web2py ud af kassen. Du kan tage dem fra hinanden for at se, hvordan de fungerer, eller udnytte dem som startskabeloner til at oprette dine egne apps.

Udviklere implementerer typisk Web2py ved at downloade kildekoden og bygge videre på det. Men for mindre tekniske brugere på Windows eller MacOS tilbyder Web2pys skabere versioner, der i det væsentlige er enkeltstående servere. Download, udpak og kør en af ​​disse versioner, så får du en lokal webserver med en forudkonfigureret kopi af Web2py indbygget. Dette er en god måde at få et ben på at oprette en Web2py-app, som derefter kan implementeres andre steder efter behov.

Web2pys webgrænseflade blev bygget med Bootstrap 4, så det er let at se på og let at navigere. In-browser-editoren er ingen erstatning for en fuldstændig IDE, men den er udstyret med nyttige hjælpemidler som linjenummerering og Python-syntaksfremhævning (inklusive automatisk indrykning). Der er også inkluderet en hurtig webgrænseflade til Python-skallen, så du kan interagere med Web2py fra kommandolinjen - en god indrømmelse til eksperter.

Dataabstraktionssystemet, der bruges i Web2py, fungerer lidt anderledes end Djangos ORM og andre ORM'er inspireret af det (såsom Peewee). Disse systemer bruger Python-klasser til at definere modeller, mens Web2py bruger konstruktorfunktioner som definere_tabel at instantiere modeller. Forskellene vil sandsynligvis kun skære, hvis du er vant til den anden vej; de bør ikke fejle nybegyndere. Du har sandsynligvis ikke problemer med at tilslutte Web2py til en dataudbyder, da den taler til næsten alle større eksisterende databaser.

En virkelig nyttig database-relateret funktion i Web2py er evnen til at generere et diagram over modellerne, så du kan visualisere, hvordan dine modeller forholder sig til hinanden. Du skal dog installere PyGraphviz-biblioteket for at aktivere denne funktion.

Web2py leverer mange andre komponenter af professionel kvalitet: internationaliseringsfunktioner, flere cachemetoder, adgangskontrol og autorisation og endda frontend-effekter (for eksempel en datovælger i formularer) via integreret support til jQuery og AJAX. Kroge til ekstern og intern middleware er også inkluderet, selvom du ikke har tilladelse til at bruge middleware til at erstatte centrale Web2py-funktioner. Der er dog endnu ingen eksplicit brug af Pythons async-funktionalitet i Web2py, selvom der er en planlægning til håndtering af langvarige opgaver.

Det er ikke underligt, at Web2pys dokumentation kaldes "bogen". For det første dækker det en svimlende mængde materiale på Web2py, Python og de installationsmiljøer, der bruges til begge. For det andet er det skrevet i en meget tilgængelig, fortællende stil. For det tredje taler den indgående om almindelige applikationsopbygningsscenarier. Der er for eksempel et helt kapitel om brug af jQuery til at opbygge AJAX-applikationer.

Weppy

Weppy føles som et halvvejs mærke mellem Flaskens minimale enkelhed og Djangos fuldstændighed. Mens du udvikler en Weppy-app, har Flash ligetil, kommer Weppy med mange funktioner, der findes i Django, som datalag og godkendelse. Således er Weppy velegnet til apps, der spænder fra ekstremt enkle til beskedent sofistikerede.

Ved første øjekast ser Weppy-koden meget ud som Flaskekode eller Flaskekode. Få instruktioner er nødvendige for at få et grundlæggende websted med en rute i gang. Ruter kan beskrives gennem funktionsdekoratorer (på den nemme måde) eller programmatisk, og syntaksen til dette hugger tæt på Flask / Bottle. Skabeloner fungerer omtrent det samme bortset fra mindre variationer i syntaksen.

Weppy står i kontrast til de mindre rammer ved at inkludere nogle funktioner, de kun indeholder som plug-ins eller add-ons. For eksempel har hverken Flask eller Bottle et indbygget ORM eller et datastyringssystem. Weppy inkluderer en ORM, omend en baseret på pyDAL-projektet snarere end den langt mere populære SQLAlchemy. Weppy understøtter endda skemamigrationer, som Django understøtter som en del af sin ORM (Djangos migrationssystem er også meget mere automatiseret). Mens Weppy har en udvidelsesmekanisme, er listen over officielt godkendte tilføjelser lille, langt mindre end kataloget med udvidelser til Flask.

Lysere rammer som Weppy bruges ofte til at opbygge RESTful API'er, og Weppy er udstyret med bekvemmelighedsfunktioner til dette formål. Sæt en @service dekoratør på en rute, og de data, du returnerer, formateres automatisk efter dit valg af JSON eller XML.

Weppy inkluderer andre funktioner, der synes mere i tråd med en større ramme, men implementeres uden bulk. Eksempler inkluderer datavalideringsmekanismer, formhåndtering, caching af svar og brugervalidering. I alle disse tilfælde tager Weppy en ”lige nok” tilgang. De leverede funktioner er ikke så komplette, som du måske finder i Django og andre tungvægtsrammer, men en udvikler behøver ikke investere meget arbejde i at gøre dem nyttige, og de kan altid udvides efter det faktum.

En anden tungvægts rammefunktion, der findes i Weppy, er internationaliseringsstøtte. Strenge i skabeloner kan oversættes i henhold til sprogfiler, der følger med applikationen, som er enkle Python-ordbøger. Valget af sprog kan også indstilles ved at analysere browseranmodningen (dvs. HTTP-overskriften Accept-Language) eller ved at binde en oversættelse til en bestemt rute.

Weppys dokumentation har den samme smag som selve rammen. Det er rent, læsbart og skrevet til at blive fortæret af mennesker. Bortset fra det sædvanlige "hej verden" -eksempel, inkluderer det en god gennemgangsvejledning, der lader dig oprette et mikroblogging-system som et startprojekt.

Langsigtede planer for Weppy inkluderer understøttelse af asynkronisering og stikkontakter som førsteklasses enheder på lavt niveau. Weppys udviklere planlægger at introducere disse funktioner i version 2.0 og derefter kræve Python 3.7 eller bedre for alle fremtidige versioner af Weppy.

Zope

$config[zx-auto] not found$config[zx-overlay] not found