import java.util.concurrent.TimeUnit;
// ...
TimeUnit.MINUTES.toSeconds(55);

Fajna sprawa – jeśli mamy do czynienia z konwersjami. Inny pożyteczny przykład to przekazywanie czasu jako argumentu:

package org.code_house.concurrent;

import java.util.Date;
import java.util.concurrent.TimeUnit;

public class Lock {
    void lock(TimeUnit unit, long value) throws InterruptedException {
        Thread.sleep(unit.toMillis(value));
    }

    public static void main(String[] args) throws Exception {
        System.out.println("before " + new Date());

        new Lock().lock(TimeUnit.SECONDS, 30);

        System.out.println("after " + new Date());
    }

}

Programista, który używa takiej klasy nie musi się więc przejmować konwertowaniem jednostek na milisekundy, które są podstawą do wywołania metody Thread.sleep.

TimeUnit obsługuje następujące wielkości:

• nanosekundy
• mikrosekundy
• milisekundy
• sekundy
• minuty
• godziny
• dni

Posługując się kodem z Javy postanowiłem sobie przypomnieć nieco PHP i napisałem wersję tego typu wyliczeniowego dla PHP:

<?php
// namespace org\code_house\util;
/**
 * A simple class for converting between time units.
 *
 * @author Łukasz Dywicki <luke@code-house.org>
 */
class TimeUnit {

    /**
     * Nanoseconds.
     */
    const NANOS     = 0;

    /**
     * Microseconds.
     */
    const MICROS    = 1;

    /**
     * Milliseconds
     */
    const MILLIS    = 2;

    /**
     * Seconds.
     */
    const SECONDS   = 3;

    /**
     * Minutes.
     */
    const MINUTES   = 4;

    /**
     * Hours.
     */
    const HOURS     = 5;

    /**
     * Days.
     */
    const DAYS      = 6;

    /**
     * Conversion table between time units.
     * @var array
     */
    private static $modifiers = array(
         self::NANOS     => 0.000000001,
         self::MICROS    => 0.000001,
         self::MILLIS    => 0.001,
         self::SECONDS   => 1,
         self::MINUTES   => 60,
         self::HOURS     => 3600,
         self::DAYS      => 86400,
    );

    /**
     * Constructs new time unit.
     *
     * @param $type TimeUnit Time unit base.
     */
    public function __construct($type) {
        if ($type < TimeUnit::NANOS || $type > TimeUnit::DAYS) {
            throw new RuntimeException('Time unit base is out of range');
        }
        $this->type = $type;
    }

    public function toNanos($value) {
        return TimeUnit::convert($this->type, $value, TimeUnit::NANOS);
    }

    public function toMicros($value) {
        return TimeUnit::convert($this->type, $value, TimeUnit::MICROS);
    }

    public function toMilis($value) {
        return TimeUnit::convert($this->type, $value, TimeUnit::MILLIS);
    }

    public function toSeconds($value) {
        return TimeUnit::convert($this->type, $value, TimeUnit::SECONDS);
    }

    public function toMinutes($value) {
        return TimeUnit::convert($this->type, $value, TimeUnit::MINUTES);
    }

    public function toHours($value) {
        return TimeUnit::convert($this->type, $value, TimeUnit::HOURS);
    }

    public function toDays($value) {
        return TimeUnit::convert($this->type, $value, TimeUnit::DAYS);
    }

    /**
     * Convert method.
     *
     * @param $from Time unit
     * @param $value Number of values.
     * @param $to Time unit
     * @return decimal
     */
    private final static function convert($from, $value, $to) {
        if ($from === $to) {
            return $value;
        }

        $value *= self::$modifiers[$from];
        return $value / self::$modifiers[$to];
    }
}

// przykład użycia
$unit = new TimeUnit(TimeUnit::SECONDS);
echo $unit->toMinutes(60) ."\n";

$unit = new TimeUnit(TimeUnit::HOURS);
echo $unit->toMinutes(1) ."\n";

?>

Niestety brak pól z modyfikatorami public static final w PHP uniemożliwił zastosowanie choćby czegoś podobnego do typu wyliczeniowego.. Kod klasy dla PHP jest wolnodostępny. :-)

