PHP i Python – środowisko developerskie

27 maja 2016

Jakiś czas temu zacząłem pracować dla klienta, który realizuje swój projekt w oparciu o koncepcję mikroserwisów Martina Fowlera. Nowe serwisy pisane są w Pythonie ale utrzymanie i dalszy rozwój starszych częściej architektury wymaga znajomości języka PHP. Mam ponad pięcioletnie, ciągłe doświadczenie w programowaniu w PHP, ale sięga ono czasów kiedy użycie JavaScriptu na serwerze wydawało się być pomysłem absurdalnym, kiedy konto na Naszej Klasie było tak powszechne jak dziś profil na Facebooku, a na współdzielonych hostingach królowało PHP w wersji 5.3, która zasłynęła m.in z wprowadzenia instrukcji goto.

Odkąd porzuciłem PHP na rzecz Pythona nie tylko zacząłem tworzyć bardziej pythoniczny kod, ale wzbogaciłem też swój warsztat deweloperski o nowe narzędzia, praktyki i metodologie. Po tych kilku latach patrzę już na PHP przez pryzmat doświadczeń zdobytych w trakcie programowania w innych językach. Nie dawno miała miejsce premiera PHP w wersji 7, która zbiera dobre recenzje i ma rewelacyjne wyniki w benchmarkach. Postanowiłem zapoznać się z tą nową odsłoną – dla mnie zapomnianego już lekko – języka. Pierwsza krok jaki musiałem wykonać to instalacja najnowszej wersji PHP na komputerze.

PHPbrew

Dwie wersje Pythona 2 i 3 zainstalowane równolegle w systemie to standard jednak chcąc mieć możliwość skorzystania z mniej popularnych wersji warto posłużyć się dodatkowym oprogramowaniem takim jak pythonz będącego forkiem nie wspieranego już projektu pythonbrew, który oficjalnie odsyła do pyenv (nie mylić z pyvenv, o którym za chwilę).

PHP ma swój odpowiednik pythonbrew – PHPbrew. Instalacja tego narzędzia jest bezproblemowa i szczegółowo opisana na stronie projektu http://phpbrew.github.io/phpbrew/ więc nie będę jej powielał. Po instalacji PHPbrew możemy przystąpić do instalacji samego PHP w różnych wersjach. Podobnie jak analogiczne narzędzia Pythona – PHPbrew do zainstalowania PHP oraz jego rozszerzeń wymaga także zadbania o zależności. Ja np. spotkałem się z komunikatem configure: error: Please reinstall readline – I cannot find readline.h, który w uprzejmy sposób poinformował mnie o konieczności doinstalowania pakietu deweloperskiego redline

sudo aptitude install libreadline-dev
phpbrew install php-5.5.9

albo instalacji PHP bez obsługi tego rozszerzenia np w wersji 7.

phpbrew install php-7.0.6 -readline

Przełączenie się na wybraną wersję PHP wymaga wydania prostej komendy w konsoli:

phpbrew use php-7.0.6

Od tej chwili możemy rozpocząć pracę z wybraną wersją PHP w konsoli lub też odpalić wbudowany w PHP od wersji 5.4 serwer, a po zakończeniu pracy wrócić do domyślnie zainstalowanej w systemie wersji.

phpbrew off

virtPHP

Zarówno Python, jak i PHP stale się rozwijają. Wciąż dochodzą mniejsze lub większe usprawnienia, pojawiają się nowe rozszerzenia, biblioteki, moduły. Przełomowe zmiany, takie jak w przypadku wydania siódmej odsłony PHP następują stosunkowo rzadko, a co za tym idzie mechanizmy zarządzania wersjami danego języka w systemie przydają się sporadycznie. O wiele częściej deweloperzy spotykają się z potrzebą konfiguracji środowiska deweloperskiego dobraną specjalnie pod dany projekt.

Python ze swoim wirtualnym środowiskiem virtualenv trochę mnie rozpieścił jako dewelopera. Virtualenv lub też jego funkcjonalny następca – wbudowany w Pythona 3 moduł pyvenv pokazał mi że praca nad różnymi aplikacjami, wymagającymi często odmiennego zestawu bibliotek i konfiguracji może być łatwa i przyjemna.

Instalacja, utworzenie wirtualnego środowiska – w tym wypadku w katalogu projektu – i uruchomienie go poprzez wywołanie skryptu, który ustawia wszelkie zmienne środowiskowe.

sudo apt-get install python-virtualenv
cd ~/my_project/
virtualenv .ve
source .ve/bin/activate

Do wersji 3.3 Pythona zalecane jest używanie virtualenv zamiast pyvenv bo dopiero w wersji 3.4 pyvenv ma wbudowanego menagera pakietów pip umożliwiającego łatwą instalację zależności.

pip install django

Pip umożliwia zrzucenie listy zainstalowanych pakietów do pliku dzięki czemu możliwe jest np. zachowanie konfiguracji wirtualnego środowiska w repozytorium Git

pip freeze > requirements.txt

i późniejsze jego odtworzenie na innej maszynie.

pip install -r requirements.txt

Komfort pracy, jaki daje wirtualne środowisko jest nie do przecenienia. W katalogu projektu mamy tylko i wyłącznie pliki projektu. Wszystkie zależności – niezbędne moduły i biblioteki dostarczane przez zewnętrznych developerów trzymane są w odmiennej lokalizacji i jedyne czego potrzebujemy do odtworzenia środowiska niezbędnego do uruchomienia projektu jest plik requirements.txt. Python dał mi zupełnie odmienne doświadczenie w tej kwestii w stosunku do projektów realizowanych w PHP gdzie wszelkie zależności – nie licząc wbudowanych funkcji języka oraz wkompilowanych w niego rozszerzeń – były trzymane, najczęściej w podkatalogu „vendors” i razem z plikami projektu do repozytorium pchane były całe feameworki i inne rozbudowane biblioteki, ewentualnie zaciągane zewnętrzne repozytoria.

Jak wspomniałem przez ostatnie lata nie obcowałem z PHP zbyt intensywnie więc szukałem funkcjonalnego odpowiednika virtualenv. Znalazłem virtPHP. Twórcy virtPHP nie ukrywają, że wzorowali się na swym pythonowym odpowiedniku starając się stworzyć narzędzie równie łatwe a nawet podobne w użyciu. Biblioteka ta nie została jeszcze ustabilizowana. Ostatnia póki co wersja virtPHP 0.5.2-alpha jest dedykowana jedynie na systemy unixopochodne. Trochę martwi brak aktywności developerów przez ostatni rok – nie mniej zachęcam do wypróbowania możliwości wirtualnych środowisk w PHP.

Kiedy już uporamy się z zainstalowaniem virtPHP, możemy przystąpić do utworzenia pierwszego wirtualnego środowiska dla projektu w PHP.

cd ~/my_php_project/
php virtphp.phar create .my-ve
source .my-ve/bin/activate

VirtPHP można łaczyć także z PHPbrew

php virtphp.phar create --php-bin-dir="/home/user/.phpbrew/php/php-5.5.9/bin" .my-ve

Od tej chwili można instalować biblioteki z repozytoriów PECL i PEAR

pecl install mongo
pear install pear.phpunit.de/PHPUnit

Potencjał tego narzędzia oceniałbym jako wysoki gdyby nie problem z repozytoriami PHP. PECL to repozytorium rozszerzeń PHP napisanymi w języku C. Trudno mi ocenić jego aktualność – zwłaszcza w związku z wydaniem wersji PHP 7. PEAR to biblioteki napisane w PHP tyle, że to staroć nieuaktualniany o nowe wydania bibliotek (np. Symfony Framework). Ponieważ trzymanie zależności w podkatalogu „vendor” stało się powszechnie stosowaną praktyką w świecie PHP popularność zdobył sobie menadżer zależności, który niejako podtrzymał tradycję.

Composer

Menadżer zależności Composer może być uruchomiony w kontekście wirtualnego środowiska virtPHP co niesie ze sobą dodatkowe korzyści, ale równie dobrze może być używany niezależnie. Koncepcyjnie Composerowi najbliżej do npm znanego z Node.js.

Instalacja Composera sprowadza się do ściągnięcia pliku composer.phar do katalogu głównego projektu.

cd ~/my_php_project/
php -r "readfile('https://getcomposer.org/installer');" | php

Zależności są instalowane w podkatalogu vendors.

php composer.phar require monolog/monolog
php composer.phar require twig/twig

natomiast w katalogu głównym tworzone są trzy pliki:

./vendors/autoload.php
./composer.json
./composer.lock

Plik composer.json, zawiera bieżącą konfigurację zależności.

{
    "require": {
        "monolog/monolog": "^1.19",
        "twig/twig": "^1.24"
    }
}

Z kolei w pliku composer.lock – również w formacie json – zapisane są szczegóły na temat zainstalowanych paczek i ich wersji. Tan plik jest bardzo rozbudowany. W repozytorium kodu zalecane jest przechowywanie obu plików, gdyż w przypadku próby odwzorowania konfiguracji na innej maszynie,

