Michał Jędryka Prawo, informatyka i okolice

Przy dodawaniu aplikacji do settings.py należy dodać ją w postaci [nazwa_projektu].[nazwa_aplikacji]. Jeśli umieścimy tylko nazwę aplikacji, to na komputerze lokalnym jest ok, a przy podłączeniu do Apache'a - nie.

Okazuje się, że przy podczepianiu Django do Apache'a trzeba zachować sporą ostrozność. Jest tam wiele pułapek, o których tutoriale wspominają mało, albo wcale.

Na przykład dyrektywa PythonPath w konfiguracji Apache'a - zobacz tutaj dyskusja na grupie wywołana przeze mnie.

Zasoby statyczne panelu admina - http://groups.google.pl/group/django-pl/browse_thread/thread/a4e4022382f...

Po co właściwie tworzy się aplikacje?
Aplikacje w Django są jednostką mniejszą niż projekt, w tym sensie, że projekt może składać się z kilku aplikacji. W zasadzie w mniejszych projektach będzie tylko jedna aplikacja, nasuwa się więc pytanie, czy tworzenie aplikacji jest w ogóle potrzebne. Otóż można nie tworzyć aplikacji, ale wtedy nie da się korzystać z ORM Django. Jeśli więc chcemy wykorzystać bibliotekę modeli musimy stworzyć co najmniej jedną aplikację wewnątrz naszego projektu, chociaż może na początku wydaje się to sztuczne.
Nasuwa się tu pytanie drugie: po co w takim razie są projekty, czy nie mogłyby istnieć aplikacje bez projektów? Jeśli potrzebne nam kilka aplikacji, robimy kilka, jeśli jedna to jedną, a po co projekt? Odpowiedź jest prosta - projekt zawiera wspólną dla aplikacji konfigurację.

Podsumowując - aplikację tworzymy by łatwo wydzielić jakąś funkcjonalność z całego projektu (np. forum, albo galerię...). Projekt tworzymy, by zespół aplikacji korzystał z jednej bazy i jednej konfiguracji (co dla użytkownika przekłada się np. na jednokrotną autentykację dla wszystkich aplikacji projektu - dla czepialskich: wiem, że można to osiągnąć inaczej...).

Po wpisaniu modeli i próbie zarządzania nimi z poziomu modelu admina ujawniły się trzy problemy.
1. Zastosowane w verbose name polskie znaki powodowały błędy, mimo, że models.py miał deklarację kodowania w utf-8
2. Pole FileField przy próbie uploadu dawało błąd braku uprawnień. Katalog .../media/upload określony w parametrze "upload_to" miał 777, ale to nic nie dało.
3. Listy rozwijalne w panelu admina nie podawały rekordów tak jak bym chciał ;)

Rozwiązania:
ad 2
jeśli katalog do ładowania plików nazywa się np "pliki" to trzeba napisać upload_to="pliki/", a nie upload_to="/pliki/". To drugie rozwiązanie daje błąd. Jest tak chyba dlatego, że django pomija początkowe ukośniki stosując wyrażenia regularne.

ad 1. No właśnie. Te błędy wystąpiły w panelu admina. Panel admina jest bardzo czuły na wszelkie błędy w bazie danych. w przypadku bazy mysql trzeba bardzo uważać na charset i collate. Musi być utf-8. Nie wiem dlaczego, ale jeśli się tego jawnie nie zadeklaruje, to baza stworzona poleceniem create database ma jakieś szwedzkie kodowania!

Ciąg dalszy - wyjaśnienie powyżej opisanego zjawiska znajduje się tutaj. Rzeczywiście, domyślnie serwer mysqld ma ustawiony charset na latin1, a collation na latin_swedish_ci.

Żeby więc utworzyć poprawnie bazę danych dla Django należy ją tworzyć poleceniem:

CREATE DATABASE jakas_tam_baza
  DEFAULT CHARACTER SET utf8
  DEFAULT COLLATE utf8_polish_ci;

Ewentualnie można użyć utf8_general_ci. Ustawi się ono samo, gdy zrobimy DEFAULT CHARACTER SET utf8, bez określania COLLATE. Powyższe rozwiązania są sprawdzone i działają!