Szybki start z Rails, Merb i Pylons

Opublikowane przez Jarosław Zabiełło Sun, 16 Dec 2007 06:31:00 GMT

Celem tego tekstu jest porównanie podstawowych czynności niezbędnych do tego aby uruchomić Rails, Merb oraz Pylons. Zakładam że używany będzie

Czytaj dalej...

Tagi , , , , , , , ,  | 15 comments

SQLAlchemy - pythonowy ORM

Opublikowane przez Jarosław Zabiełło Wed, 14 Feb 2007 00:31:00 GMT

Użytkownicy Railsów mają ułatwione zadanie z użyciem baz danych. Mają swój Active Record, ładny i czytelny ORM. Może nie posiada on ani szybkości ani możliwości takich jak pythonowy SQLAlchemy, ale jest względnie elegancki1 i prosty do nauki.

W świecie ORM’ów Pythona do niedawna królował SQLObject ale jest bardzo mocno wypierany przez znacznie potężniejszy SQLAlchemy. Niestet, SA nie jest specjalnie łatwy do opanowania. Szczególnie mętne są różne opisy rozpoczęcia pracy z SA. Preferownych jest wiele styli, zupełnie wbrew pythonowemu paradygmatowi o jednej, zalecanej drodze postępowania. Jest też moduł WSGI Alchemyware która działa w miarę dobrze z jednym wyjątkiem – źle działa z bazą MSSQL.

Elixir (SQLAlchemy + składnia Active Record)

Biblioteka Elixir ma szansę stać się hitem dla Pythona, bo jest wrapperem na mocny ORM jakim jest SQLAlchemy. Elixir udostępnia bardzo ładną składnię wzorowaną na railsowym Active Record.

Migrate (SQLAlchemy + migracje)

SQLAlchemy doczekało się też projektu implementującego wersjonowanie struktury bazy – Migrate


1 Można czepiać się składni :conditions => “która wymaga klepania SQL’a”, ale to można poprawić za pomocą pluginu ez_where. Szkoda że to nie jest standardowo dodane do Active Record.

Tagi ,  | 2 comments

Pylons 0.9.4

Opublikowane przez Jarosław Zabiełło Sun, 31 Dec 2006 01:40:00 GMT

Wyszła nowa wersja pythonowego megaframeworka (korzysta z zewn., już istniejących bibliotek) do szybkiego budowania aplikacji webowych – Pylons. W wersji 0.9.4 dodano trochę poprawek i ulepszeń. M.in. jest nowy Routes 1.6.1, ulepszono introspekcję dla XML-RPC,Akcje kontrolerów są teraz generatorami a helpery oraz metoda _ (z gettext) generują teraz obiekty Unicodowe zamiast stringów UTF-8. Znowu Pylons znacznie wyprzedza, to co dopiero jest w powijakach dla Django.

SQLAlchemy

Coraz bardziej zaznacza się tendencja w używanych pod Pythonem ORM’ach (Pylons może korzystać z dowolnych) aby zamiast SQLObject wybierać raczej SQLAlchemy. Ten drugi jest uważany za znacznie bardziej wyrafinowany i o większych możliwościach. Na liście dyskusyjnej Pylonsów Ben Bangert pokazał jak w praktyce można używać SQLAlchemy.

Szablony

Pylons potrafi korzystać z dowolnych systemów szablonów dostępnych dla Pythona. Generalnie, popularne są dwa podejścia. Szablony pisane pod propgramistów lub pod webmasterów/designerów, którzy zajmują się samą kwestią prezentacji, wizualizacji i pracują najczęściej ze “wspomagaczami” takimi jak edytor Dreamweaver.

Dla tych drugich, polecane jest podejście albo takie jak promuje Django, czyli specjalnie uproszczony język szablonów umożliwiającym generowanie zaróno HTML jak i CSS, czy innej dowolnej treści.

Albo podejście jeszcze bardziej uproszczone (dla designerów, nie dla programistów), czyli koncepcja, jaką promują twórcy frameworka Zope. Chodzi o szablony ZPT, Kid czy Genshi gdzie logika szablonów jest dodana do atrybutów. Dzięki temu są one przezroczyste dla edytorów takich jak Dreamweaver i jeśli wymagana jest częsta konsultacja z designerami to takie podejście oszczędza ponownego, ręcznego dodawania logiki dla programistów.

Nadchodzi Mako

Moim zdaniem, znacznie lepszym podejściem jest podejście jakie oferują szablony Cheetah czy Myghty. Te drugie, są aktualnie najpoteżniejsze. Mają nie tylko duża szybkość, ale bardzo dobrze działający (lepszy od Cheetah) cache oraz łatwość do tworzenia komponentów, klocków wielokrotnego użycia.

