Jarosław Zabiełło - BLOG: Tag pylons

Szybki start z Rails, Merb i Pylons

Jarosław Zabiełło — Sun, 16 Dec 2007 07:31:00 +0100

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

Rails (v2.0.1) + Active Record + Haml
Merb (v0.4.2)+ Sequel (v0.4.3) + Haml
Pylons (v0.9.6.1) + SQLAlchemy + Mako

Wpierw musimy (jeśli jeszcze nie mamy) poinstalować stosowne biblioteki. W wypadku Rails i Merba musimy mieć Rubiego i RubyGems oraz doinstalowane gemy:

gem install -y rails haml merb sequel merb_sequel

W wypadku Pylons musimy mieć zainstalowanego Pythona oraz pakiet setuptools dający możliwość używania skryptu easy_install (taki odpowiednik RubyGems dla Pythona)

easy_install Pylons SQLAlchemy Mako

Tworzenie projektu:

Rails

rails rails_app

Merb

merb merb_app

Pylons

paster create -t pylons pylons_app

Podpięcie do bazy

Rails

Należy w pliku config/database.yml wpisać:

shared: &shared  
  adapter: mysql
  encoding: utf8
  username: login
  socket: /opt/local/var/run/mysql5/mysqld.sock
  password: haslo
development:
  database: rails_app
  <<: *shared
test:
  database: test
  <<: *shared
production:
  database: rails_app
  <<: *shared

Merb

Tu jest tak samo jak w Rails z tą różnicą, że nie ma tego pliku. Należy stworzyć Plik config/database.yml:

---
  shared: &shared  
    :adapter: mysql
    :encoding: utf8
    :username: login
    :socket: /opt/local/var/run/mysql5/mysqld.sock
    :password: haslo
  development:
    :database: merb_app
    <<: *shared
  test:
    :database: test
    <<: *shared
  production:
    :database: merb_app
    <<: *shared

Pylons

Tu, niestety, jest większa zabawa, bo zarówno Pylons jak i SQLAlchemy są bardziej złożone.

W pliku development.ini wstawiamy:

sqlalchemy.url = mysql://user:haslo@localhost:3306/pylons_app
sqlalchemy.echo = True
sqlalchemy.pool_recycle = 3600

Warto zwrócić uwagę, że parametr ‘pool_recycle’ zabezpiecza nas przed pewnym problemem w MySQL. Otóż po paru godzinach nieaktywności, potrafi zrywać zestawione wcześniej połączenie. SQLAlchemy zabezpiecza się przed tym stukając do bazy co godzinę. Active Record nie ma przed tym standardowo wbudowanego zabezpieczenia (sic!). Sequel zaś (też – jak SQLAlchemy- pracujący wielowątkowo) wyłapuje zerwane połączenia, czyści je i zestawia z powrotem.

Musimy ustawić sesję dla SQLAlchemy. Działa i czyści się po każdym przeładowaniu przeglądarki internetowej. W pliku pylons_app/lib/base.py wpisujemy:

# reszta pliku...
import pylons_app.model as model

class BaseController(WSGIController):

    def __call__(self, environ, start_response):
        """Invoke the Controller"""
        conn = config['pylons.g'].sa_engine.connect()
        model.Session(bind=conn)
        try:
            return WSGIController.__call__(self, environ, start_response)
        finally:
            model.Session.remove()
            conn.close()
# reszta pliku...

Tworzenie modeli

Rails

W Rails korzystamy z wbudowanych generatorów kodu:

$ script/generate model User
-> app/models/user.rb
...
-> db/migrate/001_create_users.rb

$ script/generate model Post
-> app/models/post.rb
...
-> db/migrate/002_create_posts.rb

Razem z modelami domyślnie są tworzone pliki z migracjami. Wpierw jednak zdefiniujmy relacje między modelami:

Plik app/models/post.rb:

class Post < ActiveRecord::Base
  belongs_to :user
  # Albo to samo za pomocą tych metod:
  # def user
  #   User.find :first,:conditions => ["id=?", id]
  # end
  # def user=(item)  
  #   self.user_id = item.id
  # end
end

Plik app/models/user.rb:

class User < ActiveRecord::Base
  has_many :posts
  # Albo to samo bardziej bezpośrednio:
  # def posts
  #  Post.find :all, :conditions => ["user_id=?", id]
  # end
end

Zdefiniujemy nie tylko struktury tabel ale też wypełnimy je przykładowymi danymi.

Plik db/migrate/001_create_users.rb:

class CreateUsers < ActiveRecord::Migration
  def self.up
    create_table :users, :force => true do |t|
      t.string :name, :null => false
    end
    add_index :users, :name, :unique => true
    User.create! :name => 'Jarek'
  end
  def self.down
    drop_table :users
  end
end

Plik db/migrate/001_create_posts.rb:

class CreatePosts < ActiveRecord::Migration
  def self.up
    create_table :posts, :force => true do |t|
      t.integer :user_id, :null => false
      t.string :title, :null => false
      t.text :body
      t.timestamps
    end
    add_index :posts, :title, :unique => true
    post = Post.new
    post.title = 'Tytuł artykułu'
    post.body = 'Treść artykułu'
    post.user = User.find_by_name('Jarek')
    post.save!    
  end
  def self.down
    drop_table :posts
  end
end

Uruchamiamy migracje:

rake db:migrate

Sprawdźmy interaktywnie (w konsoli, czyli po odpaleniu ruby script/console) czy modele działają prawidłowo.

User.find :all
# => [#<User id: 1, name: "Jarek">]
User.find(:first).posts
# => [#<Post id: 1, user_id: 1, title: "Tytuł artykułu", body: "Treść artykułu", created_at: "2007-12-15 18:16:27", updated_at: "2007-12-15 18:16:27">]
User.find(:first).posts[0].title
# => "Tytuł artykułu"

Merb

Tu wpierw trzeba wybrać jaki ORM chcemy używać (domyślnie Merb nie ma właczonej obsługi żadnego). Operacja jest bardzo prosta. W pliku config/dependencies.rb odkomentujemy linijkę tak aby było:

use_orm :sequel

Modele generujemy identycznymi generatorami jak w Rails.

$ script/generate model User
-> app/models/user.rb
...
-> schema/migrations/001_add_model_users.rb

$ script/generate model Post
-> app/models/post.rb
...
-> schema/migrations/002_add_model_posts.rb

Definicja modeli.