package pl.dywicki.swe.domain;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity(name = "user")
@Table(name = "user", schema = "public")
public class User {

	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	@Column(name = "user_id")
	private long id;

	@Column(name="user_login")
	private String login;

	@Column(name="user_password")
	private String password;

	public long getId() {
		return id;
	}

	public void setId(long id) {
		this.id = id;
	}

	public String getLogin() {
		return login;
	}

	public void setLogin(String login) {
		this.login = login;
	}

	public String getPassword() {
		return password;
	}

	public void setPassword(String password) {
		this.password = password;
	}

}

Co umożliwia takie rozwiązanie? Przede wszystkim dzięki zastosowaniu adnotacji spada ilość dodatkowych plików zawierających konfiguracje i mapowania. Oczywiście nie da się ich dzięki temu rozwiązaniu wykluczyć zupełnie, aczkolwiek da się znacznie ograniczyć ich użycie. Wielką zaletą, o której do tej pory nie wspomniałem, w przypadku Javy, jest to, że adnotacje możemy odczytywać w czasie uruchamiania programu a nie przed jego kompilacją.

Adnotacja od strony technicznej

Jak można zadeklarować własną adnotację? Służy do tego specjalna konstrukcja:

public @interface Name {
   String value() default "anonymous";
}

Użycie takiej adnotacji:

@Name // poprawnie
public class Component {}

@Name("user.session") // również poprawnie
public class User {}

Możemy również przekazać kilka wartości gdy zadeklarujemy w adnotacji odpowiednie pole:

public @interface Relation {
   String[] belongsTo();
   String offer();
}

Użycie takiej adnotacji:

@Relation(belongTo = {"users", "groups"}, offer = "privileges")
public class PrivilegesEntityMapping {}

Warto tutaj wspomnieć o dwóch magicznych umowach. Po pierwsze atrybut o nazwie value jest domyślnym przypisaniem wartości podanej w nawiasach. Tzn przy wywołaniu @Name(”user.session”) możemy pobrać atrybut poprzez annotationInstance.value(). Po drugie dodanie po nazwie pola default “wartość” pozwala na pominięcie atrybutu przy definicji. Z ograniczeń, jakie mają adnotacje w Javie – wartościami atrybutów mogą być ciągi znaków, typy (klasy) oraz typy wyliczeniowe (enumy).

Jak użyć adnotacji? Korzystając z reflection api.

Name instance = getClass().getAnnotation(Name.class); // Name.class to typ naszej adnotacji.
System.out.println(instance.value());

Adnotacje a PHP

Jak wcześniej wspominałem, adnotacje nie są elementem PHP, chociaż ludzie pokusili się już o zbudowanie mechanizmu podobnego do tego, który jest w Javie. Jednym z takich projektów jest Addendum. Warto zaznaczyć, że nie jest to nazwa wyssana z palca a słowo “addendum” ma swoje znaczenie również w języku polskim i ogólnie rzecz biorąc znaczy dodatek do jakiegoś tekstu (więcej informacji na wikisłowniku).

Jak wygląda użycie adnotacji w PHP? Jednym z przykładów może być Torpedeo. Projekt tego samego autora co Addendum, będący implementacją lekkiego ORMa. Przykładowa deklaracja obsługiwana przez Torpedeo:

<?php
/**
 * @Table('nodes')
 */
class Node {
	/** @Integer */
	public $id;

	/** @String */
	public $title;

	/**
	 * @Integer
	 * @Nullable
	 * @Column('parent_id');
	 */
	public $parentId;

	/** @Boolean */
	public $visible;
}
?>

Addendum wymaga by klasy adnotacji rozszerzały klasę Annotation:

<?php
class Nullable extends Annotation {}
class Transient extends Annotation {}
?>

Dodatkowo biblioteka dostarcza rozszerzeń reflection API z PHP5 umożliwiające odczytywanie adnotacji. Dokładny tutorial jak używać tego narzędzia można znaleźć na oficjalnej stronie projektu.

Adnotacje w PHP?

