avalanche

lavin är ett webbramverk Python byggt ovanpå webapp2. & Nbsp; Den använder Jinja2 som en standardmall systemet och inte innehåller någon uthållighet lager.
Avalanche mål (eller varför en annan ram webben?)
Lavin designen fokus på testbarhet och återanvändbarhet.
Naturligtvis Avalanche inte gör mirakel. Testbarhet och återanvändbarhet i slutändan kommer beror på programkoden. Men ramarna har en stor roll i att inrätta rätt väg.
Målen presenteras nedan, förhoppningsvis efter att ha läst utformningen och handledning det kommer att vara klart för er hur dessa mål uppnås.
Testbarhet
Avalanche var utformade på ett sätt att det gör det möjligt (lättare för dig) att skriva bra enhetstester för din kod. Det är inte bara att göra det enkelt att skriva tester. En enhet-testet bör:
- Ge en klar felmeddelande när den misslyckas
- Misslyckas bara när funktionen under test är trasig, inte på varje koden ändras
- Vara snabb
Återanvändning
Mestadels varje ram hävdar att återanvändbarhet är en av deras design mål. Här "återanvändbarhet" betyder källkod återanvändbarhet.
Många ramar ge några mekanismer för återanvändbara / instickbara under applikationer men det är inte alltid lätt att återanvända dessa applikationer källkod i fall du behöver för att konfigurera / modifiera det. Instickbara applikationer är också en mycket viktig funktion, men redan nu Avalanche har inget stöd för det.
Det ska inte bara vara möjligt att skriva återanvändbar kod, koden ska återanvändas på den första gången du skriver det. Du bör inte uppmanas att skriva in koden på ett sätt, och än senare måste ändra den så att den kan återanvändas. L.e. den motsätter sig att säga "Använd view (handler) funktioner". Och än ... "om du vill att dina åsikter att kunna återanvändas konvertera dem till klassbaserade vyer!".
Projektdetaljer
- Webbplats / docs
- Det här är ett projekt med öppen källkod (MIT licens) skriven i python.
- Ladda ner från PyPi
- Projektledning (bug tracker, förfrågningar har och källkod) på bitbucket.
- Frågor och feedback på google-grupp.
Avalanche Design
Varning
Avalanche är på ett tidigt utvecklingsskede (alfa). API kan förändras i framtiden och det finns ingen garanti att det kommer att hålla kompatibilitet.
bortom MVC (Model-View-Controller)
MVC är en programvara arkitektonisk mönster som skapats med målet att isolera "domänlogik" från användargränssnittet. Denna separation av oro möjliggör skapandet av en bättre tillämpning koden. Detta mönster var mycket framgångsrikt för många skrivbords ramar och så fungerade som en hänvisning till skapandet av web-ramar. Problemet är att denna arkitektur inte kan mappas direkt till det sätt webb-applikationer arbete.
Även de så kallade MVC ramverk är inte riktigt MVC. Så låt oss bara hålla MVC mål. Det vill skriva rent, återanvändbara och testbar kod.
webbapplikationer
I princip all en webb-applikation gör är att ta emot en HTTP-begäran, bearbeta den och generera ett HTTP-svar.
& Nbsp; + ------------------ +
HTTP Request ------> | webbapplikation + -----> HTTP Response
& Nbsp; + ------------------ +
Sändning och mottagning HTTP hanteras av en webb-server. Låt oss ta en närmare titt på vad webben ansökan gör:
& Nbsp; + ------ + + ------- +
HTTP-begäran ----> | router | -----> | handler | ----> HTTP-svar
& Nbsp; + ------ + + ------- +
Routern kommer att kontrollera webbadressen för begäran och skicka den till en förfrågan hanterare som kommer att skapa svaret. Avalanche använder webapp2 routern.
förfrågan lastare stilar
Det finns i huvudsak tre stilar av förfrågnings hanterare.
- En enda funktion
- En klassmetod
- En klass
Avalanche (och webapp2) använder den tredje stilen, en klass. Med hjälp av en klass som förfrågan handler passar bättre våra mål eftersom det ger en större flexibilitet, enklare att ändra / utöka och återanvända delar av föraren.
Begäran handler bearbetning
Begäran-hanteraren bearbetning kan delas i tre faser:
& Nbsp; + ----------------- + + ----------------- + + --------- - +
begära ----> | param omvandlare | ---- param föremål ----> | kontext byggare | --- sammanhang -----> | renderaren | ----> svar
& Nbsp; + ----------------- + + ----------------- + + --------- - +
1. param omvandlare - få parametrar från HTTP-begäran
& Nbsp; HTTP är ett textprotokoll kommer ansökan vanligtvis få några parametrar från begäran och konvertera strängvärden i vissa inhemska datatyper. Dessa parametrar är tagna från URI bana, URI query, post-uppgifter, kakor, etc.
2. sammanhang byggare - bearbetning
& Nbsp; Sammanhang är en term som används för att representera data som kommer att användas av en renderare.
& Nbsp; Det här behandlingen är programlogiken. Det kommer ofta åt ett lager persistens (kallas ibland Model), men det är helt upp till programkoden och ramarna har någon roll om det.
& Nbsp; En webbsida ofta består av flera delar så ibland är det klokt att dela upp arbetet i mer än en "kontext byggare".
3. renderare - generera utdata
& Nbsp; Renderaren kommer att omvandla resultatet av behandlingen till text HTTP svaret. Detta steg kan hoppas över om svaret är en HTTP redirect. Renderaren kommer vanligtvis att använda en mall system för att generera HTML-kod eller konvertera data till JSON.
På lavin ska du skriva kod för de 3 stegen av hundföraren separat och låt ramarna limma ihop de olika delarna.
. Gå vidare till handledning för att se hur det ser ut

Krav :

• Python