Django - ciągle zaskakuje

Przejście z PHP/Symfony na Python/Django wymusza inne spojrzenie na architekturę aplikacji i projektów. Na każdym kroku wyzbywam się złych przyzwyczajeń i uczę się nowej filozofii.
Dziś chcę podzielić się kilkoma istotnymi uwagami, tak z punktu widzenia newbie. Jednocześnie zaznaczam, że tekst nie jest skierowany do wyjadaczy Django, a dla ludzi przechodzących na jasną stronę mocy.

Aplikacje Django

Nie są aplikacjami w rozumieniu aplikacji Symfony. Są to swego rodzaju pluginy, które dostarczają elementów całemu projektowi. Tymi elementami (klockami) są: widoki (kontrolery), szablony, formularze, widgety, helpery, modele danych, katalogi tłumaczeń.
W przeciwieństwie do Symfony można używać ich z poziomu innych aplikacji (w końcu rozumiem termin reusable apps ;).

Projekt Django może być odpowiednikiem aplikacji Symfony, jednakże są pewne różnice. Główna to taka, że projekt może dostarczać i używać innych aplikacji.

Moje nowe projekty buduję po prostu z pakietów zawierających aplikacje Django i inne potrzebne do działania systemu pakiety/moduły.

Szablony

Nie ma potrzeby wpisywania ręcznie ścieżek do szablonów. Django ma wbudowany resolver django.template.loaders.app_directories.load_template_source, który dodaje ścieżki poszukiwań szablonów na podstawie wpisów w settings.INSTALLED_APPS (uwaga, kolejność ma znaczenie!)

Ponad to Django dostarcza loader szablonów z paczek egg django.template.loaders.eggs.load_template_source.

Batchadmin i Grappelli.

Grappeli to aplikacja modyfikująca i rozszerzająca aplikację panelu administracyjnego.
Dostarcza własne szablony przesłaniając szablony bazowe.

Gdy używałem jeszcze aplikacji batchadmin (operacje grupowe na listach), to miałem problem z pogodzeniem tych dwóch rozwiązań. Batchadmin używa własnego szablonu "batchadmin/change_list.html". Dopiero niedawno zrozumiałem, jak mogę rozszerzyć ten szablon w widoku dla moich modeli.

Rozwiązanie jest proste - należy ustawić class property "change_list_template" twojej klasy ModelAdmin na wlasny szablon, w którym umieszcza się na początku dyrektywę

{% extends "batchadmin/change_list.html" %}

Settings

W aplikacji Grappelli zauważyłem plik settings.py. Wygląda na to, że Django samo wciąga settings.py z zarejestrowanych aplikacji.

Sprawdziłem. Grappelli używa swoich ustawień z modułu grappelli.settings, a nie django.settings. Użyto ciekawej konwencji:

from django import settings

FOO = getattr(settings, 'FOO', 'bar')

Panel admina django

To jest "tylko" kolejna aplikacja, która jedynie wykonuje swoje konkretne zadanie - umożliwia przeglądanie, wyszukiwanie i modyfikację danych. Nie jest częscią Django w rozumieniu frameworka, dlatego umieszczono ją w katalogu contrib. Używa po prostu mechanizmów samego frameworka (mvc, orm, formy, walidacja, itd) do generowania widoków. Sama dostarcza
kilka widgetów, plikow css, templates i templatetags.

Dlatego nie można patrzec na nią, jak na admin-generator z Symfony, który jest jego
integralną częscią. I w koncu dlatego też można aplikacje admina
Django dowolnie rozszerzać i rozwijać - projektujesz własną aplikację panelu administracyjnego
używają aplikacji django.contrib.admin, albo jej nie używasz pisząć swoją aplikację panelu od nowa.

django.contrib

Po powyższych wnioskach sprawdziłem zawartość pakietu django.contrib. Doznałem lekkiego szoku. Zawarte są w nim ciekawe i użyteczne aplikacje. Tu wspomnę jedynie o kilku:

• flatpages - proste, edytowalne strony, jakie zwykle osadza się w prostych websites
• formtools - narzędzia do pracy z formularzami na wyższym poziomie abstrakcji, głównie wizard i podgląd formularza
• localflavor - baza krajów wg normy ISO, formattery wg locales (L10N)
• sitemaps - integracja z google sitemaps
• syndication - RSS feeds
• webdesign - dostarcza generator loremipsum :)

Życzę wszystkim sukcesów na nowej drodze!