class Post < Sequel::Model(:posts)
  one_to_one :user, :from => :Post
  # To samo co:
  # def user
  #   User.filter(:id=> user_id).first
  # end  
  # def user=(obj)
  #   self.user_id = obj.id
  # end  
  #
  # Merb nie ma automagicznego wypełniania treścią
  # pól o nazwach created_at czy updated_at
  # Ale posiada wywołania zwrotne (też jak Rails)
  after_create do
    set(:created_at => Time.now)
    set(:updated_at => Time.now)
  end
  after_update do
    set(:updated_at => Time.now)
  end
end

class User < Sequel::Model(:users)
  one_to_many :posts, :from => :posts, :key => :user_id
  # To samo co:
  # def posts
  #   Post.filter :user_id => pk
  # end
end

W przeciwieństwie do Active Record, w Sequelu można zdefiniować (metodą set_schema) strukturę tabel w modelu (wtedy nie trzeba np. zaglądać do migracji ani bazy, aby sobie przypomnieć strukturę tabeli). Ale aby oszczędzić sobie pisania, zdałem się tu na automatyczne rozpoznanie struktury tabel przez Rubiego.

Teraz pora na migracje. Sequel też je posiada, choć różnią się troszkę składnią do tych w Active Record.

Plik schema/migrations/001_add_mode_users.rb:

class AddModelUsers < Sequel::Migration
  def up
    create_table! :users do
      primary_key :id
      varchar :name, :size => 255, :unique => true      
    end  
    User.create :name => 'Jarek'
  end
  def down
    execute 'DROP TABLE users'
  end
end

Plik schema/migrations/002_add_mode_posts.rb:

class AddModelPosts < Sequel::Migration
  def up
    create_table! :posts do      
      primary_key :id 
      integer :user_id, :null => false
      varchar :title, :null => false, :unique => true
      text :body
      datetime :created_at 
      datetime :updated_at 
    end    
    post = Post.new
    post.title = 'Tytuł artykułu'
    post.body = 'Treść artykułu'
    post.user = User.filter(:name=>'Jarek').first
    post.save
  end
  def down
    execute 'DROP TABLE posts'
  end
end

Uruchomienie migracji działa w Sequelu tak samo jak w Active Record (nawet parametr VERSION też tu działa).

rake sequel:db:migrate

No to pora na test z interaktywnej konsoli. Odpala się ją przez:

merb -i

User.all
# => [#<User:0x19477e8 @changed_columns=[], @values={:name=>"Jarek", :id=>1}, newfalse]
User.first.posts.class 
# => Sequel::MySQL::Dataset
# User.first.posts.sql
# => "SELECT * FROM posts WHERE (`user_id` = 1)"        
User.first.posts.first.title
# => "Tytu\305\202 artyku\305\202u"

Sequel nie tylko jest szybszy i używa iteratorów (oszczędzająć przez to pamięć). Jest też wielowątkowy (używa puli wątków) oraz pozwala na krokowy podgląd kodu SQL przed jakimkolwiek przeslaniem kwerendy do bazy danych. Sequel również nie zwraca liste obiektow ORM z bazy (jak Active Record) ale jeden, specjalny obiekt proxy. Pozwala to na interaktywne budowanie kodu w stopniu o wiele lepszym niż pozwala na to Active Record (czy nawet DataMapper). Sequel ma również wbudowany cache modeli współpracujący z szybkim serwerem memcached.

Pylons

Poniższa konfiguracja jest inspirowana tekstem SQLAlchemy 0.4 for people in a hurry. Pylons nie wymaga aby każdy model był w oddzielnym pliku, zatem użyjemy jednego. W pliku pylons_app/model/init.py wpisujemy:

# -*- coding: utf8 -*-
from datetime import datetime

# Zgodnie z filozofią Pythona, importujemy tylko tylko interesujące nas symbole
# aby nie zaśmiecać sobie przestrzeni nazw:

from pylons import config
from sqlalchemy import ForeignKey, Column, MetaData, Table, types
from sqlalchemy.orm import mapper, relation
from sqlalchemy.orm import scoped_session, sessionmaker

Session = scoped_session(sessionmaker(autoflush=True, transactional=True, bind=config['pylons.g'].sa_engine))
metadata = MetaData()

# Tworzymy definicje tabel:

table_users = Table('users', metadata,
  Column('id', types.Integer, primary_key=True),
  Column('name', types.String(255))
  )
table_posts = Table('posts', metadata,
  Column('id', types.Integer, primary_key=True),
  Column('user_id', types.Integer, ForeignKey('users.id')),
  Column('title', types.Unicode(255)),
  Column('body', types.Unicode),
  Column('created_at', types.DateTime, default=datetime.now),
  Column('updated_at', types.DateTime, default=datetime.now)
  )
# Zamiast tego można automatycznie wciągnąć istniejącą strukturę:
#
# table_users = Table('users', metadata, autoload=True)
# table_posts = Table('posts', metadata, autoload=True)

# Tworzymy definicje modeli.

class User(object):
    pass
class Post(object):
    pass

# Mapowanie ORM do klas SQLAlchemy i ustawienie
# relacji jeden-do-wielu
mapper(User, table_users, properties={'posts':relation(Post, backref='user')})
mapper(Post, table_posts)

Wygląda to bardziej skomplikowanie, ale SQLAlchemy ma też większe możliwości. Zasadniczą różnicą w SQLAlchemy jest rozdzielenie obiektów ORM od obiektów modelu biznesowego. Obiekty ORM zajmują się mapowaniem struktur tabel do obiektów Pythona. Są one następnie łączone z klasami SQLAlchemy. Takie rozdzielenie daje dużo większe możliwości, bo można w modelu biznesowym nawet zamapować kilka tabel do jednego modelu. SQLAlchemy ma dużo innych możliwości, o których tu nie będę teraz pisać. W każdym razie odbija się to na złożoności (ale i tak to jest prościej niż np. w javowym Hibernate).

Co z migracjami? Nie ma ich. Trzeba by było je napisać (to w sumie nie jest trudna sprawa). Stworzmy jednak strukture tabel wraz z przykładowymi danymi za pomocą SQLAlchemy. W tym celu końcówka pliku pylons_app/websetup.py powinna wyglądać następująco:

# początek pliku…

def setup_config(command, filename, section, vars):
    """Place any commands to setup pylons_app here"""
    conf = appconfig('config:' + filename)
    load_environment(conf.global_conf, conf.local_conf)

    from pylons_app.model import metadata, Session, User, Post

    log.info("Creating tables")
    metadata.create_all(bind=config['pylons.g'].sa_engine)
    log.info("Successfully setup")

    log.info("Adding some data to table 'users'")
    user = User()
    user.name = 'Jarek'
    Session.save(user)
    Session.commit()

    log.info("Adding some data to table 'posts'")
    user_query = Session.query(User)
    user_id = user_query.filter(User.name == 'Jarek').one().id
    post = Post()
    post.title = 'Tytuł artykułu'
    post.body = 'Treść artykułu'
    post.user_id = user_id
    Session.save(post)
    Session.commit()    
    log.info("Data added.")

