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

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

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

Pylons 0.9.4

Jarosław Zabiełło — Sun, 31 Dec 2006 02:40:00 +0100

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.