php composer.phar install

polecenie composer install korzysta właśnie z pliku composer.lock i dopiero w przypadku jego braku, z konfiguracji zapisanej w composer.json, ale wtedy nie ma pewności, że dostaniemy dokładnie taki sam wynik.

Deweloperzy PHP są leniwi jak przystało na każdego szanującego się programistę i unikają pisania zbędnego kodu związanego z dołączaniem wymaganych klas i funkcji. Mają do dyspozycji autoloader. Sam byłem zakochany w koncepcie autoloadera dopóki nie zacząłem na full etat kodować w Pythonie. Okazało się, że importy są całkowicie wystarczające a do tego stanowią jeden z aspektów samodokumentującego się kodu. Jeśli unikasz tzw. importowania z gwiazdką, nie potrzebujesz zaawansowanego IDE aby wiedzieć, gdzie co jest i czego możesz się spodziewać w danym module. Pythonowcy nie wiedzą co to autoloader. PHP-owcy nie potrafią bez niego żyć tak więc Composer wspiera również ten mechanizm. Po zainstalowaniu zależności w katalogu vendors generowany jest plik autoload.php, który wystarczy tylko zaimportować.

require __DIR__ . '/vendor/autoload.php';

PHP przez wiele lat królowało na współdzielonych hostingach dając PHP dużą przewagę nad innymi językami skryptowymi używanymi w web developmencie. Wystarczyło połączenie FTP do przesłania plików na serwer i początkujący webmaster mógł się cieszyć z działającej strony www. Composer wymaga dostępu do shella tak więc z pełni jego zalet będą cieszyć się osoby pracujące nad serwisami publikowanymi na kontach z dostępem przez ssh np. na VPN-ach albo serwerach dedykowanych.

Docker

Przez ostatnie parę lat mocno rozwinęła się wirtualizacja. Deweloperzy bardzo chętnie sięgają dziś po narzędzia typu Vagrant lub Docker, które umożliwiają utworzenie niemal całkowicie odseparowanego środowiska deweloperskiego, niezależnego od konfiguracji komputera programisty, dającego się przenieść na inną maszynę. W kontenerze można dziś zamknąć zarówno aplikacje pisane w PHP, Pythonie jak i w wielu innych językach programowania więc to nie czyni różnicy między nimi. Docker ma ogromne możliwości, których nie zamierzam tutaj opisywać. Jest to temat na grubą książkę. Chcę jedynie zaprezentować przykład podstawowego użycia kontenera, w którym zamknięte jest PHP w wersji 7 do sprawdzenia możliwości nowej odsłony tego języka.

PHP ma swoje oficjalne obrazy w repozytorium Dockera i w domyślnej konfiguracji, wraz z pełni funkcjonalnym Apachem daje się uruchomić po wydaniu zaledwie dwóch komend .

docker pull php:7.0.6-apache
docker run -p 8080:80 -v "~/my_php_project":/var/www/html --name my-php7-container php:7.0.6-apache

Po wrzuceniu pliku do katalogu my_php_project

echo '<?php phpinfo();' > ~/my_php_project/info.php

I wybranie w przeglądarce adresu

localhost:8080/info.php

możemy obejrzeć sobie konfigurację PHP 7.

Naturalnie trzeba mieś już zainstalowanego i skonfigurowanego Dockera. Warto ten wysiłek podjąć i rozpocząć przygodę z kontenerami. Już najprostsze przypadki użycia są przydatne i wcale nie trzeba pracować nad wielkim projektem o rozbudowanej architekturze aby docenić zalety konteneryzacji. Choć rozwiązanie to nie jest bez wad – obrazy Dockera sporo ważą, a uruchomione instancje zabierają sporo zasobów będąc bądź co bądź pełnoprawnymi systemami – w zamian dostajemy odseparowane pudełko, w którym możemy zamknąć np. wersję 2.4 blendera, która jako ostatnia obsługuje skrypty pisane w Pythonie 2.

Każdy człowiek ucząc się nowej rzeczy czerpie ze swoich dotychczasowych doświadczeń. Programiści rozpoczynający pisanie oprogramowania w nowym dla nich języku starają się zorganizować swój warsztat pracy w sposób, który jest im znany. Udaje się to mniej lub bardziej bo każdy język programowania ma swoją specyfikę uwarunkowaną przyjętymi założeniami, filozofią, techniczną implementacją i wypracowaną praktyką. To co jest przyjęte za standard w jednej technologii w innej może być uważane za niemile widziane. Sztuką jest dostosować się i nauczyć poprawnie każystać z dedykowanych narzędzi. Zarówno PHP, jak i Python umożliwiają organizację pracy dewelopera w sposób umożliwiający łatwe przełączanie się pomiędzy różnymi projektami posiadającymi swoją konfigurację i zależności. Choć robią to w nieco odmienny sposób w mojej ocenie wygoda rozwiązań stoi na porównywalnym poziomie.

Upload plików w Django

9 marca 2013

Upload plików w Django

W Django nie zapomniano o kwestii uploadu plików. Deweloperzy tego frameworka starali się uczynić tę czynność jak najprostszą mimo to prawidłowa realizacja tego zadania wymaga odrobiny wysiłku. Na początek przytoczę znaleziony na stackoverflow.com minimalny przykład prezentujący krok po kroku jak w Django pobrać od użytkownika plik i zapisać go na serwerze. Będzie on stanowił doskonały punkt wyjścia dla bardziej zaawansowanych tematów jak dbanie o równomierny rozkład plików w katalogach czy przycinanie obrazków w panelu administracyjnym z użyciem jQuery i jCrop, którymi to tematami zajmę się w kolejnych wpisach.

Poniższy opis oparty jest na przykładzie, którego źródło można ściągnąć z github-a

Przykład bazuje na Django 1.3 w którym główny plik settings.py i urls.py trzymane są w katalogu głównym projektu.

minimal-django-file-upload-example/
    src/
        myproject/
            database/
                sqlite.db
            media/
            myapp/
                templates/
                    myapp/
                        list.html
                forms.py
                models.py
                urls.py
                views.py
            __init__.py
            manage.py
            settings.py
            urls.py

W Django 1.4 nastąpiła zmiana w domyślnej strukturze projektu i wyżej wspomniane pliki powinny trafić do podkatalogu o nazwie odpowiadającej nazwie projektu.

1. Konfiguracja: /myproject/settings.py

Przede wszystkim należy zacząć od prawidłowej konfiguracji bazy danych ponieważ szczegółowa ścieżka do pliku zapisywana będzie w bazie danych, mediów – czyli wskazania katalogu w projekcie, do którego będą trafiały wszystkie wgrywane przez użytkowników pliki oraz URL-a zarezerwowanego na potrzeby serwowania plików statycznych. Trzeba też pamiętać aby aplikacja zawierająca model ze zdefiniowanymi polami do uploadu plików była dodana do INSTALLED_APPS.

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': '/path/to/myproject/database/sqlite.db'),
        'USER': '',
        'PASSWORD': '',
        'HOST': '',
        'PORT': '',
    }
}

MEDIA_ROOT = '/path/to/myproject/media/'
MEDIA_URL = '/media/'

INSTALLED_APPS = (
 …
 'myapp',
)

Więcej na temat konfiguracji mediów i plików statycznych w Django.

2. Model: myproject/myapp/models.py

Do uploadu plików w modelu Django służy pole FileField lub też jego specjalna wersja dla obrazków ImageField. Oba z wymienionych pól mają atrybut „upload_to” umożliwiający wskazanie szczegółowej lokalizacji składowania pliku.

# -*- coding: utf-8 -*-
from django.db import models
 
class Document(models.Model):
    docfile = models.FileField(upload_to='documents/%Y/%m/%d')

Jeśli ustawimy upload_to=’documents/%Y/%m/%d’ to w katalogu określonym w zmiennej MEDIA_ROOT zostanie utworzona ścieżka oparta na bieżącej dacie np. „documents/2013/03/09”.

Atrybutowi „upload_to” możemy przypisać zarówno tekst, jak i też metodę czy funkcję zwracającą ścieżkę do katalogu, co daje nam większe możliwości, ale jest to kwestia bardziej złożona i omówię ją przy innej okazji.

3. Formularz: myproject/myapp/forms.py

Wykorzystanie obiektów formularzy w Django bardzo ułatwia pracę z formularzami o czym przekonałem się wielokrotnie. Także w tym przypadku najprościej jest użyć ModelForm – czyli formularza opartego na modelu, w którym nie trzeba definiować pól formularza tylko wskazać na jakim modelu dany formularz ma się opierać i które pola mają podlegać edycji. Przytaczany tu przykład jednak pokazuje jak stworzyć zupełnie niestandardowy formularz z wykorzystaniem kontrolki pola do uploadu pliku FileField. UWAGA! – nie należy mylić pól modelu z polami formularza, które mimo podobieństwa nazwy są czymś innym.

# -*- coding: utf-8 -*-
from django import forms
 