W powyższym przykładzie widać też próbkę sposobu w jaki używa się SQLAlchemy. Każda operacja jest zamykana w ramach specjalnej sesji a sesja jest tworzona niezależnie dla każdego wątku. W SQLAlchemy praktycznie w ogóle nie ma potrzeby sięgania do kodu SQL tak jak to nagminnie widać w Active Record. Choć muszę też przyznać, że Sequel także ładnie daje sobie radę ze skomplikowanymi konstrukcjami bez konieczności uciekania się do surowego kodu SQL.

Uruchamiamy tworzenie tabel za pomocą:

paster setup-app development.ini

Interaktywny shell uruchamia się przez

paster shell

Trzeba pamiętać, że fakt uruchomienia konsoli nie oznacza, że mamy automatycznie powciągane moduły wszystkich modeli. W Pythonie nie ma magii, wszystko należy jawnie zaimportować. Także i nasz projekt.

from pylons_app import *
print model.User
# => <class 'pylons_app.model.User'>

Tworzenie kontrolera i prostego widoku.

Rails

script/generate controller home
# => app/controllers/home_controller.rb

Plik kontrolera (app/controller/home_controller.rb):

class HomeController < ApplicationController
  def index
    @user = User.find :first
  end
end

Aby użyć Haml zamiast ERb musimy w katalogu projektu odpalić komendę (nie zapomnij o kropce, która oznacza tu bieżący katalog):

haml --rails .

Plik widok (app/views/home/index.html.haml):

Użytkownik
= @user.name
posiada post(y)
%ul
  - @user.posts.each do |post|
    %li= post.title

Serwer uruchamiamy klasycznie

script/server

Merb

script/generate controller home
# => app/controllers/home.rb

Plik kontrolera (app/controllers/home.r):

class Home < Application
  def index
    @user = User.first
    render
  end
end

Aby uaktywnić Haml należy w pliku config/merb_init.rb dopisać na końcu

Merb::Template::Haml

Warto też doinstalować gemy:

gem install -y merb_helpers merb_has_rails_plugins ruby-debug

i dodać je do config/dependencies.rb

dependency 'merb_helpers'
dependency 'merb_has_rails_plugins'
dependency 'ruby-debug'

Dzięki temu będziemy mieli dostępnych trochę dodatkowych helperów z Rails. Zaś gem ruby-debug umożliwia nam wpisanie w dowolnym miejscu komendy debugger przerywającej pracę przeglądarki i kierującej wykonanie kodu do konsoli. Po jej zakończeniu przeglądarka wznawia obsługę requestu. Działa to tu tak jak w Rails. Można interaktywnie sobie operować na żywym kodzie. Warto też wiedzieć, że w Merb wszystkie pluginy są po prostu gemami. Ułatwia to zarządzanie ich wersjami.

Plik widoku jest identyczny jak w wyżej dla Railsow więc nie będę podawał jeszcze raz jego treści.

Odpalamy serwer za pomocą komendy merb i na stronie http://localhost:4000/home podziwiamy wynik. :) Komenda merb—help wyświetli wszystkie, dostępne opcje.

Pylons

paster controller home
# => pylons_app/controllers/home.py

Plik kontrolera (pylons_app/controllers/home.py):

import logging
from pylons_app.lib.base import *
log = logging.getLogger(__name__)
from pylons_app.model import Session, User

class HomeController(BaseController):
    def index(self):
        user_query = Session.query(User)
        c.user = user_query.filter(User.name == 'Jarek').one()
        return render('/home/index.mako')

Plik widoku (pylons_app/templates/home/index.mako):

Użytkownik ${c.user.name} posiada post(y)
<ul>
  % for post in c.user.posts:
    <li>${post.title}</li>
  % endfor
</ul>

Odpalamy serwer za pomocą

paster serve development.ini --reload

Pylons nie posiada trybów pracy tak jak Rails czy Merb. Wielowątkowy serwer HTTP (paster) musi dostać odpowiedni plik konfiguracyjny. Daje to w sumie więcej możliwości, bo można izolować sobie różne konfiguracje dużo bardziej niż prosty podział na tryb produkcyjny i rozwojowy.

Podsumowanie.

Rails jest bardzo bogato wyposażony w różne helpery, posiada dobrą literaturę, książki itd. Jest też bardzo łatwy do nauki i dosyć intuicyjny. Jeśli chodzi o prototypowanie, to jest prawie nie do pobicia. Niestety, można się przyczepić do jakości implementacji wewnętrznej jak i do niektórych błędów projektowych w Active Record. Myślę, że Railsom wyrósł bardzzo groźny konkurent w postaci Merba. Jest lepiej zorganizowany, spójniejszy i szybszy. Jest też tak samo prosty i intuicyjny. Czy warto się przesiadać? Wg mnie – warto. Jeśli zaś chodzi o ORM, to Sequel jest pod wieloma względami lepszym projektem od Active Record. Tu może tego nie eksponowałem, ale Sequel pozwala na obiektowe budowanie znacznie bardziej skomplikowanych zapytań niż to potrafi Active Record czy DataMapper. Po przykłady kodu Sequela odsyłam do jego strony domowej.

Co z Pylons? Korzysta z potężnego ORM’a i potężnych szablonów. Ma pełną obsługę Unicode, szablony Mako natywnie pracują na obiektach unikodowych (nie mylić ze stringami utf8). Mako mają dziedziczenie, potężny, elastyczny cache i są bardzo “pythonic” w swym podejściu do budowania modułów czy custom tagów. Niestety Pylons w całości wymaga trochę więcej wiedzy i umiejętności aby go ustawić do pracy. Rails i Merb są tu znacznie prostsze. Dzięki zaś Merb przepaść między wydajnością i możliwościami pythonowego Pylonso a frameworkami Rubiego mocno się zmniejszyla. Ci, co czepiali się wcześniej wydajności Rails nie mają teraz specjalnie na co narzekać. Ci co narzekali na ograniczenia Active Record, nie mają wymówki w zetknięciu z Sequelem. No chyba, że ktoś nie chce się uczyć Rubiego, jego sprawa. Ja jednak uważam, że Ruby to piękny język i bardzo przyjemnie się w nim pisze. A prostota Merba w porównaniu z Pylons jest (szczególnie dla osób zaczynających pracę) – powalająca.

