Mamy pl.comp.lang.ruby!

Opublikowane przez Jarosław Zabiełło Fri, 23 Jun 2006 07:13:00 GMT

Są już oficjalne wyniki głosowania na rzecz stworzenia grupy dyskusyjnej pl.comp.lang.ruby. 96 głosów za, 4 wstrzymujące się i 6 nieważnych. Nowa grupa powinna być wkrótce dostępna na serwerach usenetowych.

Posted in ,  | Tagi  | 3 comments

Django i jego konkurenci

Opublikowane przez Jarosław Zabiełło Wed, 21 Jun 2006 15:18:00 GMT

Po ostatnich paru tekstach o Django, pora na odrobinę odmiany, bo Django niekoniecznie musi być uważany za najlepszy framework w klasie środowisk “railsopodobnych”. :)

TurboGears

Trzeba pochwalić dobry marketing megaframeworku1 TurboGears, bo już w Amazonie jest nawet dostępna książka na jego temat. Jednakże, małe to pocieszenie. TurboGears raczej nie będzie poważną alternatywą dla Django z prostej przyczyny. Cały jego kręgosłup opiera się na mało profesjonalnej implementacji frameworka CherryPy. Na ten temat było sporo dyskusji na grupie pl.comp.lang.python, więc nie będę się powtarzał.

Pylons

O Pylons pisałem wcześniej ale nie w kontekście Django. Moim zdaniem, Pylons jest jedynym frameworkiem, który aktualnie może stanowić być realną alternatywę dla Django.

Wpierw trzeba napisać kilka słów wyjaśnienia dla tych, co myślą że Pylons to jakiś taki zlepek innych bibliotek i frameworków jak TurboGears. Pylons to właściwie nic innego jak framework Myghty tylko, że ze znacznie większym przełożeniem akcentów na paradygmat MVC i podobieństwo do będacych aktualnie “na fali” Railsów.

Twórcy Myghty, mimo bardzo dobrej implementacji i wydajności nie mogli wcześniej przebić się do miłośników Pythona ze względu na zbytnie podobieństwa do Perla (nic dziwnego, Myghty był wzorowany na bardzo dobrym perlowym Masonie, który jest używany na dosyć dużą skalę)

Postanowiono więc troszkę dostosować Myghty dla ludzi lubiących prostotę Pythona i elegancję Ruby on Rails. I tak powstał Pylons.

Zalety Pylonsów.

Myghty pozwala praktycznie na wymianę wszystkich swoich “podzespołów”. W wypadku Pylonsów, użyto resolvera adresów URL opartego na bibliotece Routes. W skrócie można powiedzieć, że Pylons jest tu prawie identyczne jak Rails. “Prawie”, bo Routes jest potężniejszym resolverem od tego co mają Railsy (pozwala np. na używanie większych uogólnień i wyrażeń regularnych).

Elastyczność

Elastyczność Pylonsów jest znacznie większa od Django. W praktyce tam, gdzie stosuje się wstawki PHP do profesjonalnych systemów CMS takich jak RedDot, Pylons dzięki swojej elastyczności i potędze szablonów Myghty znacznie łatwiej może wyprzeć tu PHP. Django jest systemem znacznie bardziej monolitycznym. To jest jego zaletą ale równocześnie także i wadą w wypadkach kiedy potrzebujemy znacznie większej elastyczności.

DRY w kontekście generowania adresów URL

Przewagą korzystania z Routes jest nie tylko prostota budowania adresów url bez konieczności posiadania wiedzy o wyrażeniach regularnych. Największą zaletą jest stosowanie helperów do budowania adresów URL. Identycznie jak w Railsach, jakakolwiek zmiana zasady rozwiązywania adresów, automatycznie przemapuje wszystkie adresy http we wszystkich szablonach. W wypadku Django musimy mozolnie poprawiać wszystkie szablony. W wypadku dużego serwisu jest to kupa, niepotrzebnej roboty2.

Ajax i cała reszta helperów z Ruby on Rails.

Django (jak dotąd) nie posiada wbudowanej implementacji Ajax’a. Nie ma nawet jednomyślności jaką bibliotekę do tego celu mieliby użyć3. Poza tym Pylons implementują wiele z helperów jakie mają Rails dostępne dla swoich szablonów.

Potęga szablonów Myghty