class DocumentForm(forms.Form):
    docfile = forms.FileField(
        label='Select a file',
        help_text='max. 42 megabytes'
    )

4. Widok: myproject/myapp/views.py

W widoku realizowany jest cały proces obsługi formularza. Po przeprowadzeniu walidacji możemy śmiało pobrać plik z request.FILES i przypisać go wprost do pola modelu. Jeszcze łatwiej byłoby w przypadku formularza opartego o model, ale tak za to mamy większą elastyczność gdyż przed zapisaniem pliku w bazie danych moglibyśmy jeszcze coś z nim zrobić (np. zmienić nazwę).

# -*- coding: utf-8 -*-
from django.shortcuts import render_to_response
from django.template import RequestContext
from django.http import HttpResponseRedirect
from django.core.urlresolvers import reverse
 
from myproject.myapp.models import Document
from myproject.myapp.forms import DocumentForm
 
def list(request):
    # Handle file upload
    if request.method == 'POST':
        form = DocumentForm(request.POST, request.FILES)
        if form.is_valid():
            newdoc = Document(docfile = request.FILES['docfile'])
            newdoc.save()
 
            # Redirect to the document list after POST
            return HttpResponseRedirect(reverse('myapp.views.list'))
    else:
        form = DocumentForm() # A empty, unbound form
 
    # Load documents for the list page
    documents = Document.objects.all()
 
    # Render list page with the documents and the form
    return render_to_response(
        'myapp/list.html',
        {'documents': documents, 'form': form},
        context_instance=RequestContext(request)
    )

5. Konfiguracja URL-i: myproject/urls.py

Django nie udostępnia mediów z MEDIA_ROOT automatycznie gdyż byłoby to niebezpieczne w środowisku produkcyjnym. Na serwerze developerskim to Apache, Nginx czy Lighttpd zajmują się serwowaniem plików statycznych natomiast w środowisku developerskim trzeba sobie dodać regułkę do urls-ów.

# -*- coding: utf-8 -*-
from django.conf.urls.defaults import patterns, include, url
from django.conf import settings
from django.conf.urls.static import static
 
urlpatterns = patterns('',
    (r'^', include('myapp.urls')),
) + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

6. URL-e aplikacji: myproject/myapp/urls.py

Aby widok z danej aplikacji był dostępny także dla niego trzeba dodać regułkę do urls.py

# -*- coding: utf-8 -*-
from django.conf.urls.defaults import patterns, url
 
urlpatterns = patterns('myapp.views',
    url(r'^list/$', 'list', name='list'),
)
<pre>
 
<h2>7. Szablon: myproject/myapp/templates/myapp/list.html</h2>
 
<p>Aby można było wgrać plik na serwer wymagane jest aby tag formularza zawierał atrybut enctype="multipart/form-data" oraz żeby formularz był wysyłany metodą POST</p>
 
<pre lang="html4strict">
<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <title>Minimal Django File Upload Example</title>
    </head>
    <body>
    <!-- List of uploaded documents -->
    {% if documents %}
        <ul>
        {% for document in documents %}
            <li><a href="{{ document.docfile.url }}">{{ document.docfile.name }}</a></li>
        {% endfor %}
        </ul>
    {% else %}
        <p>No documents.</p>
    {% endif %}
 
        <!-- Upload form. Note enctype attribute! -->
        <form action="{% url list %}" method="post" enctype="multipart/form-data">
            {% csrf_token %}
            <p>{{ form.non_field_errors }}</p>
            <p>{{ form.docfile.label_tag }} {{ form.docfile.help_text }}</p>
            <p>
                {{ form.docfile.errors }}
                {{ form.docfile }}
            </p>
            <p><input type="submit" value="Upload" /></p>
        </form>
    </body>
</html>

8. Uruchomienie przykładu

Tak dla pełnego obrazu – aby uruchomić omawiany tu minimalny, przykład uploadu plików w django należy ściągnąć jego źródła lub przekopiować z wyżej zamieszczonych listingów a następnie uruchomić w konsoli odpowiednie komendy:

> cd myproject
> python manage.py syncdb
> python manage.py runserver

Po uruchomieniu serwera pod adresem localhost:8000/list/ zobaczymy – na początek pustą – listę zuploadowanych plików oraz formularz. Pliki powinny się zapisywać w katalogu analogicznym do „/path/to/myproject/media/documents/2013/03/09/”

Autorem powyższego wyczerpującego przykładu jest Akseli Palén. Omówienie jest wzbogacone kilkoma moimi komentarzami.

Pliki statyczne w Django

19 października 2012

Pracuję z Django od wersji 0.96 i w projektach, które utrzymuję jest jeszcze wiele zaszłości. Jedną z nich jest sposób składowania wszelakich plików statycznych w katalogu, którego ścieżka zdefiniowana była w settings.py w zmiennej MEDIA_ROOT. Tymczasem od wersji 1.3 developerzy Django postanowili rozróżnić pliki statyczne – czyli wszelkiego rodzaju javascript-y, css-y, grafiki itp. stałe elementy składające się na tzw. layout – od mediów, pod którą to nazwą powinniśmy rozumieć wszelkiego rodzaju pliki uploadowane.

Na marginesie dodam, że aplikacja django-staticfiles była już wcześniej dostępna, ale integralną częścią frameworka stała się dopiero od wersji 1.3.

Jak skonfigurować ustawienia mediów?

Zacznę od mediów bo sprawa jest stara, prosta i wielokrotnie opisywana.

Załóżmy, że struktura naszej aplikacji wygląda tak:

project_root/
    manage.py
    mysite/
        __init__.py
        settings.py
        urls.py
        wsgi.py 
    news/
        __init__.py
        models.py
        urls.py
        views.py
    /media
        /users
	    user_avatar.jpg

UWAGA! Od wersji 1.4 zmieniła się podstawowa struktura projektu w ten sposób, że podstawowa konfiguracja oraz główny plik z urls.py trafiły do podkatalogu z nazwą projektu – w tym wypadku „mysite”.

Mediów dotyczą dwie zmienne w settings.py

MEDIA_ROOT – przechowuje pełną ścieżkę do katalogu z mediami. Do tego folderu będą trafiały pliki wrzucane przez użytkowników z poziomu strony www. Stanowi on bazową ścieżkę dla parametru „upload_to” pól FileField i ImageField.

MEDIA_ROOT = '/home/user/project_root/media'

Jeśli zmienimy fizyczne położenie mediów (bo np. serwer produkcyjny czyta pliki statyczne tylko z podkatalogu public_html) to będziemy musieli zmienić MEDIA_ROOT.

MEDIA_ROOT = '/home/user/project_root/public_html/media'

ale MEDIA_URL i wszystkie odwołania w szablonach pozostaną takie same.

MEDIA_URL – bazowy adres URL, pod którym dostępne będą pliki mediów.

MEDIA_URL = '/media/'

Przy takiej kongfiguracji do plików mediów będziemy odwoływać się następująco

<img src="/media/images/user_avatar.jpg" alt="{{ user.username }}" />

MEDIA_ROOT – Może mieć formę adresu względnego – najczęściej używaną na serwerze developerskim, albo adresu bezwzględnego, przydatnej na serwerach produkcyjnych

MEDIA_URL='http://static.domain.pl/media/'

Zmiana url-a wiąże się z koniecznością zmiany wszystkich odwołań w szablonach dlatego warto od razu przewidzieć taką możliwość i przekazać do szablonu zmienną MEDIA_ROOT i posługiwać się nią zamiast hardkodować adresy do plików mediów.

<img src="{{ MEDIA_URL }}images/user_avatar.jpg" alt="{{ user.username }}" />

Przy okazji wspomnę, że obiekty formularzy FileField i ImageField rzutowane do tekstu lub unicode-a zwracają względną ścieżkę do pliku

{{ user.avatar }} # users/user_avatar.jpg

metoda url zwraca pełen url zawierający w sobie MEDIA_URL

{{ user.avatar.url }} # /media/users/user_avatar.jpg (albo http://static.domain.pl/media/users/user_avatar.jpg)

<img src="{{ user.avatar.url }}" alt="{{ user.username }}" />

UWAGA! Jeśli dla FileField lub ImageField dopuścimy możliwość wstawiania null-i (null=True, blank=True, default=None), w szablonie zawsze dobrze jest sprawdzać czy mamy do czynienia z plikiem czy null-em.

<img src="{% if user.avatar %}{{ user.avatar.url }}{% endif %}" alt="{{ user.username }}" />

a metoda path zwraca pełną ścieżkę do pliku zawierającą w sobie MEDIA_ROOT

{{ user.avatar.path }} # /home/user/project_root/public_html/media/users/user_avatar.jpg

Z plikami statycznymi wiąże się więcej zagadnień.

Jaki jest modelowy sposób składowania plików statycznych w Django?