Celem tego tekstu było pomóc osobom w początkowej fazie konfiguracji Pylons oraz Merb. Mam nadzieję, że był pomocny i dalej już każdy sobie sam da radę. Jeśli chodzi o dodatkową pomoc, to warto zajrzeć na IRC. Na serwerze freeenode istnieją kanały: #pylons, #merb, #sequel, #datamapper, #rubyonrails oraz nasze polskie #rubyonrails.pl i #python-pl. Są też polskie grupy dyskusyjne w Usenecie: news://pl.comp.lang.python i news://pl.comp.lang.ruby.

Kod źródłowy z powyższymi przykładami można pobrać stąd

Shoulda - pozbycie się magii RSpec'a

Jarosław Zabiełło — Sun, 28 Oct 2007 18:45:00 +0100

Od jakiegoś czasu w kręgach Ruby on Rails można zauważyć przesunięcie paradygmatu w zakresie metodologii testowania kodu. Popularyzowane podejście TDD (Test Driven Development) zostaje wypierane przez BDD (Behaviour Driven Development). Jedną z bardziej promowanych bibliotek jest RSpec. Mimo że kusi składnią przypominającą naturalny język angielski, próba wykorzystania RSPec w rzeczywistym projekcie szybko może stać się co najmniej kłopotliwe.

RSpec aby wyglądał tak ładnie jak wygląda, wykorzystuje dynamikę i specyficzne właściwości Rubiego. Ruby pozwala opuszczać nawiasy w metodach, niezauważenie otwierać i modyfikować klasy swoich bibliotek (w tym wbudowanych i standardowych) oraz ogólnie dosyć dobrze nadaje się do tworzenia nowych języków do specyficznych zadań (DSL, Domain Specific Language). Innymi słowy, ceną za korzystanie ze składni RSpec jest konieczność opanowania tego nowego języka. I tu zaczynają się schody…

Dokumentacja do RSpec jest najdelikatniej mówiąc, niekompletna. Przykładów użycia RSpec trzeba szukać po całym internecie. Dokumentacja wygenerowana z kodu źródłowego API do RSpec jest również słabej jakości. Brakuje przykładów, brakuje nawet wzmianki co do niektórych metod, jakie są używane. Np. weźmy taki prosty przykład:

response.should have_text(/My String/)

Próba znalezienia czegoś sensownego na stronie z API RSpec’a jest beznadziejna. Nie ma nic napisane o metodzie “response”, nie ma nic o metodzie “have_text” ani w ogóle o tym, co można przekazać do metody should(). Po prostu pojawia się coś niczym królik z kapelusza magika. I tak jest z wieloma elementami składni RSpec’a. Są jakieś pojedyńcze elementy, ale nie wiadomo które, i jak je łączyć ze sobą. Jeśli Ruby ma zbytnie skłonności do “magii”, to RSpec magia do kwadratu. Coś się pojawia i znika nie wiadomo skąd, ani dlaczego. To jest po prostu chore. Po wielu dniach takiej walki z RSpec doszedłem do wniosku, że to droga donikąd. Tylko, że z drugiej strony, cofnięcie się z BDD do TDD też nie brzmi atrakcyjnie.

Czy jest zatem jakieś wyjście pośrednie? Tzn. rozwiązanie które nie rezygnując z elegancji BDD byłoby oparty na znanych, dobrze opisanych metodach, bez żadnej kolejnej, magicznej składni? Wydaje się, że powyższe założenia spełnia projekt Shoulda. Mój pierwsze wrażenia z kontaktu z tą biblioteką, jak na razie, są dosyć dobre. Shoulda wprowadza dużo mniej nowej składni niż RSpec. Większość testów wykorzystuje stare, sprawdzone “asserty”. I o to chodzi. Nowa metodologia i znana, sprawdzona biblioteka standardowa Rubiego Test::Unit.

class UserTest << Test::Unit 
  context "A User instance" do
    setup do
      @user = User.find(:first)
    end

    should "return its full name" 
      assert_equal 'John Doe', @user.full_name
    end

    context "with a profile" do
      setup do
        @user.profile = Profile.find(:first)
      end

      should "return true when sent #has_profile?" 
        assert @user.has_profile?
      end
    end
  end
end

Jeszcze jedna uwaga odnośnie implementacji BDD w innych językach. Trochę miałem problemów ze znalezieniem biblioteki do Pythona. Znaleziona obszerna lista bibliotek do Pythona nie ma kategorii BDD. Wygląda na to, że BDD i w ogóle kwestią testowania bardziej przejmują się użytkownicy Rubiego. Ale na szczęście na stronie na stronie http://behaviour-driven.org/Implementations zamieszczono informacje których mi brakowało. Jeden z linków prowadzi do Pinocchio, który jest rozszerzeniem bibliotek Nose używanej m.in. przez framework Pylons. Co ciekawe, jest też nawet JSSpec, biblioteka BDD dla języka Javascript.

Zobacz też:

Beyond Test Driven Development: Behaviour Driven Development

Wykładowcą jest Dave Astels, współautor książki A Practical Guide to eXtreme Programming (Google TechTalks)

Shoulda – strona główna
Test/Spec – podobny pomysł co Shoulda – BDD oparte a Unit::Test.
Behavour Driven Development – strona główna BDD
Behaviour Driven Development – implementations – implementacje BDD dla: Boo, C#, .NET, Delphi, Javy, Javascript, Ruby i Pythona.
Wprowadzenie do RSpec – BDD – polskie wprowadzenie do RSpec i BDD

Django ograniczeniem w rozwoju?

Jarosław Zabiełło — Sat, 27 Oct 2007 16:31:00 +0200

Django do dobry i szybki framework do większości zastosowań. Jednakże ci, którzy chcą za jego pomocą stworzyć stworzyć większy projekt, mogę mieć później problemy z dalszym jego rozwojem…

Jednym z większych polskich projektów stworzonych w Django jest serwis społecznościowy grono.net. Niedawno w jednym z blogów ukazał się wywiad z dyrektorem działu IT tego serwisu – Albertem Szybińskim. Grono.net pierwotnie używało Javy, lecz to się nie sprawdziło. Java został zastąpiona pythonowym frameworkiem Django. Początkowo wszystko było dobrze, ale serwis się rozrastał i…

“Doszliśmy już do takiego poziomu, w którym Django zaczął być dla nas problemem. W czasie tworzenia portalu był to bardzo dobry framework, ale przy obecnym stopniu zaawansowania, Django stał się dla nas ograniczeniem w rozwoju i sami musimy go modyfikować.”