Jeśli komuś przeszkadzają małe możliwości szablonów Django (celowo takie są, bo są kierowane do nieprogramistów) to możliwości jakie dają szablony Myghty są po prostu powalające. Jeśli ktoś mówi, że Django ma dobry cache, to niech się przyjrzy temu co potrafią wykorzystywane w Pylons – szablony Myghty.

Każdy szablon może być komponentem niezależnie keszowanym wg bardzo wyrafinowanych zasad (potężniejszych od tych, co oferuje Django) Regeneracja cache jest także inteligentnie napisana (podobnie jak to robi Skunkweb) Tzn. nigdy nie ma sytuacji, kiedy nadchodzi żądanie wyświetlenia strony i w tym samym momencie trzeba odświeżyć cache (bo się np. przeterminował). Pylons w takim wypadku, odwleka operację odświeżania cache’a i podaje starą zawartość. Regeneracja następuje zaraz za tym requestem. W efekcie nigdy nie ma żadnych “czkawek” w takiej krytycznej sytuacji.

Jeśli ktoś myśli, że to bardzo rzadki przypadek, to niech sobie wyobrazi czy co się dzieje w wypadku naprawdę dużego obciążenia serwera. Pylons/Myghty był od początku tworzony z myśla pracy w sytuacji mocno obciążonego serwera.

Szablony Myghty obsługują nie tylko bardzo potężne mechanizmy includowania (tzn. można przekazać wiele różnych parametrów do includowanego szablonu włącznie z indywidualnymi zasadami keszowania). Myghty obsługują także mechanizm dziedziczenia4.

Automatyczne generowanie dokumentacji.

Pylonsy pozwalają na automatyczne generowanie dokumentacji z projektu. Wykorzystuje do tego celu pythonowe docstringi i zamiast HTML – reStructuredText (które są częścią projektu docutils)

Zapakowanie projektów do uniwersalnego formatu .egg.

Pylonsy potrafią zapakować cały projekt do paczki .egg co umożliwia bardzo łatwą dystrybucję aplikacji pylonsowych. Django tej (jakże pożytecznej) opcji w ogóle nie ma zaimplementowanej!

Zalety Django.

Mimo powyższych zalet Pylonsów, Django ma także kilka swoich, dobrych stron.

Lepsza dokumentacja.

Dzięki swojej monolityczności, Django dysponuje znacznie pełniejszą dokumentacją i jest ona zgromadzona w jednym miejscu. W wypadku Pylonsów dokumentacja jest niezbyt wyczerpująca i porozrzucana. Wynika to w głównej mierze z tego, że Pylons używa gotowych komponentów z innych projektów.

Świetna obsługa formularzy.

Django pracuje na wyższym poziomie abstrakcji odnośnie pracy z formularzami. O ile nie potrzebujemy większej elastyczności, to tą kwestię mają doskonale zaprojektowaną. Jeśli chcemy czegoś więcej, możemy przeciążyć metody jakie używa Django i wzbogacić je w dodatkowe opcje (np. obsługę zdarzeń javascript). Django obsługuje bardzo elegancko walidację formularzy. Pylons TurboGears też) korzysta z FormEncode, ale wydaje mi się, że Django jest tu jeszcze prostsze.

ORM

Djangowy korzysta z własnego ORM (mapera relacyjno-obiektowego) Pylons korzysta z SQLObject. Oba ORM’y są podobne, ale mnie się bardziej podoba ten, co ma Django. Moim zdaniem ma bardziej elegancką składnię. Ma także lepszą dokumentacje. Trochę to dziwne, bo SQLObject nie jest wcale nowym projektem. Mogliby się postarać o lepszą dokumentację, bo ta co jest, jest fatalna.

Panel admina.

To jest wizytówka Django. O ile nie potrzebujemy bardzo specyficznego jego działania, to jest bardzo pomocny. To nie jest żaden “scaffolding” z Railsów. To dopracowana aplikacja końcowa.

Generic views

To kolejna wizytówka Django. Za pomocą konfiguracji adresów (w pliku urls.py) i generic views można budować całe serwisy bez tworzenia ani jednego kontrolera. W ten sposób działa cała strona domowa Django. Osobiście głęboko nie wchodziłem w działanie tych mechanizmów, ale wyglądają bardzo interesująco i mogą daćo gromne przyśpieszenie w budowaniu stron www.

Szersze wdrożenia i silniejsze wsparcie komercyjne.