Przede wszystkim zmienna STATIC_ROOT pełni rolę analogiczną do MEDIA_ROOT, ale tylko na serwerze produkcyjnym. Wbudowany – developerski – serwer Django w celu odnalezienia położenia plików statycznych korzysta z tzw. finderów zdefiniowanych w STATICFILES_FINDERS oraz STATICFILES_DIRS – ale po kolei.

Pliki statyczne należy trzymać w podkatalogu „./static” każdej aplikacji

project_root/
    manage.py
    mysite/
        __init__.py
        settings.py
        urls.py
        wsgi.py
        static/ - pliki wspólne dla całej strony
            /css
                screen.css
            /js
                jquery.js 
    musicplayer/
        __init__.py
        models.py
        urls.py
        views.py
        static/ - pliki statyczne aplikacji
            /js
                jplayer.js
            /images
                play.gif

Ścieżkę każdego z podkatalogów powinniśmy dodać do krotki zmiennej STATICFILES_DIRS w settings.py

STATICFILES_DIRS = (
    "/home/project_root/mysite/static",
    "/home/project_root/musicplayer/static",
)

Jeśli zdefiniujemy zmienną STATIC_URL następująco:

STATIC_URL = '/static/'

Adresy plików w szablonach będą wyglądały tak:

<img src="/static/images/play.gif" alt="play" />

Oczywiście tu podobnie jak w mediach warto przekazać do szablonu zmienną STATIC_URL,

<img src="{{ STATIC_URL }}images/play.gif" alt="play" />

bo na serwerze produkcyjnym możemy się zdecydować na podanie bezwzględnego url-a zamiast względnej ścieżki.

STATIC_URL = 'http://static.domain.pl/static/'

Czasami chcielibyśmy aby media aplikacji – dajmy na to musicplayer – znalazły się w podkatalogu o tej samej nazwie. Nie musimy w tym celu zmieniać struktury plików lecz wystarczy dodać prefix do ścieżki w STATICFILES_DIRS.

STATICFILES_DIRS = (
    "/home/project_root/mysite/static",
    ('musicplayer', "/home/project_root/musicplayer/static"),
)

Fizyczne położenie pliku się nie zmieniło, ale zmiana konfiguracji pozwala traktować plik jakby się znajdował w dodatkowym podkatalogu.

<img src="/static/musicplayer/images/play.gif" alt="play" />

Aby całość zadziałała musimy jeszcze wskazać Django narzędzia wyszukiwania plików tzw. findery.

STATICFILES_FINDERS = (
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
)

Ponieważ w dwóch różnych podkatalogach /static możemy mieć plik o tej samej nazwie, może się zdarzyć że jeden „nadpisze” drugi i trzeba będzie wyszukać wszystkie lokalizacje w jakich może znajdować się plik o danej nazwie.

Warto wtedy skorzystać z komendy findstatic

$ python manage.py findstatic css/base.css admin/js/core.js
#/home/special.polls.com/core/static/css/base.css
#/home/polls.com/core/static/css/base.css
#/home/polls.com/src/django/contrib/admin/media/js/core.js

Pliki statyczne na serwerze developerskim

Django nie udostępnia plików statycznych i mediów z automatu gdyż byłoby to niebezpieczne na serwerze produkcyjnym. Dlatego też także w środowisku developerskim trzeba zadbać aby serwer wiedział gdzie szukać plików poprzez dodanie odpowiednich reguł do urls.py

from django.conf.urls import patterns, include, url
from django.conf import settings
from django.conf.urls.static import static
from django.contrib.staticfiles.urls import staticfiles_urlpatterns
 
urlpatterns = patterns('',
    # Uncomment the next line to enable the admin:
    url(r'^admin/', include(admin.site.urls)),
    ...
)
 
if settings.DEBUG:
    urlpatterns += staticfiles_urlpatterns()   
    urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

Pliki statyczne na serwerze produkcyjnym

Nie będę opisywał jak skonfigurować Apache 2, Nginx czy Lighttpd. Przyjmijmy, że dowolny serwer umożliwia serwowanie plików statycznych z poziomu podkatalogu /public_html.

W pierwszej kolejności należy odpowiednio ustawić zmienną STATIC_ROOT w settings.py

STATIC_ROOT = os.path.join(PROJECT_ROOT, 'public_html/static')

Następnie należało by odpowiednio do ustawień STATICFILES_DIRS przekopiować (lub dowiązać) pliki i katalogi.

project_root/
    public_html/
        static/ - pliki wspólne dla całej strony
            /css
                screen.css
            /js
                jquery.js 
	    musicplayer/ - pliki statyczne aplikacji
                /js
                    jplayer.js
                /images
                    play.gif

Może to być nieco pracochłonne dlatego też wielu developerów do tej pory preferowało trzymanie statyków w jednym wspólnym katalogu. Po opublikowaniu strony na serwerze produkcyjnym wystarczyło tylko przekopiować lub przenieść statiki do katalogu publicznego oraz zmienić ustawienia STATIC_ROOT.

Od wersji 1.4 mamy do dyspozycji komendę „collectstatic”, który całą robotę z kopiowaniem plików statycznych robi za nas. W trakcie developmentu możemy trzymać pliki statyczne w wielu podkatalogach a po wrzuceniu na live wystarczy tylko wywołać komendę –

python manage.py collectstatic

i mamy przekopiowane wszystkie pliki statyczne łącznie z tymi związanymi z panelem administracyjnym. Dodanie na końcu opcji -l albo –link,

python manage.py collectstatic -l

tworzy dowiązania symboliczne zamiast kopiować pliki.

Staticfiles w starych projektach

Przy podnoszeniu starych projektów do nowej wersji Django nie jesteśmy zmuszani do wydzielania mediów i relokacji plików statycznych. Dalej możemy trzymać wszystko w jednym katalogu, ale trzeba zadbać o odpowiednią konfigurację.

MEDIA_ROOT = '/home/user/project_root/static'
 
MEDIA_URL = '/static/'
 
STATICFILES_DIRS = (
    MEDIA_ROOT,
)
 
STATIC_URL = MEDIA_URL
 
STATIC_ROOT = '/home/user/project_root/public_html/static'

UWAGA! Traktuj STATIC_ROOT jak zmienną używaną tylko na serwerze produkcyjnym i nawet jeśli nie wiesz jak powinna ta ścieżka wyglądać docelowo wskarz na katalog, który nie jest jednym z katalogów zdefiniowanych w STATICFILES_DIRS

Podusmowanie

Konfiguracja mediów w Django nie jest tak prosta jak to się wydaje doświadczonym developerom. Zagadnienie to nie jest poruszone w podstawowym tutorialu, a dokumentacja choć jedna z najlepszych nie prowadzi za rękę początkującego programistę.

Choć staticfiles wraz z komendą collectstatic to bardzo wygodne rozwiązanie ułatwiające trzymanie porządku w projekcie, dodatkowo utrudnia zagadnienie zarządzania plikami statycznymi. Mam nadzieję, że swoim wpisem nie gmatwam dodatkowo całej sprawy, i że przyda się on komuś rozpoczynającemu dopiero pracę z frameworkiem Django.

MySQL-owe widoki w Django

28 października 2011 Comments: 2

Niniejszy artykuł traktuje o widokach w bazie danych (konkretnie w MySQL) i możliwości tworzenia modeli do tychże widoków z użyciem ORM-a framewokra Django. Zwracam na to uwagę aby nie pomylić – pomimo zbieżności nazw – widoków SQL-owych z widokami (views.py) Django.

Czym są właściwie widoki w relacyjnej bazie danych i po co się je tworzy wyjaśnia – skądinąd świetnie napisany rozdział pod tytułem „Widoki” w przygotowanym przez Heliona kursie MySQL.

W jednym z projektów, nad którymi pracuję stanąłem przed potrzebą stworzenia widoku w MySQL-u. Postanowiłem więc zdefiniować taki widok, stworzyć do niego model w Django i posługiwać się jak dowolnym innym modelem z tym, że tylko do odczytu. ORM w Django jest jednym z najbardziej rozbudowanych i zaawansowanych narzędzi tego typu mimo to ma swoje ograniczenia dlatego też nie byłem pewien czy uda mi się zrealizować to co sobie założyłem. Okazało się to możliwe aczkolwiek dopiero od wersji 1.3 frameworka Django.

Poniżej prezentuję jak zdefiniować prawidłowo model dla widoku. Na potrzeby tego artykułu stworzyłem możliwie proste przykłady aby pokazać mechanizm. Skonstruowany przeze mnie widok był daleko bardziej rozbudowany.

Załużmy, że mamy nowy projekt django a w nim aplikację do prezentacji newsów.

news/models.py

from django.db import models
from django.contrib.auth.models import User
 
class Article(models.Model):
    name = models.CharField(max_length=255)
    slug = models.SlugField(unique=True, max_length=100)
    text = models.TextField()
    added_by = models.ForeignKey(User)
    added_on = models.DateTimeField(auto_now_add=True)
    updated_on = models.DateTimeField(auto_now=True)
    is_active = models.BooleanField(default=True)

news/admin.py

from news.models Article
from django.contrib import admin
 