Czyli potwierdziło się to co pisałem wcześniej o Django. To system zbyt monolityczny i zdecydowanie za mało elastyczny. Django ciągnie za sobą dziedzictwo CMS Elington z jakiego wyrósł. Może dobrze sprawdza się w projektach typu “wertykalny portal dla wydawnictwa”, ale jak już chcemy coś nietypowego, zaczynają się problemy.

Na pytanie “Czy posiadając taką wiedzę jaką macie dziś, czy zdecydowalibyście się na zaimplementowanie Grono.net ponowie wykorzystując Django, czy może coś innego?” padło wskazanie na Pylons. Może nie ma tak ładnie zgrupowanych modułów w jednym miejscu jak Django, ale na pewno ma większy potencjał do tworzenia nietypowych czy skomplikowanych serwisów.

To nie Django jest prawdziwą pythonową konkurencją dla popularnego Ruby on Rails (że nie wspomnę frameworki pehapowe). Moim zdaniem, bardziej groźną dla nich konkurencją jest Pylons.

Aplikacja webowa - wybór technologii

Jarosław Zabiełło — Sat, 25 Aug 2007 21:22:00 +0200

Dość często spotykam się z prośbą o to, jaką technologię (i framework) bym polecił do tworzenia aplikacji webowych. Dziedzina aplikacji webowych rozwija się bardzo prężnie i trudno tak naprawdę przewidzieć, co będzie najlepszym wyborem za parę lat. Niniejszy artykuł stanowi krótkie podsumowanie moich doświadczeń w tej dziedzinie na dzień dzisiejszy.

Nie wierzę w przyszłość architektur webowych opartych na językach kompilowanych, statycznie typowanych.

Na ten temat można by dużo dyskutować. Po prostu nie wierzę w przyszłość budowania aplikacji webowych w językach C# czy Java. Każda zmiana kodu wymaga rekompilacji, wymiany dll itp. Mam złe doświadczenia z ASP.NET. Bardzo wolno i mozolnie się tworzy i debuguje kod. Z kolei Java (tzn. aplikacja webowa pisana napisana w tym języku) jest ciężka i skomplikowana. Aplikacje webowe są dosyć specyficzne. Znacznie lepiej sprawdzają się tam języki wysokopoziomowe i interpretowane. Nie trzeba nic restartować, rekompilować, efekty zmian są prawie natychmiastowo dostępne. Myślę, że większość aplikacji webowych, szczególniej małej i średniej klasy złożoności, zostanie opanowana przez języki interpretowane. Po części już to uczynił PHP. Jednakże…

Nie wierzę w przyszłość PHP.

Na temat wszystkich wad PHP mógłbym dużo pisać. W każdym razie nie mogę się nadziwić, dlaczego jego tworcy wciąż inspirują się składnią Perla i Javy zamiast wzorować się na prostocie i elegancji Pythona czy Ruby. PHP nie nadaje się do modularyzacji, tworzenia komponentów. Próbowałem już kiedyś uzyskać efekt komponentów w Smarty. Nie da się. Głównym problemem jest kolizja nazw klas i funkcji. Przestrzeń nazw miała być dodana w PHP5. Nie dodali, bo nie umieli. PHP brnie więc nadal w swoim chaosie wielkiej, wspólnej przestrzeni nazw dla swych wszystkich, chaotycznie nazwanych funkcji o niespójnej kolejności przekazywanych parametrów. Czy w PHP nie da się napisać dobrej aplikacji? Owszem, da. Jak ktoś się uprze to i w Assemblerze taką napisze. Tylko jakim kosztem… Kierunek rozwoju tego języka wygląda na przypadkowy. Sam język jest źle zaprojektowany. Nie wierzę w jego przyszłość tym bardziej, że wyrosła mu poważna konkurencja.

Fenomem Ruby on Rails.

Powodem rosnącej popularności Ruby on Rails, wbrew zazdrosnym opiniom co niektórych, na pewno nie jest tylko efekt dobrego marketingu. To także efekt pewnej, nowej filozofii w podejściu do tematu. Rails mocno postawił na prostotę i elegancję kodu połączoną z kompleksowością rozwiązania. Do tego dobrze dobrane wartości domyślne (ograniczające ilość niezbędnych konfiguracji) plus wygodne generatory kodu prowadzą człowieka dosłownie za rękę. Rails doczekał się też dobrego IDE co powoduje, że w tym frameworku pracuje się dosyć przyjemnie. Jest przejrzysty i czytelnie zorganizowany. Zainspirował i znalazł już wielu naśladowców, ale nigdy nie uzyskają one jego elegancji i prostoty z prostej przyczyny: siłą Rails jest prostota i dynamika języka Ruby. Dynamika większa nawet od Pythona. Sukces Railsów wzmacnia także lawinowo rosnąca ilość książek.

Rails zaczyna się wdzierać do rozwiązań korporacyjnych. Nie zastąpi on z pewnością Javy, ale na pewno lepiej od niej nadaje się do szybkiego stworzenia dynamicznych interfejsów webowych. Z chwilą okrzepnięcia JRuby (javowej implementacji Rubiego), Rails oparty na Javie (ale ze składnią Rubiego) może zrobić jeszcze sporo zamieszania.

Jednakże, jest technologia, może nie aż tak prosta, ale na pewno pod wieloma względami dojrzalsza i szybsza.

Django i Pylons.

Tak jak Rails, Django powstał na bazie aplikacji zastosowywanej komercyjnie. Podobnie też do Rails, stara się podchodzić kompleksowo podając na tacy określony (autorski) ORM, system szablonów i sposób rozwiązywania adresów URL. Django jest szybsze od Railsów. Wynika to dwóch rzeczy. Python (jako język) jest szybszy od Rubiego oraz Django od początku było projektowane z myślą o optymalizacji wydajnościowej. (Rails skupiał się od początku na uzyskaniu funkcjonalności, zrzucając optymalizację na później). O zaletach Django pisałem rok temu. Django pożera też wyraźnie mniej pamięci niż Rails odpalany na mongrelach.

Niestety, można się przyczepić do kilku rzeczy. Główna krytyka Django dotyczy jego zbytniej monolityczności i mniejszej elastyczności. Rails pozwala podpinać się do wielu baz, Django tylko do jednej. Rails posiada migracje do kontrolowania ewolucji struktury bazy. Django nic takiego nie posiada (tzn. jest w fazie rozwojowej gdzieś w bocznych gałęziach repozytorium SVN). Rails posiada świetne helpery do generowania adresów URL. Djangowy system adresów jest znacznie gorszy. Nie ma możliwości zmiany struktury aplikacji i wygenerowania zmienionych linków we wszystkich szablonach. Rails, dzięki helperom to umożliwia. Rails posiada świetne helpery i specjalne szablony uproszczające korzystanie z AJAX’a, Django nic tu nie oferuje.