Django może się poszczycić niezła listą poważnych wdrożeń. Skala złozoności portalów zbudowanych w Django przewyższa to, czym się chwali strona domowa Railsów. Jeśli chodzi o Pylons, to wdrożeń jest bardzo mało. Może brakuje im trochę zmysłu marketingowego jaki mają twórcy Railsów i Turbogears? Na pewno brakuje lepszej, obszerniejszej dokumentacji wraz z większą ilością przykładów.

Na bazie Django oferowany jest także odpłatnie, komercyjny CMS (system zarządania treścią) – Ellington. Specjalizowany jest do większych serwisów, gazet itp. Firmy ceniące sobie wsparcie komercyjne, nie muszą się więc obawiać, że Django to jakiś projekt paru zapaleńców.

Django w rzeczy samej, jest projektem który został wyekstraktowany z komercyjnego projektu Ellington.

No i na koniec, last but not least, twórcom Django udało się pozyskać sympatię samego twórcy języka Pythona – Guido van Rossum’a. Na stronie głównej. Pythona w sekcji Web programming, obok Zope widzimy Django i Turbogears…

Podsumowanie.

Django ma swoje zalety, ale nie jest wolny od wszelkich wad. Jednakże, ogólnie rzecz biorąc, to dobry framework, który raczej nie powinien mieć trudności w zdominowaniu dziedziby budowania aplikacji internetowych w Pythonie.

Jednak tam, gdzie liczy się większa elastyczność i gdzie monolityczność Django jest nie do zaakceptowania, głównym moim faworytem jest Pylons. To jedyna realna alternatywa dla Django5.

-

1 Megaframework – środowisko zbudowane z gotowych, innych rozwiązań. Turbogears korzysta m.in. z frameworku CherryPy, szablonów Kid, SQLObject jako ORM (mapera relacyjno obiektowego).

2 Developerzy Django są przyciskani do muru żądaniami aby wprowadzić jakiś mechanizm zastępujący ręczne wpisywanie adresów, i nie wykluczają, że użyją Routes jako alternatywnego resolvera URL. Ale nie wiadomo kiedy i czy w ogóle to zrobią.

3 Nie wiem dlaczego nie chca użyć gotowych bibliotek jakie już używa Pylons. Po co odkrywać na nowo koło?

4 Dziedziczenie działa trochę inaczej niż w Django i Cheetah. Np. nie ma tu, tak wygodnych “bloków” do przeciążania. Ale jest za to coś, co przypomina “akwizycję” znaną z Zope. Tzn. w Myghty można wrzucić do folderu z szablonami plik “autohandler” i automatycznie staje się szablonem bazowym dla wszystkich szablonów (bez dotykania ich zawartości!) To pozwala na wygodne zarządzanie całymi grupami szablonów.

5 Poza oczywiście Zope czy Plone, ale to jest trochę inna bajka i temat na oddzielne rozważania. :)

Posted in ,  | Tagi , ,  | 1 comment

PyQT 4

Opublikowane przez Jarosław Zabiełło Tue, 13 Jun 2006 02:21:00 GMT

Firma Riverbank Computing ogłosiła wypuszczenie PyQT4, pythonowego wrappera do biblioteki QT4 firmy Trolltech. Wygląda to imponująco: 8 głównych modułów, 400 klas, 6 tys. metod i funkcji. Szczególnie dobre wrażenie robi Designer (do budowania GUI) Assistamnt z naprawdę ładnie przygotowana dokumentacją. QT zawsze uchodziła za bibliotekę szybką, ładną i dobrze napisaną. Jedyny wcześniejszy problem wersją 3 dotyczył konieczności opłat za użytkowanie pod Windowsami. Jednak wersja 4.x jest już w pełni open source! Czyżby rozpoczął się na dobre proces wypierania wxPythona i PyGTK?

Posted in  | Tagi ,  | 3 comments

Django - zabójcza aplikacja. Część III.

Opublikowane przez Jarosław Zabiełło Mon, 12 Jun 2006 20:29:00 GMT