class ArticleAdmin(admin.ModelAdmin):
    list_filter = ['is_active']
    list_display = ('name', 'added_by', 'added_on', 'updated_on', 'is_active')
    prepopulated_fields = {'slug': ('name',)}
    search_fields = ('name', )
 
admin.site.register(Article, ArticleAdmin)

Z pewnych powodów potrzebujemy widoku, który prezentuje się następująco:

DROP VIEW IF EXISTS `users_newsview`;
CREATE VIEW `users_newsview` AS
    SELECT 0 AS id, n.id AS news_id, n.name AS news_name, n.added_by_id AS user_id, u.username
    FROM news_article AS n
    INNER JOIN auth_user AS u ON u.id = n.added_by_id;

Tworzymy do niego model, który będzie tylko do odczytu.

users/models.py

from django.db import models
from news.models import Article
from django.contrib.auth.models import User
 
class NewsView(models.Model):
 
    class Meta:
        managed = False
 
    news = models.ForeignKey(Article, null=True, blank=True, on_delete=models.DO_NOTHING)
    news_name = models.CharField(max_length=255, null=True, blank=True)
    user = models.ForeignKey(User, null=True, blank=True, on_delete=models.DO_NOTHING)
    username = models.CharField(max_length=255, null=True, blank=True)

O tym, że obiekty modelu „NewsViews” są niemodyfikowalne decyduje Zdefniowany w podklasie „Meta” parametr „managed = False”. Innym bardzo istotnym elementem jest dodanie do definicji kluczy obcych „on_delete=models.DO_NOTHING”. Django w przypadku kluczy obcych domyślnie emuluje zachowanie „on delete cascade”. Możliwość zmiany tego zachowania Django wspiera dopiero od wersji 1.3. Jeśli nie zmienimy sposobu w jaki Django ma postępować z elementami powiązanymi w trakcie usuwania danego obiektu to przy próby usunięcia newsa, albo usera zostanie zgłoszony błąd gdyż próba usunięcia także rekordu widoku z oczywistych względów się niepowiedzie.

W starszej wersji frameworka Django też można stworzyć model do widoku, ale trzeba w nim zrezygnować z tworzenia relacji do innych obiektów i zamiast pól „news” i „user” zdefiniować pola typu integer „news_id” oraz „user_id”. Jak się domyślacie rozwiązanie to jest o wiele mniej wygodne.

Kilka reflaksji na temat frameworków

27 marca 2011 Comments: 2

Ostatnio – po długiej przerwie – wszedłem na blog Zyxa wierząc, że znajdę tam coś ciekawego do przeczytania. Nie zawiodłem się. Znalazłem dwie recenzje najpopularniejszych w Polsce frameworków PHP tj. Symfony 1.4 okiem Zyxa i Zend Framework także okiem Zyxa.

Ostatnio przerzuciłem się na Pythona i Django, a wcześniej przez co najmniej dwa lata budowałem aplikacje w oparciu o Kohanę, jednak od czasu do czasu – w tak zwanym międzyczasie – próbowałem też coś sklecić na ZF i polubić Symfony dlatego też orientuję się przynajmniej pobieżnie w ich konstrukcji. Artykuły Zyxa i własne doświadczenie skłoniły mnie do kilku refleksji na temat ogólnej konstrukcji frameworków, sensu użycia ORM-ów a także systemów szablonów.

Architektura

Dobrze zaprojektowana struktura plików to podstawa porządnego frameworka. Każdy szanujący się projektant stara się utrzymać porządek w swoim projekcie i lubi bez zbędnego zastanawiania się wiedzieć gdzie ma czego szukać. Kohana umożliwia tworzenie modułów z których każdy może mieć swoje kontrolery, modele, widoki, pliki konfiguracyjne, a nawet biblioteki. Układ katalogów jest rozbudowany. Kaskadowość z jednej strony umożliwia elastyczność np. nadpisanie konfiguracji domyślnej, konfiguracją specyficzną dla danego modułu. (w Kohanej nie tylko konfigurację można nadpisać ale też „wymienić” klasy z zachowaniem ich dotychczasowej nazwy. Założenie to w PHP wyklucza proste użycie dziedziczenia dlatego też w Kohanie 2 było to zrobione po chamsku z użyciem evala. W wersji 3 tego frameworka mechanizm ten został bardziej elegancko zaimplementowany). Z drugiej strony przy bardziej rozbudowanych projektach człowiek zaczyna się gubić nie pamiętając niekiedy skąd się wzięła bieżąca wartość danej zmiennej konfiguracyjnej. Zaczyna się szukanie. Pół biedy, kiedy struktura katalogów jest płaska, ale jeśli musimy przeklikać się przez kilka poziomów zagłębień staje się to męczące.

Nie wiem kto na to wpadł, aby każdą klasę trzymać w osobnym pliku, nie wiem też kto wymyślił aby nazwa klasy odzwierciedlała położenie pliku w strukturze katalogów (patrz ZF, PEAR), ale doprowadziło to do powstania całej masy katalogów i podkatalogów i jeszcze większej liczby plików, z których niektóre np. zawierają jedynie jednolinijkową definicję wyjątku. W Django w poszczególnych app-sach znajdziemy z reguły pliki (__init__.py, views.py, models.py, urls.py, admin.py, tests.py) i to w 90% przypadków wystarcza. W Kohanie jeden moduł to kilka katalogów. Python jakoś obywa się bez autoloadera i kiedy czytam to co wyżej sam napisałem zaczynam rozumieć dlaczego. Na marginesie tylko wspomnę, że w związku z wprowadzeniem namespace-ów, sposób organizacji klas w plikach PHP się zmieni.

PHP w wersji piątej poszło wyraźnie w kierunku „magi”. Wszystkie poprzedzone podwójnym podkreśleniem metody są bardzo wygodnym rozwiązaniem i osobiście bardzo je lubię ale nadmiar czarów daje się we znaki w chwili kiedy zachodzi potrzeba prześledzenia procesów zachodzących w aplikacji. Debugowanie przesyconych „magią” klas jest znacznie utrudnione przede wszystkim przez niejednoznaczne komunikaty błędów. Dodatkową wadą użycia metod magicznych jest to, że dynamiczne settery i gettery nie będą podpowiadane przez żadne IDE typu NetBeans, czy Eclipse mimo w sumie dobrze zrealizowanej w nich funkcji podpowiadania składni.

Inną kwestią jest uniwersalność kodu. Klas Kohanej można używać tylko w ramach tego frameworka, z kolei biblioteki eZ Components lub Zend Frameworka można używać niezależnie lub w ramach zupełnie innej platformy. Sam wielokrotnie w projektach opartych na Kohanej sięgałem do wybranych komponentów Zend Frameworka. Klasy ZF są jak to zauważył Zyx dopracowane i przetestowane i jedyną ich wadą jest z reguły to, że są zbyt dobre. Zamiast w najprostszy sposób realizować banalną funkcjonalność, autorzy poszczególnych bibliotek prześcigają się w wymyślaniu wariantów zastosowań i sposobów użycia. Tak właśnie z noża powstał szwajcarski scyzoryk – fajny ale do smarowania chleba najlepszy jest zwykły nóż kuchenny. Ponoć w nowej wersji ZF ma to ulec zmianie.

ORM

Symfony zniechęciło mnie do siebie przede wszystkim ORM-em. Do Propela nawet nie startowałem, natomiast z Doctrine-m walczyłem jakiś czas. Niestety na etapie kiedy przeprowadzałem moje eksperymenty Doctrine było mocno niedopracowane w związku z czym wielokrotnie wzbudzało to moją irytacją. Z tego co pamiętam nie mogłem nawet dowolnie wskazać miejsca generowania modeli tylko było to z góry narzucone. Dlatego między innymi zarzuciłem pomysł „dokooptowania” Doctrine do Kohany.

Na tę chwilę o wiele większe doświadczenie mam z ORM-em Django uważanym za wzorcowy. Jest on o wiele bardziej dopracowany niż wyżej wspomniane PHP-owe odpowiedniki w związku z czym da się z nim w miarę sprawnie pracować. Mimo to pozostaję sceptyczny w kwestii użycia tego typu narzędzi. Opanowanie django-wego ORM-a kosztowało mnie sporo czasu, a do tego nie wyobrażam sobie aby można było efektywnie go używać nie znając wcześniej SQL-a. Przy prostych konstrukcjach jest miło i przyjemnie przy bardziej skomplikowanych użycie obiektów rzutuje przede wszystkim na wydajność, do czego przyczyniają się w dużej mierze bajery typu „lazy loading”. Zmiana ORM-owej konstrukcji w celu optymalizacji i tak poprzedzana jest napisaniem zapytania w SQL więc człowiek nie ma żadnej korzyści z użycia ORM-a, która by rekompensowała nakłady poniesione w celu jego poznania.