Wiele z wymienionych wyżej wad nie posiada pythonowy konkurent Django – Pylons. Pisalem o tym ponad roku temu, że Pylons skopiował prawie wszystkie helpery jakie posiada Rails. Rozwiązuje adresy też w podobny sposób umożliwiając bardziej elastyczne modyfikowanie struktury kontrolerów. Wszystkie zależne adresy URL są generowane za pomocą helperów w sposób podobny do Rails. Pylons w zasadzie to taka sklejanka zewnętrznych bibliotek Pythona. Wykorzystując standardowy mechanizm WSGI, Pylons pozwala na wymianę prawie każdego swojego elementu, od ORM, po system szablonów czy resolver adresów URL.

Wiele z elementów, jakie domyślnie oferuje Pylons przewyższa elastycznością i możliwościami to, co dostępne jest w Django. Np. Pylons korzysta domyślnie z SQLAlchemy, który jest potężniejszy od tego w Rails i Django¹. Nie tylko bez problemu pozwala podpiąć się do kilku baz, ale także do bardziej skomplikowanych struktur². Domyślny system szablonów Mako jest najlepszym systemem jaki znam. Oferuje rozbudowaną³ obiektowość, prostą składnię, doskonały cache dowolnego fragmentu i wg dowolnych zasad. Coś, o czym np. Rails może tylko pomarzyć⁴. No i Pylons udostępnia szybki, wielowątkowy serwer HTTP który można bez problemu używać zarówno do deweloperki jak i produkcyjnie. Ani Django ani Rails nie obsługują wielowątkowości. Pylons obsługuje, dzięki czemu też ma mniejsze zapotrzebowanie na pamięć.

Pylons oferuje więc więcej możliwości, ale kosztem większej złożoności. Django jest trochę prostszy do opanowania. Cała dokumentacja jest w jednym miejscu. Nauka Pylons wymaga sięgnięcia do oddzielnej dokumentacji SQLAlchemy, Mako czy Routes. Sam SQLAlchemy jest też bardzo rozbudowany i trudniejszy do opanowania.

Zope 3 – najwyższa poprzeczka.

Napisany w Pythonie, obiektowy, wielowątkowy serwer aplikacyjny Zope od dawna uchodził za “zabójczą aplikację” Pythona. Powstało do niego tysiące pluginów. Jednym z najsłynniejszych jest Plone CMS (wg mnie najlepszy CMS jaki napisano). Zope 2.x był jednakże krytykowany za zbytnią złożoność i bałagan w API. Nauczenie się Zope wymagało sporo wysiłku także z powodu słabej dokumentacji. Większość lekkich frameworków Pythona powstało trochę na bazie kontestacji Zope. Na szczęście, twórcy wyciągnęli lekcję z Zope 2 i kod dla wersji 3 został napisany od zera. Znacznie uproszczono i uporządkowano API.

Rails, Django czy Pylons są groźną konkurencją przede wszystkim dla popularnego PHP. To jest mniej więcej dziedzina ich zastosowań. Zope zaś to trochę inna filozofia i inna grupa docelowa. Zope ma ambicję aby konkurować z najpoważniejszymi zastosowaniami klasy enterprise opanowanymi głównie przez Javę.

Przede wszystkim Zope to serwer aplikacyjny w pełni obiektowy i o budowie komponentowej. Każdy komponent ma ściśle zdefiniowane interfejsy⁵. Zope korzysta standardowo z prawdziwej bazy obiektowej. Nie potrzebuje żadnego wspierania się wrapperami ORM. Baza obiektowa zapisuje całe obiekty Pythona w sposób transparentny i stanowi naturalne przedłużenie pisanego kodu. Zope 3 ma oczywiście wbudowane wszystko co potrzebuje typowa aplikacja webowa, dobry cache, wbudowane mechanizmy bezpieczeństwa, przepływu danych, lokalizacji interfejsu (i18n, l10n) itp. Pozwala też na przeładowywanie komponentów bez restartu serwera. Jeśli potrzeba nowej funkcjonalności, wystarczy napisać nowy komponent i podpiąć do serwera. Nie ma znaczenia czy tym komponentem będzie “artykuł”, czy “plik graficzny” czy cały system redakcyjny, bądź CMS.

Te możliwości jednak nie są bez wad. Do największych zaliczyłbym słabą promocję (to w ogóle jakaś przypadłość Pythona i jego aplikacji) oraz wciąż za słabą dokumentację. Na szczęście ta ostatnia rzec się trochę poprawiła. Nawet są już książki dedykowane specjalnie dla Zope 3.3. Zope potrzebuje też znacznie więcej pamięci niż taki Django czy Pylons.

Ku przyszłości.

Dziedzina aplikacji webowych rozwija się bardzo dynamicznie i trudno coś przewidzieć w dalszej przyszłości. W związku z dynamicznym rozwojem procesorów wielordzeniowych, kto wie, czy renesansu nie przeżyje język Erlang (bo doskonale się nadaje do programowania współbieżnego). Być może renesans przeżyją serwery kontynuacyjne, które zapewniają zachowanie stanu dla aplikacji webowej eliminując potrzebę używania sesji. W serwerze kontynuacyjnym, pisanie kodu dla aplikacji webowej, czy desktopowej, prawie niczym się nie różni. Na razie najbardziej znanym serwerem tego typu jest napisany w Smalltalku – Seaside. Duży potencjał ma też Ruby, bo posiada wbudowaną obsługę kontynuacji.

Na pewno obawa co do znalezienia pracy w Rails czy Pythonie raczej nie ma dużego uzasadnienia. Jest wiele firm używających Pythona. Najlepszym przykładem jest Google, który prawie wszystko ma oparte na Pythonie. Od czasu do czasu pojawiają się w Polsce dramatyczne ;) wołania o programistów Pythona, więc choć ofert nie ma tyle co dla Javy i .NET, to można coś wyszukać. Jeśli chodzi o Ruby on Rails, to ofert zaczyna być coraz więcej, jest już trochę więcej niż dla Pythona. Rails pędzi na pełnej szybkości i dzięki dobre promocji wdziera się coraz szerzej do świadomości programistów głównego nurtu. Sam pracuję w firmie gdzie główny system oparty jest na Springu i Hibernate, technologiach Javy. Jednakże do tworzenia aplikacji webowej został wybrany Ruby on Rails.

Podsumowując powiedziałbym, że współczesny programista musi operować kilkoma językami i technologiami. Dzisiaj pracuje się w heterogenicznym środowisku i wykorzystuje mieszane technologie. Kto myśli, że nauczy się tylko jednego, doskonałego języka i tylko jednego frameworka, pewnie mocno się rozczaruje w zderzeniu z rzeczywistością⁶.