W części pierwszej i drugiej opisałem podstawowe zalety Pythona i Django. Pora ma malutką demonstrację działającej aplikacji. Będzie to mała, ale poręczna wyszukiwarka biblijna (choć kod można łatwo zaadoptować do innych treści rzecz jasna). Jako bazę użyję MySQL5. Zakładam także, że docelowo projekt będzie chodził pod Linuksem. Natomiast będzie budowany i testowany pod Windowsami. Taki model pracy jest często spotykany. Django oczywiście w wersji 0.95 SVN, czyli wersji pozbawionej wcześniejszej “magii” (kod Django jest teraz bardziej jawny i oparty na standardowych mechanizmach Pythona)

Zaczynamy!

Na początku musimy stworzyć projekt oraz aplikację (Django w ramach jednego projektu potrafi obsługiwać wiele aplikacji)

admin-django startptoject myproject
cd myproject
manage.py startapp biblia

Zauważmy, że skrypt admin-django uruchamiamy tylko raz. Potem już posługujemy się skryptem manage.py. Dzięki temu odpada nam kombinowanie z definiowaniem zmiennej systemowej DJANGO_SETTINGS_MODULE. Listę wszystkich dostępny opcji, zarówno dla django-admin.py jak i manage.py, uzyskamy uruchamiając te skrypty bez żadnego parametru.

Wstępna konfiguracja.

Mamy zatem stworzony katalog z projektem i aplikacją. Wpierw trzeba skonfigurować plik settings.py2. Na początku pliku ustawiamy:
import sys

if sys.platform == 'win32':
    DEBUG = True
else:
    DEBUG = False
TEMPLATE_DEBUG = DEBUG

ADMINS = (
    ('Administrator', 'twoj@email'),
    )

MANAGERS = ADMINS

DATABASE_ENGINE = 'mysql'
DATABASE_NAME = 'myproject' 
if sys.platform == 'win32':
    DATABASE_USER = 'root'
    DATABASE_PASSWORD = ''
else:
    DATABASE_USER = 'user_na_linuksie'
    DATABASE_PASSWORD = 'haslo_pod_linuksem'

if sys.platform == 'win32':
    DATABASE_HOST = '' # domyslnie bedzie localhost
else:
    # pod linuksem zwykle korzystamy z szybkiego gniazda unix
    DATABASE_HOST = '/var/run/mysqld/mysqld.sock'
DATABASE_PORT = '' # czyli domyślnie będzie 3306

ENABLE_PSYCO = False

Kilka istotnych uwag.

  • Adres mailowy admina nie jest taki zupełnie nieistotny. W wypadku kiedy aplikacja na serwerze produkcyjnym się wyłoży na jakimś wyjątku, na ten adres jest automatycznie wysyłany mail z wszystkimi szczegółami. Trudno śledzić, czy w którymś momencie aplikacja się nie wywali. Django zadba, aby żaden taki wypadek nie umknął naszej uwadze1.
  • Należy sobie ustawić odpowiednie hasła dostępu do MySQL5 pod windozą i pod linuksem.
  • Ważne jest, aby wyłączyć obsługę akceleratora Psycho. To jeszcze nie jest dobrze przetestowane. Jak to miałem włączone, to pod Linuksem miałem problemy z działaniem djangowego panelu admina.
  • Musimy ręcznie sobie stworzyć (jeśli tego nie zrobiliśmy) bazę. Django za nas bazy nie stworzy. W naszym przypadku, tabelkę na której będziemy pracować mam już gotową w bazie. Tu jest jej spakowany dump który trzeba sobie załadować.

Pozostałe ustawienia:

LANGUAGE_CODE = 'pl' # domyślnie był angielski
#... 
if sys.platform == 'win32':
    MEDIA_ROOT = r'H:/home/myproject/biblia/public'
else:
    MEDIA_ROOT = r'/home/myproject/biblia/public'
#... 
INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'myproject.biblia',
)

Do słownika INSTALLED_APPS musimy dodać naszą aplikację aby można było jej używać. Mówi o tym ostatnia linijka powyższego kodu. Zmienna MEDIA_ROOT musi być bezwzględną ścieżką do plików statycznych. Pod serwerem www odpowiada to zmiennej DOCUMENT_ROOT, czyli miejsca od którego serwer www cokolwiek widzi.

Interaktywne testowanie Django z poziomu konsoli.

W każdej chwili możemy odpalić interaktywny dostęp do środowiska Django za pomocą komendy:
manage.py shell
Warto sobie wcześniej zainstalować ipythona, bo Django domyślnie próbuje uruchomić jego zamiast standardowy interpreter. Dzięki ipythonowi mamy wspaniałe uzupełnianie metod do obiektów + historia wczesniejszych operacji, która nie znika wraz z zamknięciem ipythona.