Pytanie czy adnotacje w PHP przyjmą się tak samo dobrze jak w Javie? Zdaje się, że by o tym mówić jest zbyt wcześnie, ponieważ projektów, które korzystają z tego mechanizmu jest na chwilę obecną bardzo mało. Sądząc jednak po tym jak szybko rozwinął się xdoclet można twierdzić, że to tylko kwestia czasu. Chociaż.. może w Javie po prostu jest więcej plików konfiguracyjnych?

Wspólny, najwygodniejszy format (zarówno w odczycie i zapisie danych) z jednej i drugiej strony to oczywiście XML. Problem w tym, jaki format ma być wykorzystany. Nie da się przecież bezpośrednio odwzorować obiektu z PHP do Javy głównie z racji na dynamikę. Jeśli w PHP ktoś dorzuci pole do obiektu, poprzez proste $someUser->city = 'Białystok' to Java bazująca tylko na statycznych, zadeklarowanych polach w klasie nie odczyta tej informacji. Serializacja w postaci specyficznej dla PHP również wiąże się ze stworzeniem parsera po stronie Javy by to wszystko obsługiwać i dodatkowo coś co by później mapowało obiekty z Javy do XMLa w postaci przyjaznej dla PHP. Wyjściem z całej sytuacji okazały się funkcje wddx_*. Po prostu strzał w dziesiątkę. WDDX to standard może nie najnowszy, ale dosyć spójny, i co najważniejsze umożliwiający przesyłanie złożonych obiektów bez zbytniej walki. Po chwili poszukiwań znalazłem DTD, zatem ze strony Javy wystarczy odpalić JAXB i jesteśmy na miejscu.

Przykładowy skrypt PHP, który uzyskuje informacje o konfiguracji Agavi:

A teraz część wyniku, który PHP wyświetla w konsoli:

Teraz kod Javy, który odczytuje sobie informacje.. (nawiasy kwadratowe przy listach podyktowane błędami w skrypcie, który koloruje składnię)

		// odpalamy interpreter PHP
		Runtime runtime = Runtime.getRuntime();
		Process exec = runtime.exec("php -q E:/agavi-ide/org.codehouse.bridge/src/org/codehouse/bridge/test2.php");

		// podnosimy kontekst JAXB
		JAXBContext context = JAXBContext.newInstance(ObjectFactory.class);
		// deserializujemy XML wygenerowany przez PHP
		WddxPacket object = (WddxPacket) context.createUnmarshaller().unmarshal(exec.getInputStream());

		// odczytujemy informacje
		for (Object stc : object.getData().getWDDXData()) {
			// spodziewamy się informacji o typie złożonym
			if (stc instanceof Struct) {
				List[generated.Var] vara = ((Struct) stc).getVar();
				for (Var value : vara) {
					// pozostaje nam tylko odczytanie zserializowanej wartości
					List[Object] configurationValue = value.getWDDXData();
					System.out.println(value.getName() + ": " + ((generated.String) configurationValue.get(0)).getvalue());
				}
			}
		}

Wynik działania poniższego kodu to:

Czyli wszystko czego trzeba było nam do szczęścia! :)

Pora na przykład bardziej złożony, wyciągnięcie informacji o jakiejś klasie widoku użytej w aplikacji opartej o Agavi.

Drobna przeróbka kodu Javy, który był użyty wcześniej i wynikiem jest

Tym, którzy dobrnęli do końca tej noty dziękuję za wytrwałość. :) Kolejna nota będzie być może o tym jak wywoływać metody statyczne klas Javy z poziomu XSLT (wierzcie mi, da się!).

Czas jakiś temu udało mi się stworzyć pierwszy działający edytor w oparciu o Eclipse.
Kilka informacji co pod spodem:

• SharedHeaderFormEditor - ładny tekstowy nagłówek oraz możliwość dodawania zakładek
• FormPage i FormToolkit - użyte do stworzenia układu, który widać na załączonym obrazku
• JFace Databinding - zapewnia propagowanie zmian z formularza do obiektów
• JAXB 2 - mapowanie plików XML do odpowiednich klas
• JFace - table viewer i parę innych dodatków