Do lekkich webowych interfejsów z dużą ilością AJAX’a wybrałbym Rails. Także dla osób początkujących, pragnących nabrać dobrych nawyków, wybrałbym Rails⁷. Tam, gdzie wymagane jest jednak dobre wsparcie dla Unicode oraz gdzie wydajność jest bardziej kluczowa, wybrałbym Pylons⁸. Z kolei, jeśli chcemy uderzyć w rynek bardziej kompleksowych rozwiązań dla biznesu, Zope 3 będzie raczej trudny do pobicia. I w końcu, tam, gdzie potrzebujemy gotowego, dobrego forum i taniego hostingu najlepiej sprawdzi się PHP (tak, najlepsze, gotowe do użycia forum są napisane w PHP).

Apendix: Jest dostępne kolorowanie składni Mako dla kilku edytorów (TextMate, Emacs, Vim i Komodo). (2007-09-12)

¹ Tak w ogóle to kwestia porównania Active Record, SQLAlchemy i Django nie jest taka oczywista. Każdy posiada coś, czego nie posiada drugi. Np. Active Record posiada eleganckie walidatory, których nie ma w SQLAlchemy. Z kolei Django nie umie podpiąć się do wielu baz, ale posiada wygodne, wysokopoziomowe pola w modelu. SQLAlchemy zaś podepnie się do najbardziej pogmatwanej struktury, wielu baz i to wszystko w elegancki, obiektowy sposób, a nie z brutalnymi wstawkami kodu SQL, jak ma miejsce w Active Record. Poza tym SQLAlchemy potrafi optymalizować zapytania tak, aby kilka poleceń wykonać możliwe najmniejszą ilością kwerend i połączeń z bazą.

² Rails nie ma problemu podpięcia się do wielu baz. Zaś struktury takie jak złożone klucze główne potrafi obsłużyć za pomocą odpowiednich pluginów.

³ Mako pozwala na więcej niż proste dziedziczenie tak jak ma Django. Pozwala na kaskadę dziedziczenia.

⁴ Rails ma słabe możliwości w zakresie buforowania danych. Np. nie potrafi buforować fragmentów szablonów w oparciu o unikalny klucz (z parametrów adresu URL lub w oparciu o inne kryteria).

⁵ Sam Python nie posiada wbudowanej składni do tworzenia interfejsów czy klas abstrakcyjnych. Autorzy Zope 3 jednak je częściowo zasymulowali korzystając z tego, co oferuje język.

⁶ W tym wszystkim za mało padło o znajomości JavaScript. Nie jest to zbyt prosty i intuicyjny język, a ma spore możliwości i jest bardzo dynamiczny. Jego znajomość jest absolutnie niezbędna dla każdej osoby chcącej tworzyć aplikacje internetowe. O CSS i XHTML nie wspominam, bo to oczywiste podstawy.

⁷ Rozpoczynanie przygody z tworzeniem aplikacji webowych od PHP jest najgorszą rzeczą jaką możemy zrobić. PHP za bardzo zachęca i utrwala złe nawyki programistyczne. To właśnie miał na myśli DHH, twórca Rails, kiedy porównał PHP do… diabła. :)

⁸ A co z Django? Jeśli mam wybierać między Django a Pylons, to wolę Pylons. Ma większe możliwości i osiągnął wystarczającą dojrzałość aby podważyć dominację i popularność Django w kręgach pythonistas. Jedną z polskich firm, która wdrożyła i używa z sukcesem Pylonsów jest firma, w której spędziłem parę lat i gdzie wdrożyłem kiedyś Pythona – Wydawnictwo Murator. Pozdrowienia dla ekipy. :)

Szablony i wzorzec MVC - cz. III

Jarosław Zabiełło — Sun, 14 Jan 2007 04:25:00 +0100

W poprzedniej części omówiono szablony dedykowane głównie do współpracy z designerami bojącymi się programować. Były to albo szablony wkładające swoją logikę do znaczników XML/XHTML (ZPT, SimpleTAL, Kid, Genshi, MasterView, PHP TAL), albo szablony posiadające swój własny, specjalizowany język (Smarty, Django, Jinja, Liquid). W założeniu taki język miał być prostym substytutem języka używanego w warstwie kontrolera. Szablony tego typu może są wygodne dla designera, ale na pewno nie dla programisty, który musi je przygotować. Po pierwsze, trzeba się uczyć kolejnego języka… szablonów. Po drugie, wszystkie tego typu języki są ograniczające dla programisty. Mimo że pozornie prostsze, w praktyce są bardziej złożone i to nawet dla designera. Np. szablony Django i Jinja nie posiadają żadnej składni na określenie trywialnego warunku większości, mniejszości:

{{ x }} jest 
{% if x > y %} 
    większe 
{% else %} 
    mniejsze 
{% endif %} 
od {{ y }}

Powoduje to masę kłopotów dla programisty¹. Prymitywna składnia szablonu wymusza więc kupę dodatkowej pracy. O ileż prościej jest użyć po prostu pełnej składni języka tak jak to robią szablony Cheetah:

$x jest 
# if x > y 
    większe 
# else 
    mniejsze 
# endif  
od $y

Dochodzimy tu więc do sytuacji kiedy byśmy chcieli coś bardziej elastycznego – pełnego dostępu do języka programowania. Taka sytuacja jest pożądana wtedy kiedy i tak szablony budują programiści na podstawie dostarczonego czystego kodu HTML od designerów.

PHP

Język PHP jest dosyć specyficzny, bo w istocie jest to język szablonów. Tzn. pierwotnie tak został stworzony, ale z czasem się skomplikował że dostąpił miana języka skryptowego. Ale jego korzenie widać w składni, która z definicji jest zagnieżdżaniem instrukcji PHP wewnątrz kodu HTML. Idąc tym tropem, niektórzy pomyśleli, że nie ma sensu wymyślać dodatkową składnię. Wystarczy użyć PHP w odpowiedni sposób. I tak powstały szablony Savant.

Właściwie to Savant nie powinny nazywać się szablonami, bo to nic innego jak PHP użyty w taki sposób, aby rozdzielić warstwę prezentacji, od wartwy logiki biznesowej. A skoro to PHP, to odpada nauka dodatkowej składni oraz potrzeby kompilacji specjalizowanego języka szablonów do końcowego kodu PHP (jak to ma miejsce w szablonach Smarty).

