Struktura projektu dla Google App Engine

| | | | | | | | | | | | | | | | | | | |

Zacząłem aplikację w Google App Engine, kiedy się pojawiła, aby bawić się technologią i pracować nad projektem dla zwierząt, o którym myślałem od dawna, ale nigdy nie zacząłem. Wynik to BowlSK. Jednak w miarę rozwoju i dodawania funkcji stało się naprawdę trudno utrzymać porządek - głównie ze względu na to, że jest to mój pierwszy projekt w Pythonie i nie wiedziałem o nim nic, dopóki nie zacząłem pracować.

Co mam:

  • Główny poziom zawiera:
    • wszystkie pliki .py (nie wiedziałem, jak sprawić, by pakiety działały)
    • wszystkie szablony .html dla stron głównego poziomu
  • Podkatalogi:
    • oddzielne foldery na css, obrazy, js itp.
    • foldery zawierające szablony .html dla adresów URL typu subdirecty

Przykład:
http://www.bowlsk.com/ mapuje stronę główną (pakiet domyślny), szablon pod adresem „index.html”
http://www.bowlsk.com/games/view-series.html?series=7130 mapuje do ViewSeriesPage (ponownie, domyślny pakiet), szablon w "games/view-series.html"

To paskudne. Jak to zrobić restrukturyzacji? Miałem 2 pomysły:

  • Folder główny zawierający: appdef, indexes, main.py?

    • Podfolder na kod. Czy to musi być mój pierwszy pakiet?
    • Podfolder na szablony. Heirarchia folderów odpowiadałaby hierarchii pakietów
    • Poszczególne podfoldery dla css, obrazów, js itp.
  • Główny folder zawierający appdef, indexs, main .py?

    • Podfolder na kod + szablony. W ten sposób mam klasę handler tuż obok szablonu, ponieważ na tym etapie dodaję wiele funkcji, więc modyfikacje jednego oznaczają modyfikacje drugiego. Ponownie, czy muszę, aby ta nazwa folderu była pierwszym pakietem nazwę moich zajęć? Chciałbym, aby folder miał nazwę „src”, ale nie chcę, aby moje klasy miały nazwę „src.WhateverPage”

Czy jest jakaś najlepsza praktyka? Czy z Django 1.0 na horyzoncie mogę zrobić coś, co mogę teraz zrobić, aby poprawić moją zdolność do integracji z nim, gdy stanie się oficjalnym silnikiem szablonów GAE? Po prostu zacząłbym próbować tych rzeczy i zobaczyć, co wydaje się lepiej, ale obsługa refaktoryzacji pyDev nie radzi sobie zbyt dobrze z przenoszeniem pakietów, więc prawdopodobnie nietrywialnym zadaniem będzie przywrócenie tego wszystkiego.