🚀 go-pugleaf

On 13 Sie, 10:36, Michał Jędryka <michal.jedr...@gmail.com> wrote:
> On 12 Sie, 01:40, Stefan <stefan...@onet.pl> wrote:
>
> > Widzę że w django każdy ma własny sposób na strukturę katalogów w
> > projekcie, nie ma czegoś "uniwersalnego" jak w przypadku np. Ruby On
> > Rails gdzie od początku wiadomo co i gdzie ma się znaleźć.
>
> Czyżby jakiś mały flamik się szykował? ;)

Proszę, nie.

Rzeczywiście jest odczucie, że Railsy bardziej narzucają strukturę
katalogów. Dokładnie opisują gdzie mają być modele, gdzie
wido^H^H^Hkontrolery, gdzie testy (jednostkowe/funkcjonalne/
integracyjne) i gdzie szablony. Funkcjonalności niezależne (dajmy na
to, obsługa OAuth) znajdują się albo w osobnych gemach albo w
pluginach (które też mają ściśle określone miejsce w projekcie).

Teraz Dajngo: określa gdzie mają być modele, ale nie mówi czy to ma
być jeden plik, czy pakiet. Określa gdzie mają być testy, ale nie
wnika w ich strukturę w żaden sposób (musi tylko być w stanie
wyciągnąć TestCase'y z modułu). Django określa gdzie mają być
dodatkowe bajery typu template_tagi, context_procesory, polecenia
management. Django *prawie* nie określa położenia szablonów, bo
zezwala na ułożenie ich pod lokacją określoną w settingsach, w
katalogach aplikacji, czy gdzie sobie ktoś życzy. Konsekwecją tego
jest fakt, że trzeba do tych settingsów zajrzeć żeby wiedzieć gdzie są
htmle, ale robi się to raz. Oczywiście aplikacje django mogą korzystać
z zewnętrznych bibliotek (PIL).

Różnica sprowadza się do podejścia "jeden projekt z pluginami" kontra
"garść aplikacji zebranych do kupy". Nie widzę zasadniczej przewagi
któregoś z nich nad drugim.