Czy takie podejście jest lepsze, czy gorsze, to już każdy może sobie ocenić. Moim zdaniem PHP ma na tyle mętną składnię, że warstwa prezentacji używająca Smarty² jest bardziej czytelna niż czysty PHP jaki używają Savant.

Ruby

Kiedy mówimy o Ruby w kontekście stron internetowych to najczęściej mamy na myśli jego najsłynniejszy framework – Rails. Ruby sam w sobie nie jest związany z HTML tak jak PHP. Rails do szablonów używa biblioteki ERb (ang. “embed Ruby”, czyli “zagnieżdżony Ruby”) Składnia jest bardzo podobna do PHP, JSP czy ASP. Ruby jest tu językiem zagnieżdżonym w HTML.

<%= x %> jest 
<% if x > y %> 
    większe 
<% else %>
    mniejsze 
<% end %>
od <%= y %>

Python

Jeśli chodzi o Pythona to istnieje cała masa systemów szablonowych. Ograniczę się do paru, tych bardziej interesujących.

Spyce

Szablony Spyce zostało stworzone jako pythonowa konkurencja dla PHP. Podobnie potrafią przeplatać język (tu: Pythona) z tagami HTML. Najbardziej oczywista przewaga Spyce wynika z faktu używania języka Python, który jest znacznie lepiej zaprojektowany i posiada dużo więcej możliwości niż PHP. Spyce potrafii budować własne znaczniki (custom tags, podobnie jak to potrafią javowe JSP) oraz łatwiej w nich zbudować komponenty, kod do wielokrotnego użytku.

Myghty

Szablony Myghty powstały pierwotnie jako pythonowa implementacja systemu komponentowego Mason dla Perla. Mimo wielu podobieństw, Myghty są znacznie potężniejsze o Masona, np. intensywnie wykorzystują obiektowość Pythona (zobacz różnice). Od początku Myghty powstało z myślą o dużych obciążeniach, ciężkich, profesjonalnych zastosowaniach. Mają doskonały własny cache, są bardzo szybkie, odporne na wątki, świetnie się nadają do tworzenia komponentów.

Programiści Pythona bardzo cenią sobie filozofię tego języka (która podkreśla prostotę, oczywistość i elegancję składni). Problem w tym, że Myghty dla pythonowców jest zbyt podobne do Perla. Są za mało “pythonic” – pythonowe. Dodatkowo, poprzez podkreślanie swojej komponentowości, Myghty niektórym zbyt kojarzy się z filozofią komponentową frameworku ASP.NET (a wzorzec MVC wydaje się być bardziej przejrzysty niż wzorzec sterowanych zdarzeniami komponentów). Myghty, jako system komponentowy, może być używane w stylu MVC, ale nie jest to takie naturalne i oczywiste. (Na szczęście, wszystko zmienił Pylons który zapewnia przejrzystą pracę zgodną z wzorcem MVC i Myghty są tam zredukowane tylko do obsługi szablonów szablonów. Sterowaniem zajmują się kontrolery Pylonsa a nie Myghty).

Cheetah

Szablony Cheetah posiadają jedną z najbardziej czytelnych i eleganckich składni. Autorzy wzorowali się trochę na javowych Velocity i Webmacro. Tym, którzy cenią sobie czystość Pythona z prostotą składni szablonów z pewnością Cheetah mogą przypaść do gustu. Przez dłuższy czas były moimi ulubionymi szablonami i do te pory lubię ich klarowność. Cheetah posiadają elegancką składnię obiektowego budowania szablonów potomnych na bazie już istniejących. Myghty też to potrafi, ale Cheetah to ma bardzo czytelnie zrobione. Cheetah są również bardzo szybkie.

Mako

Mako to najmłodsze dziecko stworzone przez programistów Pylonsów. Powstały na bazie doświadczeń i najlepszych cech szablonów Myghty, Cheetah, Django/Jinja czy Smarty. Największą ich zaletą jest ogromna szybkość i pythonowa filozofia pracy. Programiści Pythona mogą zauważyć, że składnia Mako jest bardzo bliska sposobowi pracy w samym języku Python. Mako posiadają wielką łatwość tworzenia komponentów, ale w sposób bardzo podobny do tego jak Python wykorzystuje swoje moduły. Szablony można także rozszerzać na drodze obiektowego dziedziczenia. Dziedziczenie szablonów może być określane w sposób dynamiczny (tego już nie potrafią np. Cheetah). Dowolny fragment szablonu można również zamienić na komponent z własnym cache. Mako posiadają także składnię modyfikatorów, które spopularyzowane zostały przez Smarty. Działają one jak uniksowe pipes (${zmienna|filter}.

Mako automatycznie kompilują swój kod do modułów Pythona. Można je więc debugować tak jak zwykły kod Pythona (Cheeatah wymaga ręcznej kompilacji). Można je bez problemu używać jako niezależną bibliotekę. Nie są one zależne od jakiegokolwiek frameworku. Można je zintegrować z dowolnym frameworkiem używającym standardu³ WSGI. Użytkownicy frameworka Pylons prawie nic nie muszą robić, bo Mako są już tam przygotowane do pracy.

Ogólnie rzecz biorąc, Mako to – moim zdaniem – najlepszy aktualnie istniejący system szablonów dla Pythona.

Zaś co do frameworków… to coraz bardziej zaczynam nabierać pewności, że przyszłość nie należy ani do Django, ani do Railsów. Nic nie może równać się z możliwościami czystego, 100% frameworka WSGI. Takim jest np. Pylons. Ale o tym, i o “bitwie” Pylons vs. Django i Rails, napiszę już innym razem.

Appendix 2007-01-29: Zobacz też szablony Haml .

¹ Poprawnie rzecz mówiąc, powinien napisać swojego helpera. Jeśli więc chcemy wyświetlić w pętli rekordy z bazy, a widok jest czuły na zawartość tych danych, to powinniśmy cała listę rekordów wrzucić do helplera, przeiterować w pętli, dodać dodatkową zmienną i dopiero tak zmodyfikowaną listę przekazać do szablonu.

² Smarty mimo posiadania własnej składni pozwala na odpalanie pełnego języka PHP: {php}print phpinfo();{/php}. Tak praktyka jest jednak odradzana, bo wprowadza jeszcze większy bałagan niż już jest w PHP.

³ Zobacz artykuł Introducing WSGI: Python’s Secret Web Weapon oraz prezentację koncepcji WSGI na video.

Pylons + Mako

Jarosław Zabiełło — Tue, 02 Jan 2007 04:46:00 +0100

Mako – nowy, wydajny system szablonów dla Pylonsów jest już dostępny publicznie na stronie http://makotemplates.org. Można go pobrać za pomocą setuptoolsów, czyli skryptem:

easy_install Mako