O wiele bardziej przemawiają do mnie składacze zapytań SQL takie jak Zend_Db – choć jak większość bibliotek Zenda jest ona przedobrzona. Mając prostą klasę do konstruowania zapytań SQL – taką która ułatwia, nie ogranicza i bynajmniej nie zmusza do uczenia się zamienników w stylu „annotate” zamiast „group by”, wspartą wzorcem projektowym DAO można stworzyć prosty w utrzymaniu, debugowaniu, elastyczny, wcale nie pracochłonny i przede wszystkim odseparowany od warstwy logiki i widoku mechanizm dostępu do bazy danych.

ORM-y mogą być w moim mniemaniu jedynie dodatkami używanymi np. do automatycznego generowania backedu (czytaj panelu administracyjnego), ale w żadnym wypadku nie powinny być jedynym ani nawet głównym sposobem pracy z danymi pobieranymi z bazy danych.

Szablony

Symfony a także Zend Framework, jak równierz Kohana używają natywnych szablonów PHP. Podobnie jak Zyx zgadzam się, że można znaleźć lepszą alternatywę dla warstwy widoku. W odróżnieniu jednak od niego nie stawiałbym na Open Power Template’a, które uważam za trudne i pracochłonne w użyciu (z samej swojej xml-owej natury), a do tego mniej elastyczne i intuicyjne niż kontestowane przez niego Smarty.

System szablonów Smarty w wersji 3 zostało wzbogacone o kilka ciekawych funkcjonalności jak np. dziedziczenie szablonów i możliwość nadpisywania bloków kodu znane z szablonów Django. W przeciwieństwie do ORM-ów uważam, że warto potrudzić się troszkę ze składnią Smarty i pogodzić się z narzutem na wydajność bo w zamian można zyskać szereg usprawnień jakich jesteśmy pozbawieni w przypadku użycia gołych szablonów PHP. Wspomnę tylko wygodniejszą składnię czy zaimplementowany cache, ale też zwiększone bezpieczeństwo wymuszone ograniczoną dostępnością funkcji PHP wewnątrz szablonu czy też encapsulacją zmiennych. Smarty 3 umożliwia też użycie natywnych szablonów PHP ale jest to alternatywa nie ograniczenie.

Do niedawna pracowałem jeszcze z Django w wersji 9.6, w której szablony w stosunku do wersji 1.2 były mocno ograniczone. Obecne szablony Django w wersji 1.x przypominają Smarty (albo na odwrót jak ktoś woli) – z tym, że Smarty 3 są po prostu lepsze. Jestem fanem składni i możliwości języka Python mimo to na polu szablonów PHP u mnie wygrywa.

Reasumując

We wpisie tym nie dążyłem bynajmniej do porównania frameworków między sobą, a już na pewno się do porównywania rozwiązań stosowanych w języku PHP czy Python. Poruszyłem trzy zagadnienia, które w mniejszym lub większym stopniu dotyczą wszystkich z wyżej wymienionych platform. Wspomniałem o tym, że jestem zwolennikiem rozwiązań uniwersalnych ale elastyczność nie może być realizowana kosztem przejrzystości i prostoty. Dałem też do zrozumienia, że mapowanie na siłę relacyjnej bazy danych do postaci obiektów jest raczej wyrazem fundamentalizmu ideologicznego niż pragmatycznym działaniem. Z kolei w użyci systemów szablonów dostrzegłem wiele zalet.

Liczba mnoga (msgid_plural) w plikach „po” gettext-a w django

22 marca 2011

Django jest rozbudowanym frameworkiem przewidzianym m.in. do tworzenia wielojęzykowych serwisów. Wykonanie strony w kilku wersjach językowych wymaga uwzględnienia wielu zagadnień, takich jak formaty daty, czasu, waluty a nawet oznaczania części dziesiętnych w liczbach. W poszczególnych językach różny jest porządek sortowania choćby z uwagi na znaki narodowe wzbogacone o akcenty czy ogonki – jak w naszym rodzimym, polskim języku. Sporym wyzwaniem jest też gramatyka w tym szyk zdania, przypadki i liczba mnoga.

Django jest przygotowane do pracy z gettext-em – oprogramowaniem do tworzenia tłumaczeń. To profesjonalne narzędzie uzupełnione wieloplatformowym edytorem plików poedit służącym do edycji plików „.po” (rozszerzenie plików źródłowych gettext-a) i jednocześnie kompilującym owe pliki do formatu binarnego „.mo” przyspiesza i ułatwia umiędzynaradawianie oprogramowania tworzonego w przeróżnych językach programowania. Ja z powodzeniem używałem gettexta w aplikacjach PHP i Python.

Standardowo treść pliku „.po” składa się z szeregu par zmiennych msgid i msgstr, z których pierwsza zawiera treść komunikatu oryginalnego, a druga tłumaczenie.

msgid "Komunikat oryginalny"
msgstr "Tłumaczenie komunikatu"

Istnieją jednak komunikaty wymagające uwzględnienia liczby mnogiej. Na przykład zawierające zmienną wypełnianą dynamicznie.

msgid "We offer %(num_homes)d homes for sale "

Format gettext-a uwzględnia wiele aspektów poszczególnych języków narodowych w tym m.in. różny sposób tworzenia liczby mnogiej. W przypadku języka polskiego jest to sprawa o tyle skomplikowana, że jeden rzeczownik może mieć kilka form liczby mnogiej zależnie od liczby elementów.

Mamy w ofercie 2 domy na sprzedaż
Mamy w ofercie 5 domów na sprzedaż

W takim wypadku wpis w pliku „.po” może wyglądać następująco. Uwzględniona jest wersja pojedyncza oraz wersje mnogie.

msgid "Please correct the error below."
msgid_plural "Please correct %(num_errors)d errors below."
msgstr[0] "Proszę poprawić poniższy błąd."
msgstr[1] "Proszę poprawić %(num_errors)d poniższe błędy."
msgstr[2] "Proszę poprawić %(num_errors)d poniższych błędów."

Aby gettext wiedział jaką logiką ma się posługiwać przy konstruowaniu liczby mnogiej należy go o tym poinformować. Oprócz wyżej wspomnianych zmiennych zawierających etykiety komunikatów oraz komunikaty właściwe, w plikach „.po” znajdują się też komentarze informujące m.in o tym w jakim pliku i w której linii dany komunikat się znajduje. Są też tzw. nagłówki stanowiące swego rodzaju metadane plików tłumaczeń.

Przykładowe nagłówki:

"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 0.2\n"

Większość tychże nagłówków najlepiej pozostawić w postaci oryginalnej, jednak nagłówek informujący o formacie liczby mnogiej może wymagać dodania lub też zmiany.

"Plural-Forms: nplurals=2; plural=(n != 1);\n"

Taki nagłówek jest prawidłowy m.in dla języka angielskiego, niemieckiego, hiszpańskiego itd. Nagłówek dla wersji polskiej jest już bardziej rozbudowany.

Plural-Forms: nplurals=3; \
              plural=n==1 ? 0 : \
                     n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;

Szczegółową listę nagłówków dla różnych języków i grup językowych można znaleźć w dokumentacji getext-a w części poświęconej formom liczby mnogiej.

Na zakończenie dodam jedynie, że brak tego nagłówka w pliku „.po” przy próbie jego zapisu kończy się komunikatem o błędzie krytycznym. W moim przypadku jeśli edytowany był wpis przewidujący liczby mnogie to usunięciu uległy wszystkie zmienne msgstr[0], msgstr[1] itd. znajdujące się pod msgid_plural owych wpisów. Plik był mimo to zapisywany co przy próbie ponownego otwarcia pliku „.po” kończyło się komunikatem o uszkodzeniu pliku. Można to było łatwo naprawić dodają wyżej wspomniane zmienne, jednak problem ostatecznie został rozwiązany po dodaniu odpowiedniego nagłówka.

Domknięcia, funkcje anonimowe przestrzenie nazw i dekoratory

19 listopada 2010

Pojęcie dekoratora w języku Python to coś więcej niż wzorzec projektowy. To elegancki sposób na zwiększenie możliwości danej funkcji czy metody doskonale wykorzystujący unikalne cechy języka Python. Mechanizm działania dekoratorów oraz sposób ich użycia doskonale opisał Kent S Johnson (opracowanie to można znaleźć także w języku polskim).

Prostym i użytecznym przykładem dekoratora może być np. funkcja mierząca czas wykonania funkcji udekorowanej.

import time
 
def timeit(method):
    """Mierzy czas wykonania funkcji"""
 
    def check_time(*args, **kw):
        ts = time.time()
        result = method(*args, **kw)
        te = time.time()
        log(method.__name__, args, kw, ts, te)
        return result
 
    def log(name, args, kw, time_start, time_end):
        msg = '%r (%r, %r) %2.10f sec' % (name, args, kw, time_end - time_start)
        print msg
 
    check_time.__name__ = method.__name__
    return check_time

Użycie dekoratora w Pythonie to syntaktyczna perełka.

@timeit
def say_hello(param):
    print param
    time.sleep(0.5)