Całość ogólnie jest prosta niczym konstrukcja cepa, w działaniu sprawia się dobrze. Jak tylko ogarnę kod postaram się opisać krok po kroku jak można coś podobnego stworzyć na własny użytek.

Splatch wraca do gry i będzie grać wysoko! ;-)

Pojawiły się drobne zmiany w API do obsługi configów oraz nowy sposób ich odczytu, który wejdzie do użytku w wersji 1.0. Póki co jest tylko testowy a jedynym handlerem, który został zaimplementowany "na nowo" jest ten obsługujący WSDL.

Dodam, że Agavi to pierwszy framework PHP, który rozwiązuje kwestie dostępu do akcji w tak elastyczny sposób. Niezależnie od tego jakim sposobem zostało przysłane żądanie akcja wygląda tak samo. Jest to krok w stronę dojrzałych rozwiązań tj Spring Framework. Pytanie tylko - czy developerom uda się zachować pierwotną prostotę i ile pracy trzeba będzie włożyć w użycie danego rozwiązania? Odpowiedź na nie pozostaje póki co zagadką a pełnej oceny będziemy mogli dokonać po ukazaniu się wersji 1.0 wraz z dokumentacją.

Zainteresowanych naturalnie Agavi zapraszam do traca i przeglądania źródeł wersji 0.11 RC5. :)

Zacznijmy od tego, że trzeba potrafić rozróżnić interfejs od klasy abstrakcyjnej, to nie to samo!
Interfejs jest najwyższym poziomem abstrakcji, który definiuje nowy, wolny od implementacji typ. Bez jakiejkolwiek linii kodu, tylko sygnatury metod publicznych.
Klasa abstrakcyjna jest już początkiem konkretnej implementacji, zawiera kod ogólny i wymusza w klasach dziedziczących dorzucenie konkretnych metod, które są specyficzne, inne, różne. Mogą trafić się takie przypadki, że klasa abstrakcyjna zawiera 5 metod, a jej pochodne tylko jedną. Czy jest to uzasadnione? Oczywiście. Ta jedna metoda determinuje nowy typ, który jest jawną specjalizacją.

Warto pamiętać, że w chwili gdy mamy klasę abstrakcyjną i kilka jej pochodnych dorzucenie interfejsu jest polisą na życie. Spójrzmy, na praktykę - co się powinno dziać w chwili, gdy pojawiają się kolejne pochodne oraz klasa abstrakcyjna rozrasta się do niebagatelnych rozmiarów? Wyodrębniamy wspólny interfejs (patrz extract interface) i kolejne klasy abstrakcyjne.
Bez problemu dorzucamy kolejny typ i lecimy bez przestojów. W chwili gdy uzależnimy się od klasy abstrakcyjnej z jakimkolwiek kodem z biegiem czasu możemy mieć do czynienia z klasami, które zawierają po 10, 20 i więcej metod. Nawigacja po tak rozbudowanym typie jest uciążliwa a zrozumienie kodu wymaga przebrnięcia przez stos metod, które tworzą swoisty labirynt.
Rozsądne użycie interfejsów i klas pozwala nam tworzyć złożone ale przejrzyste struktury. Separacja abstrakcji od implementacji określana mianem wzorca projektowego, nazwa mostem (ang. bridge).

Budowa złożonej aplikacji bez użycia interfejsów jest posunięciem wysoce nierozsądnym, ponieważ to właśnie dzięki nim, nawet w językach kompilowanych ze statycznym typowaniem jesteśmy w stanie zyskać nadzwyczajnie elastyczny kod. W aplikacji, która jest rozwijana od dłuższego czasu (powiedzmy, ponad pół roku) to właśnie interfejsy są miejscami zawierającymi definicję poszczególnych warstw. To one powinny być trzonem każdej aplikacji (pomijając warstwę obiektów domenowych, gdzie ich rola nie musi być dominująca). Nawet jeśli koncepcja implementacji obróci się o 180 stopni to nasz interfejs, będący swoistą fasadą, ukryje te zmiany przed osobami, których one nie dotyczą bądź nie interesują.