Serwer.

Możemy odpalić wbudowany serwer www za pomocą komendy:

manage.py runserver

Domyślnie serwer się podniesie pod adresem http://127.0.0.1:8000. Można zmienić zarówno port jak i adres jak ktoś chce, rzecz jasna. Odpal manage.py (bez parametrów) to się dowiesz, jak.

ORM

No dobrze, pora na coś bardziej interesującego. Django operuje na relacyjnej bazie danych za pomocą swojego ORM (mapera relacyjno-obiektowego) Zalet takiego podejścia jest wiele. Wspomnę tylko o tym, obiektowo można znacznie lepiej opisać dane modelu biznesowego niż to zrobić może czysty SQL ze swoimi kluczami obcymi i trigerami. Django wymaga aby w pliku myproject/biblia/models.py zdefiniować dane dla ORM’a. Zasada jest prosta: klasa odpowiada tabeli, a atrybuty klasy – jej polom. Aby jednak sobie uprościć życie, można posłużyć się skryptem manage.py.

Poniższy skrypt robi introspekcję bazy i wygeneruje pythonowe definicje wszystkich jej tabel. Jako parametr podajemy nazwę naszej aplikacji (mówiłem że Django jest zbudowane do pracy z wieloma aplikacjami w ramach projektu) Możemy spokojnie zamazać plik models.py bo po stworzeniu projektu nic tam szczególnego nie ma.

H:\home\myproject>manage.py inspectdb biblia > biblia/models.py

Mamy zatem naszą wstępną obiektową definicję dla nasej tabelki:

from django.db import models

class BibliaGdanska(models.Model):
    id = models.IntegerField(primary_key=True)
    ref = models.CharField(unique=True, maxlength=9)
    chapter_nr = models.IntegerField(unique=True)
    verse_nr = models.IntegerField(unique=True)
    verse = models.TextField()
    class Meta:
        db_table = 'biblia_gdanska'

Może sprawdźmy, czy to działa za pomocą interaktywnej konsoli:

H:\home\myproject>manage.py shell
Deleting alias <dir>, it's a Python keyword or builtin.
Python 2.4.3 (#69, Apr 11 2006, 15:32:42) [MSC v.1310 32 bit (Intel)]
Type "copyright", "credits" or "license" for more information.

IPython 0.7.1.fix1 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]: from myproject.biblia.models import BibliaGdanska
In [2]: BibliaGdanska.objects.count()
Out[2]: 31151L

Bingo! Widać, że działa.

Kontroler i szablon.

Teraz pora na naszą aplikację internetową. Musimy stworzyć kontroler. Z tajemniczych powodów developerzy Django zamiast MVC (model-view-controller) stosują nazwę MTV (model-template-view). W każdym razie, to co zwykle nazywamy kontrolerem oni nazywają widokiem (view) a to co nazywamy widokiem, oni nazywają szablonem. Mniejsza o nazwy. Kontroler tworzymy w pliku myproject/biblia/views.py

#-*- coding: utf-8 -*-

from django.shortcuts import render_to_response

def home(request):
    return render_to_response('home.html')

Plik home.html jest szablonem. Stwórzmy na razie ten plik z napisem “alama kota” w środku, aby zobaczyć, czy to działa. Plik powinien leżeć w myproject/biblia/templates/home.html.

Rozwiązywanie adresów URL

Wpierw musimy powiedzieć Django aby wiedział, gdzie ma szukać naszego kontrolera. W tym celu dodajmy taką treść do pliku myproject/biblia/urls.py

from django.conf.urls.defaults import *
from settings import DEBUG, MEDIA_ROOT

urlpatterns = patterns('',
    (r'', include('myproject.biblia.urls')),
    #(r'^admin/', include('django.contrib.admin.urls')),
)

if DEBUG:
    urlpatterns += patterns('',
        (r'^images/(?P<path>.*)$', 'django.views.static.serve', {'document_root': MEDIA_ROOT+'/images', 'show_indexes': True}),
        (r'^stylesheets/(?P<path>.*)$', 'django.views.static.serve', {'document_root': MEDIA_ROOT+'/stylesheets', 'show_indexes': True}),
        (r'^javascripts/(?P<path>.*)$', 'django.views.static.serve', {'document_root': MEDIA_ROOT+'/javascripts', 'show_indexes': True}),
    )    

