ccnmtldjango

ccnmtldjango är en Klistra mall som vi använder för att ersätta den vanliga django-admin.py startproject kommandot.
Den gör samma grundläggande uppgiften att inrätta en katalogstruktur för en django app, men det har förlängts för att genomföra en hel del CCNMTL specifik funktionalitet och konfiguration.
Vad det ger för oss att startproject inte:
- Django Wind (en Django bro till Columbia centrala auth tjänst - http://www.jasig.org/cas/deployments/columbia-university) ingår och konfigureras som standard så våra appar kan använda WIND för auth automatiskt. Dvs, alla med en Columbia UNI som standard kommer att ha ett konto. De CCNMTL utvecklare Unis automatiskt in som superanvändare, och gruppen affil att CCNMTL personal alla har blir automatiskt mappas till personalen. Dessa är i allmänhet användbara standardvärden för oss.
- Virtualenv och pip installation med käll tarbollarna buntade och bootstrappable, manage.py s shebang inställd på att använda den. Detta passar i princip det i vår en-stegs automatisk distribution och inneslutning strategi.
- Sorl.thumbnail (en praktisk dandy bildthumbnails bibliotek) ingår som standard
- Flatpages aktiverade
- Inställningar split för dev / prod
- Apache / django.wsgi konfigurerad
- Prov apache config för mod_wsgi inställning använder virtuella miljöer (allt effektiviseras så att vi bara kan symbolisk länk den genererade apache config-fil till vår produktion server / etc / apache / sites-enabled / katalogen och det är bra att gå)
- Medie dirs för dev och prod konfigurerad
- Smartif ingår (https://github.com/thraxil/django-smartif/tree/master)
- Template_utils ingår (http://code.google.com/p/django-template-utils/) samt feedparser, vilket det beror på för foder grejer
- Django-typogrify ingår (http://code.google.com/p/typogrify/) tillsammans med smartypants.py (som den använder)
- Django-vaktpost ingår (https://github.com/dcramer/django-sentry) och konfigurerad för vår inställning
- Django-munin ingår (https://github.com/ccnmtl/django-munin)
- Södra ingår för databas migreringar
- Django-irriterande ingår (jag gillarrender_to)
- Django-näsa installerad och inrättades som prov löpare (mycket trevligare!)
- Sqlite in-memory databas som används för enhetstester
- Söder tester hoppade automatiskt på ./manage.py testet (de bryter)
- Django_compressor sätts och ställa in att komprimera css på produktion
- Uuid.py
- JQuery (1.4.2, minified) inkluderade
- hs.js
- tabber.js
- widget.js
- tablesort.js
- Krävs CSS för ovanstående js biblioteken ingår i site.css som standard
- Base mallar ingår
- Django admin aktiverat (och autentiseras med WIND för TLC)
- Restclient
- Httplib2
- Imageuploader
- Markdown ingår och aktiverat
- Databas som standard till PostgreSQL (orsak MySQL är teh suck)
- Transaktionsmiddle aktiverat som standard (orsak data korruption är teh suck)
- Tidszon uppsättning
- I18n avstängd (vi är tyvärr enspråkiga ingen mening i att förneka det.)
- PIL
- Psycopg2 (tagen sin mx.DateTime beroende)
- En trevlig standardmall design med alternativa bas mallar för flera kolumner layout.
För att använda ccnmtldjango behöver du python 2.6+, virtualenv, pip, och en nyligen setuptools installerade på din maskin.
Först, om du inte redan har ccnmtldjango installerat, gör
& Nbsp; easy_install ccnmtldjango
Det bör automatiskt dra in de nödvändiga beroenden (precis PasteScript, faktiskt).
Löpning
& Nbsp; paster skapa list-mallar
bör innehålla ccnmtldjango
Nu, för att KOMIGÅNG en django projektet, men
& Nbsp; paster skapar --template = ccnmtldjango myprojectname
myprojectname bör vara en python modulnamn (dvs gemener, ingen skiljetecken, etc). Det kommer att skapa en katalog som heter myprojectname som har en django projekt i den.
paster fortfarande inte göra något med filrättigheter, så vi måste fortfarande manuellt ställa ett par:
& Nbsp; cd myprojectname
& Nbsp; chmod 755 manage.py bootstrap.py
Jag kunde inte räkna ut ett sätt att infoga slumpmässiga strängar i koden via Klistra Mall, så en sak som ccnmtldjango saknas jämfört med en vanlig django startproject är att SECRET_KEY variabeln i settings_shared.py är alltid samma standard. Det är uppenbarligen inte en bra idé, så se till att du ändrar det till någon annan slumpmässig sträng som kommer att vara unik för ditt projekt.
Detta är förmodligen en bra punkt att kolla upp projektet i versionskontroll.
Vi använder inneslutning för django också, med virtualenv:
& Nbsp; ./ bootstrap.py
Det kommer att skapa en ve katalog som innehåller en virtualenv och har haft alla bibliotek i krav / src katalogen installeras i det (detta inkluderar django själv). Den ve katalogen ska aldrig checkas in svn eftersom det genereras. Om du behöver andra bibliotek för din ansökan, bunta dem som tar-arkiv och släppa dem i krav / src / katalogen, lägga till dem i krav / libs.txt eller krav / apps.txt (beroende på om de är regelbundna bibliotek python eller django appar) sedan köra ./bootstrap.py.
Tänk på att med virtualenv, det finns ingen anledning att aktivera en miljö. Istället en ve har en bin som innehåller en python körbar. Om du använder det i stället för system python körbara, använder den biblioteken i det virtualenv.
ccnmtldjango förutsätter att ditt projekt kommer att använda en PostgreSQL-databas med samma namn som ditt projekt. Så, för vårt exempel, skulle du då göra:
& Nbsp; createdb myprojectname
och det är redo att använda den:
& Nbsp; ./ manage.py SyncDB
kommer att installera de tabeller som Django behoven för det är vanliga appar (webbplatser, sessioner, admin, flatpages, etc), och har du skapar en administratör.
Den ./manage.py SyncDB sätter automagiskt upp en "example.com" site. Detta bör ändras till din webbplats domän (t.ex. localhost: 8000) via administratörskonsolen. http: // localhost: 8000 / admin / platser / site /. (Om det spelar någon roll för din ansökan)
Din ansökan är klar att köra nu:
& Nbsp; ./ manage.py runserver
kommer att starta en server på http: // localhost: 8000 /. Going det kommer att ge dig en 404, eftersom det finns inget i ansökan ännu, men admin app bör vara tillgängliga (via användarkontot du skapade under SyncDB, eller via WIND TLC användare (eller sådana som specificeras i WIND_SUPERUSER_MAPPER_GROUPS listan i settings_shared.py .) Så sätt igång och logga in på http: // localhost: 8000 / admin /
Även utan alla program specifik kod är flatpages ingår så du kan sätta innehåll på webben direkt.
Från denna punkt ut, det är grundläggande django utveckling. Du kommer förmodligen vill göra en ./manage.py startapp att skapa din egen ansökan inom projektet och så vidare.
Att sätta upp en fräsch kassan
Första gången du kolla in en befintlig ccnmtl-mall projekt från svn / git:
& Nbsp; ./ bootstrap.py
./manage.py runserver :
Skillnader från en standard Django installation
Uppenbarligen har en massa bibliotek och en sådan tillkommit och det är hela virtualenv sak. Det finns också vissa skillnader från en standard django projekt (dvs. resultatet av django-admin.py startproject) att du bör vara awayre av.
För det första har de inställningar som delats upp för att göra dev och prod distributioner lättare att konfigurera. En regelbunden django installera kommer att ha en settings.py fil som innehåller alla inställningar. Django utvecklare kommer vanligtvis kopiera den inställningsfil och göra ändringar när de distribueras till produktionen. ccnmtldjango utnyttjar det faktum att inställningarna är bara python kod och kan importeras och åsido. Så vi har en settings_shared.py som innehåller de flesta inställningar. settings.py (som ska användas för utveckling) och settings_production.py sedan importera allt från från settings_shared.py. settings_production.py då åsidosätter också några inställningar som bör vara olika i produktions utbyggnaden (vanligtvis vägar till mallar och mediafiler).
TransactionMiddleware är aktiverat som standard. Det innebär att varje HTTP-begäran får en transaktion som begår eller rullar tillbaka i slutet av begäran. Standard django setup för någon anledning gör saker "AUTOCOMMIT" stil där varje databas operation löper i sin egen transaktion, oberoende av HTTP-begäran.
Den andra stora skillnaden att vara medveten om är den översta nivån mallar katalogen. Standard django förfarande är att ha en mall katalog i varje program i ditt projekt som innehåller mallar för det programmet. ccnmtldjango har toppnivå mallar katalog för ett par anledningar. Först, eftersom paster skapar bara projektnivå katalogen och inte de programkataloger, det var det enda sättet att få den att innehålla en standard base.html, admin / login.html, registrering / login.html och så vidare. Jag också precis som strategi att ha en projektnivå mallar katalog, särskilt för base.html mallen. Django tillåter flera mallkataloger och sökningar genom dem i en förutsägbar ordning, så att du kan (och förmodligen bör) ändå skapa tillämpningsnivå mallkataloger, lista dem i TEMPLATE_DIRS inför projektnivå ett, och åsidosätta allt mallar som du vill ha i dem.
I18N är avstängd eftersom det är ganska ovanligt att vi gör flerspråkiga grejer och det är en prestation hit för att ha det aktiverat om det inte används. . Om du behöver göra en flerspråkig django plats, bara aktivera den igen och få arbeta

Krav :

• Python