Dorzucę tutaj przykład pewnego mechanizmu, który jakiś czas temu projektowałem i implementowałem. Jest to uproszczony schemat. Singletonu chciałem uniknąć, ale przesłanki ku jego zastosowaniu były na tyle duże, że pozostał. Duże I na początku nazwy oznacza interfejs, w nawiasach, dużymi literami wzorce.

Panowie, jak byście zaimplementowali te mechanizmy bez interfejsów? Jedną, wielką protezą?

Pamiętam swoje pierwsze implementacje MVC, w czasach gdy słowo framework nie było jeszcze trendy a wiele osób, w tym i ja, nawet go nie używało. W owych pierwszych implementacjach MVC model był pewnego rodzaju fasadą, która zapewniała dostęp do danych.
Problem polegał na tym, że kod np klasy User wyglądał następująco:

<?php
class User extends Model {
    function User(DB $db) {
        parent::Model($db);
    }

    function getById($id) {
        $sql = 'SELECT * FROM user WHERE user_id = '. $id;
        return $db->query($sql);
    }
}
?>

Jak widać na powyższym listingu klasa jest odpowiedzialna za pobieranie danych. Problem takiej implementacji polega na tym, że wciąż operujemy na tablicach bądź na ResultSetach zwracanych przez obiekt odpowiedzialny za wykonywanie zapytań. Kod w takim wykonaniu jest mocno związany z bazą danych i jest ciężki do użycia w innych projektach. Co więcej w pierwszym podejściu nie korzystałem z wielu możliwości jakie daje programowanie obiektowe i po prostu odwołania do klasy nadrzędnej czy też metody abstrakcyjne były co najmniej sporadyczne. Także, każdy "model" miał swoją metodę getById, która miała swoje zapytanie. Jest to najprostsza implementacja, która zapewnia tylko jedno - wyłączenie zapytań do oddzielnych plików.

Wzorce

Znacznie lepszym krokiem byłoby wykorzystanie możliwości chociażby dziedziczenia i użyć nazwanego przez Martina Fowlera wzorca ActiveRecord, który zapewnia nam mapowanie pojedynczej encji do klasy.

Problem, jaki powstaje przy użyciu ActiveRecordu to niestety uzależnienie kodu od wybranej implementacji wzorca, co więcej kod będzie nieprzenośny, np nie da się go użyć bez zewnętrznych bibliotek. Zatem problem pozostaje taki jak był wcześniej - logika, która była związana z danymi (np przeliczanie wartości jednego pola w zależności od drugiego) została zawarta w modelu staje się bezużyteczna.

Problemy te można rozwiązać wyraźnie oddzielając obiekty z których korzysta aplikacja od warstwy dostępu do nich. Tutaj rodzi się pojęcie Domain Model czy też Domain Object. Przede wszystkim jest to kod, który jest niezależny od źródła danych np obiekt Invoice możemy pobrać zarówno z bazy jak i z zewnętrznego systemu powiedzmy przez usługę sieciową. Obiekt zawsze zachowa się w ten sam sposób i jego użycie nie będzie zależne od miejsca z którego je uzyskaliśmy. Idealnym przykładem implementacji Domain Modelu są np beany utrwalane przy pomocy Hibernate. Mamy kod, który jest przenośny, w którym nie ma żadnych jawnych odwołań do informacji zawartych poza "obiektami domenowymi", jest ona po prostu autonomiczna.

Ciężko jest określić czym w pierwszej kolejności się zająć bazą czy obiektami biznesowymi? Wydaje mi się, że modelując najpierw bazę danych ciężko jest wychwycić dziedziczenia pomiędzy obiektami biznesowymi i najzwyczajniej w świecie zostaną one pominięte. Z drugiej strony tworząc najpierw obiekty biznesowe możemy natrafić na trudności z odwzorowaniem całej, nie raz, złożonej struktury do encji w bazie.

Data Access Objects

Dostęp warstwy z obiektami domenowymi realizujemy przez Data Access Objects. Jest to zespół klas, które zapewniają odczyt, usuwanie oraz zapisywanie obiektów (całość modyfikujemy przez dostępne w obiektach domenowych metody). DAO ma na celu zapewnienie jednolitego interfejsu dla dostępu do obiektów bez pojawiania się kodu specyficznego dla danego źródła danych, niezależnie czy to będzie baza danych czy usługa sieciowa.