W PHP osiągnięcie czegoś takiego jest po prostu niemożliwe. Od wersji PHP 5.3 język został wzbogacony o nowe cechy takie jak domknięcia, funkcje anonimowe i przestrzenie nazw. Czy owe mechanizmy umożliwiają implementację czegoś co choćby przypominało pythonowy dekorator?

W PHP nie da się zdefiniować funkcji, a potem przypisać jej inną nazwę.

def foo():
    print 'OK'
 
faa = foo
 
faa() # w wyniku otrzymamy: OK

no chyba że użyjemy funkcji anonimowej (ang. anonymous function)

$foo = function() {echo 'OK';};
$faa = $foo;
$faa(); // w wyniku otrzymamy: OK

Dekorowanie funkcji anonimowych przy użyciu domknięć

Możemy zapomnieć (na razie) o dekorowaniu tradycyjnych funkcji ale udekorowanie funkcji anonimowej staje się potencjalnie możliwe.

$foo = function() {echo 'OK';};
 
$foo = function() use ($foo) {
    echo 'Jest '; return $foo();
};
 
$foo(); // w wyniku otrzymamy: Jest OK

Domknięcia (ang. closures) stoją u podstaw programowania w Pythonie, są też od zawsze obecne i powszechnie używane np. w Javascript-cie.

var Example = function()
{ 
    this.public = function() 
    { 
        return "This is a public method"; 
    }; 
 
    var private = function() 
    { 
        return "This is a private method"; 
    };
};
 
Example.public()  // returns "This is a public method" 
Example.private() // error - doesn't work

Ich implementacja w PHP to kwestia dyskusyjna podobnie jak ich użyteczność. Z uwagi na określone cechy PHP domknięcia w tym języku wydają się nie być odpowiednikiem tego mechanizmu znanym z innych języków programowania. W przeprowadzanym przeze mnie teście przydały się jednak i osobiście dostrzegam jeszcze kilka innych ich praktycznych zastosowań. Wracając jednak do głównego wątku tego wpisu.

W miarę prosty sposób udało się udekorować funkcję „foo”. Domknięcie można zamknąć w funkcji dzięki czemu nadaje się do wielokrotnego użytku.

function timeit($func) {
    return function() use ($func) {
        // pobranie wszystkich argumentów funkcji
        $args = func_get_args();
 
        // utworzenie funkcji pomocniczej
        $microtime_float = function()
        {
            list($usec, $sec) = explode(" ", microtime());
            return ((float)$usec + (float)$sec);
        };
 
        // rozpoczęcie pomiaru czasu
        $time_start = $microtime_float();
 
        // wywolanie funkcji
        $result = call_user_func_array($func, $args);
 
        // zakończenie pomiaru czasu i wyświetlenie wyników
        $time_end = $microtime_float();
        $time = $time_end - $time_start;
        printf ("\nfunction was executed during %01.6f seconds\n", $time);
 
        // zwrócenie resultatu działania funkcji
        return $result;
    };
}

Zaprezentuje może użycie „dekoratora” timeit na funkcji wymagającej parametrów.

$func_say_hello = function(param) {
	return 'Hello '. $param;
};
 
$func_say_hello = timeit($func_say_hello);
echo $func_say_hello('World');

Funkcje anonimowe są, a raczej będą stosunkowo rzadko używane, podobnie zresztą jak funkcje lambda w Pythonie, których są odpowiednikiem. Pomiar czasu wykonania np. funkcji sortującej to z pewnością przydatna sprawa, ale wzbogacanie funkcji anonimowych o nowe możliwości przy pomocy „dekoratorów” wydaje się być mało przydatne. Czy zatem można udekorować zwykłą funkcję?

Czy przestrzenie nazw pomagają w dekorowaniu funkcji?

Po co nam przestrzenie nazw (ang. namespaces)? Załóżmy, że mamy w pliku functions.php zdefiniowaną przestrzeń nazw „lib” i funkcję „say_hello”

<?php
namespace lib {
    function say_hello($param)
    {
        return 'Hello '. $param;
    }
}

Gdybyśmy w pliku index.php dołączyli plik functions.php moglibyśmy używać zdefiniowanych w nim funkcji.

<?php
include './functions.php';
echo \lib\say_hello('World');

Wywołanie say_hello(‚World’); bez podania poprzedzającego go namespace-a zakończyłoby się błędem. Niestety PHP nie wspiera jak na razie możliwości aliasowania funkcji czy stałych zamkniętych w przestrzeni nazw dlatego też chęć odwoływania się do funkcji „say_hello” bezpośrednio musi zostać poprzedzona definicją nazwijmy to „atrapy”, która przy okazji pozwoli udekorować opakowywowaną funkcję.

include './functions.php';
 
function timeit($func) {...}
 
function say_hello($param)
{
    $func_say_hello = '\lib\say_hello';
    $func_say_hello = timeit($func_say_hello);
    $result = $func_say_hello($param);
}
echo say_hello('World');

Zwróćmy uwagę na to, że funkcje „say_hello” i „\lib\say_hello” to nie to samo i równie dobrze moglibyśmy nie używać przestrzeni nazw i osiągnęlibyśmy to samo (tylko nazwy funkcji byłyby inne)

function timeit($func) {...}
 
function say_hello($param) {...}
 
function decorated_say_hello($param)
{
    $func_say_hello = 'say_hello';
    $func_say_hello = timeit($func_say_hello);
    $result = $func_say_hello($param);
}

Z punktu widzenia wygody użycia to czy użyjemy przestrzeni nazw czy nie to mamy to samo. I tak chcąc zmierzyć czas wykonania funkcji „say_hello” musimy zmienić jej wywołanie w kodzie na „decorated_say_hello”. Nie da się udekorować zdefiniowanych funkcji w pythoniczny sposób.

Aliasy – nowe możliwości dekorowania klas

W przypadku funkcji moje rozważania to jedynie gimnastyka mózgu, jednak w przypadku klas teoretyczne dywagacje – jak się zaraz okaże – przybiorą praktyczną formę.

Wspominałem wyżej o aliasach. Tego czego nie da się zrobić z funkcjami i stałymi w PHP > 5.3 da się uczynić z klasami.

Załóżmy, że plik functions.php wygląda tak

namespace lib {
	class Say
	{
		public static function hello($param)
		{
			return 'Hello '. $param;
		}
 
		public function goodbye($param)
		{
			return 'Goodbye '.$param;
		}
	}
}

Do pliku index.php możemy dołączyć functions.php i przypisać klasie „/lib/Say” alias Say

include './functions.php';
 
function timeit($func) {...}
 
use \lib\Say as Say;
 
echo Say::hello('Adam');
$say = new Say();
echo $say->goodbye('Ewa');

Nadanie aliasu sprawia, że możemy używać klasy tak jakby była zdefiniowana bez użycia przestrzeni nazw. Jeśli w tym momencie przyjdzie nam ochota zmierzenia czasu wykonania metod klasy „Say” (a właściwie „\lib\Say”) bez zmiany wywołań musimy zrobić dwie rzeczy. Zakomentować linijkę nadającą alias oraz udekorować klasę.

include './functions.php';
 
function timeit($func) {...}
 
//use \lib\Say as Say;
 
class Say
{
	private $_obj;
 
	public function  __construct() {
		$this->_obj = new \lib\Say();
	}
 
	public static function hello($param)
	{
		$func = '\lib\Say::hello';
		$func = \deco\timeit($func);
		return $func($param);
	}
 
	public function goodbye($param)
	{
		$func = function($obj, $param) {
			return $obj->goodbye($param);
		};
 
		$func = \deco\timeit($func);
		return $func($this->_obj, $param);
	}
}
 
echo Say::hello('Adam');
$say = new Say();
echo $say->goodbye('Ewa');

Wywołanie metod się nie zmieniło, ale wzbogaciliśmy naszą klasę o funkcjonalność pozwalającą nam zmierzyć czas wykonania zarówno metody statycznej klasy, jak i metody instancji. Do wygody użycia dekoratora „@timeit” w Pythonie jest jeszcze bardzo daleko. Udekorowaliśmy zaledwie dwie metody, a trzeba było napisać tyle kodu. Z każdą kolejną metodą przybędzie dodatkowego kodu w dekoratorze. Czy da się ten przyrost ograniczyć?. Dzięki metodom magicznym da się zrobić bardziej uniwersalny dekorator.

include './functions.php';
 
function timeit($func) {...}
 
//use \lib\Say as Say;
 
class Say
{
	private $_obj;
 
	public function  __construct() {
		$this->_obj = new \lib\Say();
	}
 
	public static function  __callStatic($name, $arguments)
	{
		$func = '\lib\Say::'.$name;
		return self::_addDecorators($func, $arguments);
	}
 
	public function __call($name, $arguments)
	{
		$func = function() {
			$params = func_get_args();
			$obj = array_shift($params);
			$method = array_shift($params);
			return call_user_func_array(array($obj, $method), $params);
		};
 
		array_unshift($arguments, $name);
		array_unshift($arguments, $this->_obj);
		return self::_addDecorators($func, $arguments);
	}
 