Nadchodzi jednak coś jeszcze lepszego. Developerzy Pylonsów szykują zupełnie nowy system szablonów zwany Mako (http://makotemplates.org). Jest on wzorowany na najlepszych funkcjach jakie oferują Myghty, Cheetah, Genshi i Django. Jest też bardzo szybki.

Mako oferują wielostrefowe dziedziczenie (podobnie jak Cheetah i Django). Nie jest też wymagane tak jak w Myghty, aby wstawki Pythona (zaczynające się w szablonach Myghty od znaku procenta) zaczynały wiersz. Można wstawiać je w środku tekstu lub gdziekolwiek w ramach tagów <% kod Pythona %>.

<%inherit file="base.html"/>
<%
    rows = [[v for v in range(0,10)] for row in range(0,10)]
%>
<table>
    % for row in rows:
        ${makerow(row)}
    % endfor
</table>

<%def name="makerow(row)">
    <tr>
    % for name in row:
        <td>${name}</td>\
    % endfor
    </tr>
</%def>

Unikalne dziedziczenie dynamiczne (zmienna może określać które szablony mają być bazowymi dla innych). Szablony mogą być też buforowane. Można wygodnie filtrować dane w stylu Django (Python) czy Smarty (PHP).

<%!
    def myescape(text):
        return "<TAG>" + text + "</TAG>"
%>

Heres some tagged text: ${"text" | myescape}

Oczywiście można dowolny element szablonów keszować na wiele sposobów.

<%def name="mycomp" cache="true" cache_timeout="30" cache_type="memory">
    other text
</%def>

Pylons 0.9.4 ma już wbudowaną obsługę dla Mako. Wystarczy je ściągnąć z SVN:

svn co http://svn.makotemplates.org/mako/trunk mako

Po zainstalowaniu, jedyne co trzeba, to dodać opcję

template_engine='mako' 

do wywołania config.init_app w middleware.py.

Posted in  | Tagi , , ,  | 1 comment

MySQLdb & client encoding

Opublikowane przez Jarosław Zabiełło Tue, 15 Aug 2006 23:28:00 GMT

[vide: English version]

MySQLdb to główna biblioteka dla Pythona obsługująca bazę MySQL. Baza ta (od werseji 4.1 wzwyż) ma wbudowany wygodny mechanizm translacji znaków jakie mają być wyświetlane dla klienta. Oczywiście, należy założyć, że natywnym formatem danych dla bazy to UTF-8. Za pomocą prostej kwerendy (SET NAMES latin2) można wymusić aby wszelkie napisy były wypluwane do klienta w wybranym formacie (tu: iso-8859-2).

Ostatnio, przy okazji pracy z Pylons, przyjrzałem się bardzo ciekawemu projektowi: SQLAlchemy. Wszystko wskazuje na to, że SQLObject odejdzie do lamusa (tym bardziej że jego twórca coś go porzucił i planuje stworzyć nowy SQLObject2). SQLAlchemy jest nie tylko znacznie poteżniejszym ORM, ale ma także znacznie lepszą dokumentację niż SQLObject – ok. 117 stron samego tylko manuala.

Jedyny problem, jakie to typowe, to brak czytelnej opcji translacji polskich znaków. Podobny problem swego czasu znalazłem w Django (wysłałem patcha i to poprawili dodając na sztywno “SET NAMES utf8”) W wypadku SQLAlchemy nie ma opcji do definicji kodowania po stronie klienta. Manual wspomina tylko o ustawieniu kodowania dla bazy, a to nie to samo. Okazuje, się, że rozwiązanie jest bardzo proste. Podczas tworzenia połączenia do bazy wystarczy użyć dodatkowych parametrów. Nie ma potrzeby bawienia się w żadne kwerendy “SET NAMES”. Owe parametry to use_unicode i charset:

import MySQLdb
conn = MySQLdb.connect(
    user='root', 
    passwd='', 
    db='test', 
    use_unicode=False, 
    charset='cp1250')

W powyższym wypadku, MySQL będzie zakładał że klient ma odebrać teksty w formacie stringów cp1250. Zaś w wypadku użycia “use_unicode=True” zwracane będą śliczne obiekty unicodowe! Przykładowy plik konfiguracyjny dla Pylonsa korzystającego z SQLAlchemy (config/init.py) może zatem wyglądać np. tak:

from sqlalchemy import *
import sqlalchemy.pool as pool
import MySQLdb

def getconn():
    return MySQLdb.connect(
        user='root', 
        passwd='', 
        db='test', 
        use_unicode=False, 
        charset='utf8')

db = create_engine(
    'mysql://root:@localhost/test',
    pool=pool.QueuePool(getconn, pool_size=20, max_overflow=40), 
    strategy='threadlocal')
metadata = BoundMetaData(db)

test_table = Table('test', metadata, autoload=True)

class Test(object):  
    def __str__(self):  
        return self.title  

test_mapper = mapper(Test, test_table) 

W powyższym przykładzie, wymusiłem kodowanie utf8 dla klienta oraz połączenie z bazą działać będzie w puli 20-40 wątków. Właśnie tego mi brakuje w Django: pracy wielowątkowej, bo zużywa ona mniej pamięci. W/w model można użyć w kontrolerze Pylons (controllers/home.py) np. tak:

from myproject.lib.base import *
from myproject.models import *

class HomeController(BaseController):
  def index(self):        
      c.rows = select([test_table.c.id, test_table.c.name]).execute()
      return render_response('/home.myt')

Posted in , ,  | Tagi , , ,  | 4 comments