Service Layer

Warstwa usług to miejsce przecięć różnych źródeł danych. Granica między DAO a Service Layer jest dość istotna - DAO obejmuje transakcje systemowe podczas gdy Service Layer transakcje biznesowe. Może słowo wyjaśnienia na temat tych dwóch rodzai transakcji - pierwsza jest zwykle kontrolowana przez bazę danych i zawiera ciąg poleceń SQL. Transakcja biznesowa obejmuje jedną konkretną operację np przelew bankowy - to logowanie, określenie kwoty i odbiorcy, weryfikacja kodu jednorazowego oraz zablokowanie środków. Powodzenie takiej operacji zależy od wielu czynników w tym od systemów zewnętrznych.
Warstwa usług jest bardzo przydatna w chwili gdy z tej samej logiki korzysta więcej niż jeden system. Niestety nie mam wielkiego doświadczenia z takimi sytuacjami i nie czuję się na siłach by o tym pisać, a to co tu przytoczyłem to głównie to co pamiętam z PoEAA.

To co jest bolesne w execution flow oferowanym w Agavi to niestety jego prostota. Przede wszystkim brakuje mi (jak w wielu miejscach Agavi) interfejsów. Jest to dla mnie naturalne, że dążę do generalizacji, interfejs jest podstawowym elementem, który uniezależnia od implementacji. Interesuje nas to, co jest widoczne na zewnątrz a nie to co wewnątrz implementacji. Brakuje mi opakowań dla tych tablic, które informacje o widoku. Prosty kontener, bean, który zawiera tylko informacje, ale nie jest tablicą. Przede wszystkim mam możliwość kontroli danych, które otrzymuje. Mogę już w fazie tworzenia obiektu reprezentującego flow wstępnie przeprowadzić jego walidację (czy widok istnieje?).
Zmiany w akcjach i widokach jest jak najbardziej pozytywna i rzeczywiście usprawnia działanie całości. Nie mniej do wersji 2.0 w Agavi na pewno zajdzie ich jeszcze sporo, miejmy nadzieję, że również w celu uporządkowania struktur, usunięcia nadmiaru klas abstrakcyjnych i zastąpienia ich interfejsami (pamiętaj, zanim napiszesz linijkę w klasie, która jest autonomiczna, a której implementacja może się zmieniać, generalizuj, twórz typ bazowy).

Pytaniem ciągle jest czy Agavi podąży w stronę Symfony? Jak najmniej pisania.. Twórcy Symfony ochrzcili wersję 1.0 swojego frameworka nazwą, czy też przydomkiem "enterprise". Ciężko mi powiedzieć czy było to uzasadnione. Temat Symfony-Agavi często pojawia się w rozmowach między Michałem Mechem a mną. Obaj jesteśmy zgodni w dwóch kwestiach - w Symfony pisze się bardzo szybko oraz ma ono bardzo dobrą dokumentację. Nie ustępuje ona pod żadnym względem dokumentacji Zend Frameworka.

Myślę, że najlepszym życzeniem dla nas wszystkich będzie to: by developerzy Agavi nadążyli z dokumentacją za implementacją.

W pliku konfiguracyjnym output_types.xml określamy renderer dla danej technologii, dodajemy obiekty przedefiniowane (parameters name="assigns") i następnie konfigurujemy mapowania adresów do plików (swoją drogą najlepsza implementacja tego mechanizmu z jaką się do tej pory spotkałem). Jest odpowiedni plik zawierający definicję routingu.

Zajmijmy się jednak w pierwszej kolejności konfiguracją output types:

