Prosjektering / FS layout for store Django prosjekter

stemmer
40

Hva er den beste måten å layout en stor django prosjekt? Veiledningene gir enkle instruksjoner for å sette opp programmer, modeller og visninger, men det er mindre informasjon om hvordan apps og prosjekter skal brytes ned, er hvor mye deling tillatte / nødvendig mellom programmer i et typisk prosjekt (selvsagt det er i stor grad avhengig prosjektet) og hvordan / hvor allmenne maler bør holdes.

Har noen eksempler, forslag og forklaringer på hvorfor et bestemt prosjekt layout er bedre enn en annen? Jeg er spesielt interessert i inkorporering av et stort antall enhetstester (2-5x størrelsen av selve koden base) og strengen eksternalisering / maler.

Publisert på 04/09/2008 klokken 16:36
kilden bruker
På andre språk...                            


6 svar

stemmer
17

De viktigste retningslinjene er lik alle andre store kode prosjektet. Apps bør ta et enkelt, klart definert ansvar. Navnet "program" er et misvisende; Django apps bør betraktes mer som gjenbrukbare komponenter som kan plugges sammen for å skape en reell søknad. Tester for hver app bør ligge innenfor denne app. Apps skal være frikoplet fra hverandre så mye som mulig, men klart det vil være avhengigheter, så målet bør være å holde avhengigheten grafen så enkelt og fornuftig som mulig.

Jeg foretrekker å holde alle malene for et prosjekt under et enkelt prosjekt-wide maler katalog, med en underkatalog for hver app (ved hjelp av en mal underkatalog for hver app er en veldig sterk konvensjon i Django, som det unngår mal navnekollisjoner mellom programmer) . Bakgrunnen for en enkelt prosjektbasis maler katalogen er at maler, mal arv trær, og blokkere navn kan være ganske prosjektspesifikke, så det er vanskelig å gi "default" app maler som kan plugge inn i ethvert prosjekt. Det har vært noen forsøk på å slå seg på standard navnekonvensjoner for base hele nettstedet maler og blokkene de definerer, men jeg har ikke sett en standard dukke opp ennå (slik de gjør ting over på Pinax er sannsynligvis det nærmeste vi har i standard).

Re "streng eksternalisering", hvis du mener i18n og l10n, har Django sterk støtte for dette og standard steder hvor det setter .po filer - Kontroller docs .

Svarte 25/09/2008 kl. 19:30
kilden bruker

stemmer
9

Jeg fant Zachary layout ganske nyttig Zachary Voase blogg »Django Prosjekt konvensjoner, Revisited.

Svarte 22/04/2010 kl. 01:17
kilden bruker

stemmer
6

Denne siden gjør en god jobb med å ta opp noen av mine spørsmål: http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/

Nærmere bestemt:

  1. Å definere tilpassede malkodene eller filtre, må du opprette en underkatalog i programmets katalog kalt templatetags, og den må inneholde en fil med navnet __init__.py slik at det kan importeres som en Python-modul.
  2. For å definere enhet tester som automatisk vil bli lagt merke til av Django testing rammeverk, legg dem i en modul kalt tester (som kan være enten en fil som heter tests.py eller en katalog som heter tester). Testingen rammeverket vil også finne noen doctests i den modulen, men det foretrukne sted for de er, selvfølgelig, docstrings av klassene eller funksjoner de er laget for å teste.
  3. Å gi tilpasset SQL som vil bli utført umiddelbart etter at søknaden er installert, oppretter en underkatalog kalt sql inne i programmets katalog; filnavnene skal være det samme som navnet på de modellene som tabellene de vil operere på; for eksempel hvis du har en app som heter weblog inneholder en modell som heter Entry, deretter filen sql / entry.sql inne i app katalog kan brukes til å endre eller sette inn data i oppføringene bordet så snart det er blitt opprettet.

Notatet om tests.py og tester (katalogen) innehar også for modeller, noe som bidrar til problemet med å ha altfor mange tester (eller modeller) for en fil.

Jeg ønsker fortsatt å se noen eksempler / forslag for app / prosjekt bryte ned, og store Django områder som fungerer bra.

Svarte 04/09/2008 kl. 16:44
kilden bruker

stemmer
3

Den Pinax prosjektet er bygget rundt ideen om små gjenbrukbare apps, som er lett bringes sammen i et prosjekt. De har brukt prosjektet Cloud 27 som en demo prosjekt.

Django prosjekt jeg jobber med (kalt Basie. Det er pre-0.1, så ingen link ennå.) Prøver å følge Pinax modellen, og så langt det er å jobbe ut ganske godt.

Svarte 31/10/2008 kl. 00:22
kilden bruker

stemmer
1

Jeg liker Randall Degges' innlegg om dette temaet. Han etterlater seg info om hvordan å lime innstillingsfiler sammen, men jeg vil ha et innlegg på at jeg vil være i stand til å koble, men for nå hvem som helst kan sjekke ut min repo der jeg har noen retning i readme.

Svarte 21/07/2012 kl. 12:40
kilden bruker

stemmer
1

Min nåværende layout stammer fra meg som ønsker å ha en test-versjon av mine nettsteder. Dette betyr å ha to prosjekter for hvert område, siden de trenger ulike konfigurasjoner, og tvinger meg til å flytte alle programmene ut av prosjektene.

Jeg har laget to mapper: $ APP_ROOT / devel og $ APP_ROOT / prod. Disse inneholder alle apps. Bruke kildekontroll (i mitt tilfelle git) Jeg har apps i utvik på hodet revisjonen, mens programmene i prod er låst til VARE tag. Malene har også sin egen mappe med samme layout som apps.

Nå er jeg i stand til å gjøre alt min utvikling i utvikli-apps mappen og den tilhørende mal-mappen. Når jeg har noe jeg er fornøyd med, merker jeg at revisjon og oppdatering prod.

Svarte 09/01/2009 kl. 10:35
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more