Powyższy kod robi kilka rzeczy.

  • Wiąże domyślną stronę z naszym projektem. Wejście na http://127.0.0.1:8000/ przekaże sterowanie do pliku myproject/biblia/urls.py (który za chwilkę stworzymy).
  • Takie podejście powoduje że każda aplikacja może posiadać swoje niezależne zasady rozwiązywania adresu url. Dlatego oddelegowujemy obsługę URL’i do pliku urls.py wewnątrz naszej aplikacji.
  • Zakomentowaną linijkę z panelem admina na razie zostawmy, wrócę do tego później.
  • Ostatnie linijki są potrzebne do tego, aby Django obsługiwał nie tylko plik Pythona ale także obrazki, style kaskadowe i skrypty języka JavaScript. Przyjąłem (wzorując się na Railsach) że są one odpowiednio w folderach myproject/biblia/public/images, myproject/biblia/public/stylesheets i myproject/biblia/public/javascripts.
  • Dlaczego ten kod jest dostępny tylko dla DEBUG=True? Ano dlatego, że do pracy developerskiej pod windozą nie potrzebujemy żadnego Apache’a ani Lighttpd. Wystarczy wbudowany serwer www jaki dostarcza Django. Natomiast na serwerze produkcyjnym, gdzie chcemy uzyskać największą wydajność, lepiej aby te pliki podawał serwer www i Django się tego nie dotykało. Tak będzie najlepiej i najszybciej.

Pozostał do skonfigurowania plik myproject/biblia/urls.py

from django.conf.urls.defaults import *

urlpatterns = patterns('myproject.biblia.views',
    (r'^$', 'home'),
   #(r'^admin/', include('django.contrib.admin.urls')),
)

Tu również mamy zakomentowany panel admina. Zostawmy go na razie w spokoju. Można uruchamiać: http://127.0.0.1:8000/ powinno wyświetlić nasz szablon z treścią “ala ma kota”. No to może lepiej aby wyświetlić coś bardziej atrakcyjnego. Zbudujmy formularz.

Formularz

Formularze są zmorą większości programistów. Są upierdliwe w obłudze, walidacji i co gorsze, ciągle z nimi mamy do czynienia. Aby ułatwić nam życie, Django stosuje specjalną technikę tzw. manipulatorów, aby praca z formularzami była miła i przyjemna. Muszę przyznać, że to była jedna z ważniejszych rzeczy, jaka mnie przyciągnęła do Django. Pylons i Rails mają swoje helpery, ale nie są one aż tak wygodne jak to, co oferuje Django3.

Zobaczmy jak się używa manipulatora. Wpierw zmieńmy nasz szablon (plik: myproject/biblia/templates/home.html). Będzie to prosty formularz z jednym polem gdzie wpiszemy wyszukiwane słowo.

<form method="get" action="">

    {% if form.q.errors %} 
        <div class="formError">
          Wpisz frazę o długości min. 3 znaków.
        </div>
    {% endif %}

    {{ form.q }}
    <input type="submit" value="szukaj" />

</form>

Manipulator.

Teraz pora na manipulator. Musimy stworzyć plik myproject/biblia/manipulators.py o przykładowej treści:

import re
from django import forms
from django.core import validators

class SzukajManipulator(forms.Manipulator):
    def __init__(self):
        regex = re.compile(r'(\w{3,})', re.U)
        self.fields = (
            forms.TextField(
                field_name='q',
                length=30,
                maxlength=255,
                is_required=True,
                validator_list=[validators.MatchesRegularExpression(regex)]
                ),
            )

Teraz zepnijmy wszystko razem w djangowym widoku (naszym kontrolerze). Zmieńmy treść pliku myproject/biblia/views.py na:

#-*- coding: utf-8 -*-

from django.shortcuts import render_to_response
from django import forms
from manipulators import SzukajManipulator
from models import BibliaGdanska