Jak widać trochę tej konfiguracji jest, nie mniej celowo usunąłem przekazywanie parametrów do drugiego formatu wynikowego by pokazać, że w najskromniejszej wersji definicja taka potrafi się zmieścić maksymalnie w 10 linijkach.
Do wszystkich parametrów możemy odwoływać się w widoku. Specyficzne są parametry o nazwie assigns oraz i18n. Pierwszy z nich Agavi wykorzysta po to by od razu w fazie tworzenia renderera wrzucić do niego wskazane obiekty, które znajdują się w kontekście. Drugi z atrybutów jest szczególnie przydatny podczas tworzenia aplikacji z wieloma językami. Parametr i18n jest prefiksem dla nazwy pliku. W przypadku gdy przypiszemy mu wartość subdir framework będzie szukał szablonów po katalogach np. pl/IndexSuccess, en/IndexSuccess. Inne, dopuszczalne wartości to postfix oraz prefix. Nazwy szablonów to odpowiednio IndexSuccess_pl oraz pl_IndexSuccess
Atrybut extension określa suffix dla nazwy pliku, którego użyje Agavi przy wczytywaniu szablonu np IndexSuccess.tpl.php.
Argumenty ignore_slots oraz ignore_decorators odnoszą się do strategii budowania widoku. W chwili gdy zrezygnujemy z nich wynik nie będzie dekorowany. Tzn. w odpowiedzi użytkownik zobaczy tylko treść wygenerowaną przez widok akcji.
Tutaj drobna uwaga. W wersji stabilnej Agavi 0.11 mechanizm ten zachowuje się nieco inaczej. Wybór plików oraz zachowanie dekoratora determinuje layout i elementy layer.

Następnie w routes.xml dla każdej ścieżki możemy określić również format wynikowy danych. Np:

W tym momencie, wszystkie adresy kończące się na /ajax będą obsługiwane w nieco inny sposób niż pozostałe. To znaczy, że nie będzie dekorowany output. Dodatkowo zostaną użyte inne pliki szablonów do generowania treści.

Zdaję sobie sprawę z tego, że opisałem ten mechanizm dość chaotycznie i bardziej skupiłem się na jego konfiguracji, ale na przykładową aplikację będziecie musieli poczekać do czasu gdy skończę artykuł dla PHP Solutions (czyżby Agavi tematem numeru?) bądź do pojawienia się nowego Code-House. :)

Jedną z wad Propela, która pojawia się chyba najczęściej jest XML i definiowanie tabel w pliku XML. Otóż drodzy moi, nie jest to konieczność. Schemat z istniejącej bazy danych można bez problemu przenieść do XMLa a następnie bez najmniejszego problemu wygenerować z niego klasy. Możemy zrobić to dwoma poleceniami. Pierwsze jest dostępne po instalacji przy pomocy PEARa, drugie przy korzystaniu z Phinga:

Naszym oczom ukaże się kilka informacji o przebiegu całego procesu, po czym będziemy mogli korzystać z wygenerowanych klas. :)

Propel 1.3
Propel 1.3 korzysta z PDO dlatego też, task "creole" niestety nie działa. Jeśli ktoś chce korzystać z możliwości generowania schematu musi niestety korzystać na przemian z wersji 1.2 i 1.3 (1.2 generuje schemat, 1.3 generuje klasy).

Migrowanie pomiędzy bazami danych
Propel umożliwia zrzucenie struktury bazy danych do pliku zawierającego definicje tabel. Aby to zrobić wystarczy skorzystać z taska sql. Warto pamiętać, że schemat SQL jest budowany na podstawie pliku XML. Zmieniając jedną dyrektywę w konfiguracji generatora (propel.database.url) można bez problemu przenieść całą bazę

Przenoszenie danych
Istnieje również możliwość przeniesienia danych z istniejącej bazy, służy do tego task datadump. Propel zrzuca zawartość wszystkich tabeli do plików XML po to by móc następnie wygenerować z niego zapytania insert. Aby to zrobić wystarczą dwa polecenia:

Propel a ociężałość
Trudno się nie zgodzić, że używanie narzędzi typu ORM powoduje wydłużenie czasu wykonywania skryptu, ale jak by nie patrzeć, znacznie też skraca czas potrzebny na tworzenie kodu odpowiedzialnego za warstwę DAO, co zwykle tuż po tworzeniu widoku zajmuje najwięcej czasu.
Myślę, że warto tu wspomnieć o Propelu 2.0, który ma obsługiwać dostęp do pól przez metody __get i __set dzięki czemu całość może stać się lżejsza a ilość kodu, który jest generowanego ulegnie widocznemu zmniejszeniu.