	private static function _addDecorators($func, $arguments)
	{
		$func = \deco\timeit($func);
		return call_user_func_array($func, $arguments);
	}
}
 
echo Say::hello('Adam');
$say = new Say();
echo $say->goodbye('Ewa');

Konkluzje

1. To naprawdę działa – doznałem intelektualnego orgazmu.
2. Nie stosujcie takich rozwiązań w prawdziwym projekcie

Próba debugowania takiego kodu skazana jest z góry na porażkę. Przeprowadzony przeze mnie eksperyment dostarczył mi najlepszego dowodu na to, że nie ma sensu implementować na siłę mechanizmów znanych z innych języków. PHP ma swoją naturę, która czasami jest ograniczeniem, ale często stanowi też jego zaletę.

Pogodzenie Python-a z PHP na Apache2 (mod_wsgi + mod_php)

9 października 2010 Comments: 2

Wstęp

Poradników i tutoriali opisujących konfigurację Apache z PHP i MySQL pod Linuxem (LAMP) jest cała masa. W Ubuntu sprowadza się to do wywołania w konsoli prostego polecenia

sudo apt-get install php5 php5-mysql mysql-server apache2 libapache2-mod-auth-mysql

… i mamy wszystko co potrzeba. Więcej na ten temat znajdziemy choćby w artykule Instalacja Apache + PHP5 + MySQL.

Instalacja frameworka Django i preferowanego przez pythonowców serwera baz danych Postgres jest równie prosta – przynajmniej pod Ubuntu.

sudo apt-get install python-django postgresql python-psycopg2 postfix python-imaging python-docutils

Django ma jedną z najlepszych dokumentacji, a o Postgresie pisze niemal co drugi bloger, który miał coś z nim do czynienia tak więc zainteresowanych po prostu odeślę do wciąż aktualnego i w miarę kompletnego wpisu Instalacja PostgreSQL 8.3 w Ubuntu 8.04.

O ile hostowanie skryptów PHP na Apache-u jest rzeczą naturalną zarówno w środowisku deweloperskim jak i produkcyjnym o tyle w przypadku Pythona a konkretnie aplikacji Django już nie. Django posiada świetny wbudowany serwer stworzony na podstawie klasy BaseHttpServer ze standardowej biblioteki Pythona, który świetnie sprawdza się do szybkiego testowania aplikacji o niepełnej funkcjonalności. Restartuje się automatycznie przy każdej zmianie w kodzie a ponadto ponieważ uruchamiany jest w terminalu wyświetla na wyjściu wszystkie instrukcje print.

Użycie serwera wbudowanego w środowisku produkcyjnym jest zabronione licencją, a poza tym istnieje jeszcze kilka innych obiektywnych powodów aby tego nie robić, jak choćby bezpieczeństwo i stabilność, czy wydajność. Jak się okazuje także dla celów developerskich warto czasem podjąć trud konfiguracji serwera zewnętrznego.

W przypadku Apache-a w kontekście hostowania skryptów napisanych w języku Python najczęściej stosuje się dwa rozwiązania tj. mod_python lub mod_wsgi. Oba z modułów nie powodują konfliktów z mod_php, tak więc chcąc na swoim serwerze obsługiwać zarówno aplikacje PHP i Python można zastosować dowolne z wymienionych rozwiązań.

Ponoć konfiguracja Apache2 + mod_python jest częściej stosowana, lepiej przetestowana i udokumentowana, ja jednak zdecydowałem się na WSGI z uwagi na elastyczność jaką udało mi się uzyskać.

Założenia

W przypadku środowisk produkcyjnych kluczową kwestią jest bezpieczeństwo i stabilność serwera. W środowisku developerskim, w którym skrypty uruchamiane są jedynie na komputerze lokalnym osobiście stawiam na elastyczność kosztem nawet bezpieczeństwa i stabilności. Nie lubię grzebać w plikach konfiguracyjnych Apache-a i edytowanie pliku /etc/apach2/httpd.conf lub któregoś z plików w katalogu /etc/apache2/sites-available/ za każdym razem kiedy tworze nowy projekt lub zmieniam jego nazwę. W przypadku projektów realizowanych w języku PHP wystarczy, że w moim katalogu workspace stworzę nowy katalog np. „nowy_projekt_php”, wrzucę do niego plik index.php i wywołam w pasku adresu przeglądarki

http://localhost/nowy_projekt_php

Podobny efekt chciałem uzyskać w przypadku projektów realizowanych w Django.

Instalacja mod_wsgi

Moduł WSGI możesz zainstalować ze źródeł, co zostało przystępnie opisane w artykule Ubuntu Hardy – mod_wsgi Installation, ale w Ubuntu można skorzystać z repozytorium:

sudo apt-get install libapache2-mod-wsgi

Aby aktywować moduł (w Ubuntu 10.04 – można pominąć)

sudo a2enmod mod-wsgi

W przypadku instalacji z repozytorium wystarczy już tylko restart serwera.

sudo /etc/init.d/apache2 restart

Konfiguracja Apache

Integracja mod_wsgi z Django jest świetnie opisana zarówno na stronach dokumentacji Django, jak też (może nawet lepiej) na stronie rozszerzenia specjalnie poświęconej temu zagadnieniu w artykule pod pt. Integration With Django.

Ja jednak zaproponuję jeszcze inne rozwiązanie na które natknąłem się na forum w wątku Ubuntu + Apache2 + WSGI (mod_wsgi) with LAMP i lekko zmodyfikowałem na swoje potrzeby.

Aby osiągnąć wyżej opisane założenie w najprostszy sposób należy:

Stworzyć Virtualhosta w pliku httpd.conf

sudo vim /etc/apache2/httpd.conf

<VirtualHost *>
ServerName testhost
DocumentRoot /home/myuser/workspace/

<Directory /home/myuser/workspace/>
Options Indexes FollowSymLinks MultiViews ExecCGI

        AddType application/x-httpd-php .php .phtml
        AddType application/x-httpd-php-source .phps
        AddHandler application/x-httpd-php .php .phtml
        AddHandler cgi-script .cgi
        AddHandler wsgi-script .wsgi

        Order allow,deny
        allow from all
    </Directory>
</Virtualhost>

W przeciwieństwie do rozwiązania zaproponowanego na forum proponuję usunąć dyrektywę „AllowOverride None” dzięki czemu możliwe będzie skorzystanie z mod_rewrite.

Trzeba jeszcze poinformować serwer, że domyślnym plikiem w aplikacji napisanej w Pythonie będzie index.wsgi

sudo gedit /etc/apache2/mods-enabled/dir.conf

<IfModule mod_dir.c>
DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm index.wsgi
</IfModule>

W katalogu /home/myuser/workspace/ utwórzmy nowy podkatalog nowy_projekt_python a w nim plik index.wsgi o treści:

def application(environ, start_response):
    status = '200 OK' 
    output = 'Hello World!'
 
    response_headers = [('Content-type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)
 
    return [output]

Jeśli po wywołaniu

http://localhost/nowy_projekt_python

widać „Hello World!” to znaczy, że wszystko jest ok, jeśli nie to może wystarczy zrestartować serwer 😉

Twórcy Django dążą do tego aby ich framework był pythonowy jak to tylko możliwe dlatego np. konfigurację trzymają w plikach py a nie np. w xml albo yml-u. Dzięki takiemu podejściu możemy mieć pewność, że po wrzuceniu do katalogu nowy_projekt_python aplikacji Django i modyfikacji pliku index.wsgi, zobaczymy w przeglądarce to co byśmy widzieli po uruchomieniu serwera wbudowanego.

Zmodyfikujmy index.wsgi

import os, sys
sys.path.append('/home/myuser/workspace')
sys.path.append('/home/myuser/workspace/nowy_projekt_python')
 
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
 
import django.core.handlers.wsgi
 
_application = django.core.handlers.wsgi.WSGIHandler()
 
def application(environ, start_response):
	if environ['wsgi.url_scheme'] == 'https':
		environ['HTTPS'] = 'on'
	return _application(environ, start_response)

Przydałby się jeszcze plik .htaccess

<IfModule mod_rewrite.c>
# Turn on URL rewriting
RewriteEngine On

# Installation directory
RewriteBase /nowy_projekt_python/

    # Protect hidden files from being viewed
    <Files .*>
        Order Deny,Allow
        Deny From All
    </Files>

    # Allow any files or directories that exist to be displayed directly
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d

# Rewrite all other URLs to index.wsgi/URL
RewriteRule .* index.wsgi/$0 [PT]

</IfModule>

Zaproponowane tutaj rozwiązanie jest jedynie punktem wyjścia do stworzenia swojej własnej uniwersalnej konfiguracji środowiska developerskiego do pracy z projektami PHP i Python. Zapewne przydałoby się parę rzeczy inaczej skonfigurować lub też dodać kilka opcji jak np. dyrektywę zapobiegającą wyświetlaniu treści plików python w przeglądarce. Zachęcam do eksperymentowania i dzielenia się swoim doświadczeniem.