def home(request):
    recordset = []
    errors = _GET = {}
    manipulator = SzukajManipulator()
    # tworzę kopię parametrów przekazanych z formularza
    _GET = request.GET.copy()
    if request.GET:
        # sprawdzam czy formularz nie ma błędów
        errors = manipulator.get_validation_errors(_GET)
        if not errors:
            manipulator.do_html2python(_GET)
           # wyszukuję cytaty 
           recordset = BibliaGdanska.objects.all().filter(verse__icontains=_GET['q'])
    form = forms.FormWrapper(manipulator, _GET, errors)
    return render_to_response(
        'home.html',
        {'request': request,
         'form': form,
         'recordset': recordset,
         'hits': len(recordset)})

Wyświetlenie wyników.

Aplikacja działa4, ale nie widać wyników. Wyniki wyświetlimy w tym samym szablonie. Teraz będzie wyglądał tak:

<form method="get" action="">
    {% if form.q.errors %} 
        <div class="formError">
          Wpisz frazę o długości min. 3 znaków.
        </div>
    {% endif %}    
    {{ form.q }}
    <input type="submit" value="szukaj" />   
</form>

{% if recordset %}
    <div>
      Znaleziono <b>{{ hits }}</b> wersetów:
    </div>
    <ol>
    {% for row in recordset %}
        <li>
            {{ row.ref}} {{ row.chapter_nr}}:{{ row.verse_nr }} 
            &quot;{{ row.verse }}&quot;
        </li>
    {% endfor %}
    </ol>
{% else %}
    Nie znaleziono wersetów dla frazy {{ request.GET.q }} :(
{% endif %}

Program powinien działać. Jednak w wypadku znalezienia mniej niż 5 wersetów niezbyt po polsku zabrzmi wynik, np. “Znaleziono 1 wersetów”. W wypadku języka angielskiego możemy zmodyfikować ten fragment szablonu za pomocą modyfikatora pluralize5. Polski jezyk jest jednak znacznie bardziej wyrafinowany od angielskiego, bo używa 2 różnych form dla liczby mnogiej: 1 werset, 2 wersety, 5 wersetów. Na szczęście możemy sobie zmienić sposób pracy tego modyfikatora.

Przeciążene modyfikatora

Aby nadpisać istniejący modyfikator lub dodać nowy, własny, należy stworzyć wpierw folder myproject/biblia/templatetags z pustym plikiem o nazwie init.py. Dodajemy tam drugi plik, o nazwie, powiedzmy: plugins.py o następującej treści:

import re, sys
from django import  template

register = template.Library()

@register.filter(name='pluralize')
def pluralize(value):
    """Polish implementation"""
    try:
        if int(value) in (2,3,4):
            return 'y'
        elif int(value) >= 5:
            return '\xc3\xb3w' # utf8
    except ValueError: # invalid string that's not a number
        pass
    except TypeError:
        try:
            if int(value) in (2,3,4):
                return 'y'
            elif int(value) >= 5:
                return '\xc3\xb3w' # utf8            
        except TypeError: 
            pass
    return ''

Zamiast polskiego znaczka ó, użyłem zapisu ’\xc3\xb3’ bo to wartość utf-8 i taki zapis jest niezależny od tego, w czym otworzymy plik. Nikt przypadkowo nie popsuje nam polskich ogonków.

Aby to zadziałało, musimy gdzieś na początku w szablonie dodać linijkę, która załaduje nam nową definicję modyfikatora pluralize.

{% load plugins %}

Kontekst i dziedziczenie szablonów.

Nasz kod działa, ale kod HTML jest daleki od doskonałości. Dobrze byłoby dodac jakiś nagłówek, stopkę itp. Django skopiowało z pythonowych szablonów Cheetah bardzo ciekawy sposób tworzenia kolejnych szablonów za pomocą obiektowego przeciążania starych.

Stwórzmy nasz szablon bazowy (myproject/biblia/templates/base.html)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    <head>
        <title>Przykład aplikacji w Django</title>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    </head>
    <body>    
         <h3>Wyszukiwarka Biblii Gdańskiej</h3>
         <h4> (przykład aplikacji w Django)</h4>
          <div id="main">
          {% block main %}
              tutaj będzie jakaś nowa treść   
          {% endblock %}
          </div>
        <hr size="1" />
        <div>
        &copy; 2006 
        <a href="http://blog.zabiello.com">Jarosław Zabiełło</a>. 
        </div>
    </div>
</body>
</html>

Ostatecznie szablon home.html będzie więc wyglądał tak:

{% extends "base.html" %}

{% load plugins %}

{% block main %}

<form method="get" action="">
    {% if form.q.errors %} 
        <p class="formError">Wpisz frazę o długości min. 3  "znaków".</p>
    {% endif %}    
    {{ form.q }}
    <input type="submit" value="szukaj" />   
</form>

{% if recordset %}
    <div>Znaleziono <b>{{ hits }}</b> werset{{ hits|pluralize }}:</div>
    <ol>
    {% for row in recordset %}
        <li>
            {{ row.ref}} {{ row.chapter_nr}}:{{ row.verse_nr }} 
            &quot;{{ row.verse }}&quot;
        </li>
    {% endfor %}
    </ol>
{% else %}
    <p>Nie znaleziono wersetów dla frazy <b>{{ request.GET.q }}</b></p>
{% endif %}

{% endblock %}

Szablon oparty na innym szablonie implementuje dowolne bloki z poprzedniego. Cały pozostały kontekst jest automatycznie dziedziczony. Takie podejście bardzo skraca wielkość szablonów i czyni je jeszcze bardziej czytelnymi.

Podświetlanie szukanej frazy.

Do pliku plugins.py gdzie wcześniej zmieniliśmy definicję modyfikatora pluralize, dodajmy kolejny. Będzie nam podświetlał w wersetach to, co szukamy.

@register.filter(name='highlight')
def highlight(s, q):
    if not isinstance(s, unicode): 
        s = unicode(s, 'utf-8')
    s = re. compile('('+re.escape(q)+')', re.U|re.I).sub(r'<strong class="highlight">\1</strong>', s).encode('utf-8')
    return s    
W środku zastosowano sztuczkę z przełączeniem się na obiekty Unicode, aby mieć pewność że polskie ogonki duże i małe będą tak samo traktowane. W szablonie home.html wystarczy zmienić jedną linijkę:
{{ row.verse|highlight:request.GET.q }}

Co dalej?

Mam nadzieję, że artykuł przybliżył trochę praktyczną stronę uzywania Django. To dobry i szybki framework. Przykładowe serwisy jakie w nim napisano są znacznie bardziej skomplikowane i większe niż te, co widać na stronie Rails. Django został napisany do szybkiego tworzenia całkiem sporych serwisów

W kolejnym artykule, pokażę jak sobie wygodnie skonfigurować panel admina który udostępnia Django. Panel admina nie jest żadnym prostym rusztowaniem (scaffolding) do modyfikacji bazy. To kompletna aplikacja dla użytkownika końcowego. Bardzo wygodna i łatwa w użyciu. Panel Django jest kolejną z jego cech, która daje mu wyraźną przewagę w stosunku do konkurencji.

-

1 Kompletnie inaczej od 99% aplikacji pehapowych, gdzie o błędach dowiadujemy się najczęściej dopiero wtedy, jak wszystko leży, albo jak ktoś łaskawie nas poinformuje.

2 Jak widać, to normalny plik Pythona. Żadne chore XML i inne formaty nie są w ogóle nam potrzebne – Python jest wystarczająco dobry, aby łatwo i przyjemnie prezentować zagnieżdżone struktury. Inne języki, jak np. Java nie zbyt dobrze nadają się do takich rzeczy, dlatego muszą posiłkować się XML.

3 Tzn. Railsy się już poprawiły, bo jest plugin który dodaje im taką samą funkcjonalność jak Django. Nazywa się active-form i można go zainstalować prosto spod RadRails’a.

4 Kto nie wierzy, niech sobie wpisze print recordset po operacji wyszukiwania. Na konsoli serwera www wyświetli mu się zawartość tej zmiennej.

5 Szablony Django korzystają ze składni modyfikatorów podobnych do pehapowych Smartów.

Posted in ,  | Tagi  | 8 comments

pl.comp.lang.ruby - głosowanie rozpoczęte!

Opublikowane przez Jarosław Zabiełło Sat, 03 Jun 2006 14:03:00 GMT

Po długim okresie oczekiwań w końcu doczekaliśmy się rozpoczęcia głosowania nad stworzeniem grupy pl.comp.lang.ruby. Oczywistą zaletą grupy newsowej jest m.in. to, że jest indeksowana i archiwizowana przez Google oraz jest bardziej odporna na “pady” serwera, bo posty są replikowane po wielu serwerach. Formalna treść ogłoszenia (wraz z informacją o sposobie głosowania) jest dostępna tutaj…

Posted in ,  | Tagi  | brak comments