Michał Jędryka Prawo, informatyka i okolice

Coraz częściej przygotowujemy serwisy, które z założenia mają byc dostepne w różnych językach.
Ostatnio pisałem przy okazji pewnego projektu instrukcję prostej "internacjonalizacji". Oto ona:
Krok 1
W pliku settings.py należy upewnić się, że USE_I18N jest ustawione na True (tak jest domyślnie)
Następnie należy dodać klasę LocaleMiddleware do MIDDLEWARE_CLASSES, np.:

MIDDLEWARE_CLASSES = (
    "Django.middleware.common.CommonMiddleware",
    "Django.contrib.sessions.middleware.SessionMiddleware",
    "Django.contrib.auth.middleware.AuthenticationMiddleware",

Czasem konieczne jest wyświetlenie kto jest zalogowany. Oto króciutki procesor kontekstu dla Django, który to umożliwia:

from django.contrib.sessions.models import Session
from django.contrib.auth.models import User as StandardUser
 
def whoisloggedin(request):
    sessions = Session.objects.all()
    ids = [session.get_decoded().get('_auth_user_id') for session in sessions]
    logged_in = StandardUser.objects.filter(id__in=ids)
    return {'logged_in':logged_in}

Jak wiemy, współczesne frameworki webowe, takie jak Django czy (w jeszcze większym stopniu) Ruby on Rails, opierają się na konwencjach nazewniczych. Konwencje te ułatwiają życie programiście. Na przykład w Django tworzy się klasę (model) ORM, w której to klasie nazwy pól odpowiadają nazwom kolumn w tabeli bazy danych.
Tabelę tworzy sobie Django automagicznie właśnie na podstawie zdefiniowanej klasy modelu. Na przykład:

class Product(models.Model):
    price = models.DecimalField(max_digits=8, decimal_places=2, verbose_name='cena')

Jeszcze nie przekonałeś się do Django? To wyobraź sobie, że przejąłeś słabo udokumentowany projekt internetowy po autorze i masz go ulepszać. Chcesz zmienić jakiś szczegół, np. napis.
Musisz dojść do tego skąd on się wziął. Który plik, który moduł w projekcie zawiera funkcję, która ten napis wygenerowała? Uwielbiasz to, prawda? Co to za męka, co za dramat... mówiąc słowami Tuwima!

Musiałem niedawno rozbudować pewien portal w ten sposób, że miały pojawić się w nim strony z informacjami z różnych regionów, czyli inaczej mówiąc kilkanaście serwisów newsowych w jednym. Dodatkowo wymagana była taka funkcjonalność, że wybrane wpisy miały trafiać na stronę główną. To oznaczało, że wszystkie newsy powinny być w jednej tabeli, co w Django oznacza, że w jednym modelu.
Rzecz wydawała mi się najpierw banalna.

Dotąd w zasadzie nie zastanawiałem się nad sposobem konfiguracji Apache'a w Django, stosowałem po prostu przepis z dokumentacji. Że zastanowić się warto, uświadomił mi kolega Jakub.
Zwrócił mi on uwagę, że roboty wyszukujące spodziewają się często znaleźć plik favicon.ico w głównym katalogu czyli DocumentRoot witryny.

W zasadzie archiwa miesięczne w Django robi się w sposób banalny, gdyż biblioteka Django zawiera tak zwane widoki generyczne, czyli standardowe.

Ostatnio trochę filozofowałem, czas wrócić do konkretów :).
Kto ma za sobą pierwsze kroki w Django, czyli zrobił już bloga i poznał flatpages, stanie nieuchronnie przed problemem jak zarządzać nawigacją w nieco bardziej rozbudowanym serwisie.

Jak już pisałem, postanowiłem wypróbować Django CMS.
Ustawiłem wirtualne środowisko pythona i CMS pięknie się zainstalował poprzez easy_install django-cms.
Na początek wymyśliłem, że potestuję go na sqlite. Postanowiłem pierwsze próby wykonać na aplikacji example dostarczonej razem z 'dystrybucją' django-cms.

Rozpoczynam pracę nad większym portalem. Rozważam jakie są za i przeciw pisania od początku własnego CMS-a, w stosunku do pomysłu skorzystania z gotowego rozwiązania.
Dla mnie kluczowym argumentem za pisaniem od początku jest elastyczność otrzymanego rozwiązania. Ktoś powie, że Drupal jest też elastyczny. To jest oczywiście prawda, tak samo Wordpress. Co innego jednak obiektywna elastyczność, a co innego możliwość szybkiego skorzystania z niej w przypadku, gdy potrzebne będą nowe funkcjonalności lub jakaś modyfikacja. Oczywiście najlepiej zna się kod, który się samemu napisało ;)