Kolejny problem jaki wylazł to zapisywanie obiektów w db4o. Początkowo założyłem sobie, że niektórym elementom będę przypisywał lokalizacje (na diagramie interfejs IResourceLink). Okazało się jednak, że pochodne IResource (IFolder, IFile) w Eclipse zawierają sporo informacji, z których zapisaniem był problem (PreferencesStore), a które z punktu widzenia AgaviIDE były zbyteczne. Ilość zapisanych obiektów była przytłaczająca, już po chwili pracy baza projektu miała ponad 1 megabajt. Biorąc pod uwagę to, że jest tam zapisywany model, który zmienia się często i w którym wyszukiwanie powinno być możliwie najszybsze sytuacja taka była nie do przyjęcia. Znowu przekopałem cały kod modelu, tym razem po to by korzystać ze klasy java.io.File. Masakra, koniec końców udało mi się całość uruchomić. Builder działa, obiekty są zapisywane (drugi obrazek). Teraz dorzucić jeszcze wyciąganie informacji z plików php i powinno być ok..

Oto output, którym w tej chwili częstuje builder.

Pomyślcie jak fajnie będzie się edytować routing.. podanie ścieżki, wskazanie akcji i gotowe.. albo konfiguracja walidatorów na podobna do tej z JSF Tools

Oczywiście przy pisaniu napotkałem problemy. Pierwszym z nich było zniknięcie klasy buildera, drugim wywalanie się db4o (dev 7.0). O ile pierwszy uraczył mnie gromadą logów o tyle drugi poza pokaźnym stosem nie dał mi nic. Typ wyjątku com.db4o.ext.ObjectNotStorableException - nazwa w miarę jasna, problem w tym, że za tym żadnego uzasadnienia, powodu dla którego wyjątek by leciał. Zero, dosłownie zero informacji.
Na forum db4o znalazłem parę postów - z nich wyciągnąłem wniosek - konieczne jest użycie taska ant, który zmodyfikuje bytecode klasy, ponieważ w przeciwnym wypadku db4o próbuje serializować obiekt, a gdy mu się nie uda rzuca w/w wyjątek.

Skrypt ant - który załatwia problem, dla potomnych (przeróbka z forum):

<project name="db4o enhance project" default="enhance" basedir=".">

	<!-- inny projekt z workspace'a -->
	<property name="model.classes.location" location="E:/agavi-ide/org.codehouse.model" />
	<!--
	położenie eclipse, db4o szpera w poszukiwaniu zależności klas, tak się składa,
	że mój kod korzysta z paru rzeczy z org.eclipse.core.resources, normalnie ta
	wstawka się nie pojawia
	-->
	<property name="eclipse.location" location="E:/eclipse-3.3/eclipse" />

	<target name="pack-model">
		<echo message="Tworzę archiwum z modelem" />
	    <jar destfile="lib/model.jar">
	        <fileset dir="${model.classes.location}/bin/">
	        	<!-- włączamy wszystkie skomilowane klasy -->
	            <include name="**/*.class" />
	        </fileset>
	    </jar>
	</target>

	<!-- classpath dla projektu -->
	<path id="project.classpath">
		<pathelement path="${basedir}/bin" />
		<fileset dir="lib">
			<include name="**/*.jar" />
		</fileset>
		<fileset dir="${eclipse.location}/plugins/">
			<include name="**/*.jar" />
		</fileset>
	</path>

    <!-- odwołanie do taska z db4o-tools.jar -->
    <taskdef name="db4o-enhance" classname="com.db4o.enhance.Db4oEnhancerAntTask" classpathref="project.classpath" />

	<target name="enhance" depends="pack-model">
		<!-- przeoranie źródeł i zależności -->
		<db4o -enhance classtargetdir="${basedir}/bin" jartargetdir="${basedir}/lib">
			<classpath refid="project.classpath" />
			<sources dir="${basedir}/bin" /> <!-- w tym katalogu db4o zajmie się plikami .class -->
			<jars dir="${basedir}/lib">
				<include name="*.jar" />
				<exclude name="db4o-*.jar" />
				<exclude name="ant.jar" />
				<exclude name="bloat-1.0.jar" />

			</jars>
		</db4o -enhance>
	</target>

</project>

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! ;-)

Pierwszym krokiem jest podpięcie własnych plików z definicjami struktur do Eclipse. Wskakujemy zatem do Window > Preferences a następnie do Web and XML > XML Catalog. Mamy tam listę definicji, których używa WST do podpowiadania składni. Jest miejsce na definicje użytkownika - zatem dorzucamy nowy wpis do obsługi autoload. Po pierwsze wybieramy nowy element. Do wyboru mamy dwa rodzaje źródeł - plik ze wskazanego projektu bądź z określonej lokalizacji. Drugi ma tą przewagę, że nie ma problemów z jego przenoszeniem pomiędzy różnymi workspace'ami. Po wskazaniu źródła z poprawnym dokumentem xsd bądź dtd Eclipse samo wypełni pola. Jedyne co pozostaje nam zrobić to kliknąć i potwierdzić.

Po tym zabiegu możemy zabrać się za edytowanie istniejących plików bądź stworzyć nowy w oparciu o kreator.. Aby to zrobić korzystamy z opcji File > New > Other z listy wybieramy XML i tworzymy na podstawie schematu. Po wybraniu tej opcji mamy dostępną listę schematów, na podstawie których WST jest w stanie wygenerować szablon dokumentu.

Koniec końców mamy w pełni funkcjonalne podpowiadanie składni w dokumencie XML. W podpowiedziach jest również dodawana informacja o krotności elementów * (zero i więcej), + (jeden i więcej), ? (zero lub jeden) a także wyświetlana dokumentacja. Gdy pracuje się z dobrze opisanym schematem - np plikiem xsd, w którym autorzy nie żałowali miejsca na adnotacje z informacjami na temat poszczególnych elementów - nie ma nawet konieczności skakania po oknach w celu doczytania informacji - jakiego atrybutu bądź znacznika użyć - po prostu mamy to od razu w edytorze. Bez jakiegokolwiek wysiłku, kilkoma kliknięciami zyskujemy funkcjonalne narzędzie. :)

Druga opcja, która jest dostępna w większości edytorów tekstowych to zdefiniowane szablony. W celu zdefiniowania nowego szablonu w preferencjach otwieramy zakładkę Web and XML > XML Files > Templates. Znajdziemy tam listę z możliwością modyfikacji. Opcję tą odkryłem przy okazji walczenia z pisaniem schema.xml dla Propela z ręki. Była niezastąpiona i zastępowała sporo pracy związanej z tępym kopiowaniem tekstu. W definicji szablonów mamy do dyspozycji kilka pre definiowanych zmiennych, są one przydatne podczas tworzenia szablonów nowych plików. Możemy również deklarować własne zmienne - ${nazwa_zmiennej}. Po wstawieniu szablonu do pliku możemy się nawigować po miejscach wystąpień zmiennych przy użyciu tabulatora. Miejsca, w których powtarzają się te same nazwy zmiennych są automatycznie uzupełniane, tak, że wpisując przy pierwszej zmiennej ${name} nie musimy powtarzać tej czynności w drugim miejscu.

Mam nadzieję, że przyda się w praktyce! Przy okazji pragnę Was, drodzy czytelnicy, poprosić o opinie na temat lightboxa, czy nie przeszkadza Wam jego użycie, być może wolicie tradycyjne linki do plików? Pomijam efekty graficzne, bo wygaszanie tła etc przy trzecim razie bardziej irytuje niż cieszy oko. Jak sądzicie - usunąć lightboxa? Momentami mam też problemy z rozmieszczaniem "obrazków" stąd są prozżucane po akapitach raz z lewej raz z prawej ponieważ przy mniejszych rozdzielczościach zachodzą na siebie, co powoduje niezbyt miłe efekty.

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. :)

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. :)

1. Nie ma nikogo kto byłby w stanie pomóc mi przy projekcie. Obaj byli developerzy zakończyli swoją przygodę z PHP. Nie ma również żadnej społeczności, która jest w stanie zająć się forum, wyłapywaniem błędów - jednym słowem - to by było to samo co robiłem wcześniej przy własnym frameworku.

2. Są projekty, które być może w tej chwili nie dorównują Mojavi 4, lecz są na tyle dobre, że w przyszłości mogą osiągnąć próg czwórki a nawet go przekroczyć.

3. Podobna sytuacja miała miejsce kiedy Sean Kerr zrezygnował z rozwijania Mojavi 3. Później prace nad czwórką przejął Tyler. Gdybym teraz miał zacząć poprawiać Mojavi 4 wyszłaby piątka, której prawdopodobnie bym nie skończył. Czy ktoś by się zajął pozostawioną wcześniejszą wersją?

4. Nie chcę tworzyć większego projektu w PHP, mocno prawdopodobne, że po miesiącu, dwóch po prostu bym zrezygnował z pisania Mojavi pogarszając i tak już wystarczająco ciężką sytuację.
Projekt, na który zwrócę teraz baczniejszą uwagę to Agavi. Jest w nim sporo znajomych rzeczy z trójki. Wersja 0.11 jest dużym krokiem w stosunku do 0.10, w której były same poprawki. W trunku widać, że developerzy nie poprzestali na poprawkach i postanowili dodać funkcjonalności. Do ciekawszych należą: routes (Symfony wymięka), translates, output types (w połączeniu z routes daje świetne możliwości), view renderers.

Oto moje rozwiązanie:

Instalacja:
Stworzyć w katalogu lib katalog layout a w nim plik ViewLayout.class.php. Jego zawartość jest wyżej.
1. Dodać w autoload.ini:

2. Dodac w config_handlers.ini linijki:

3. Stworzyć plik konfiguracyjny (np. frontend.layout.ini) w tym samym katalogu co plik z klasą. Przykładowy plik:

4. Użycie w klasie widoku:

Myślę, że mechanizm jest na tyle prosty, że można go rozszeżać do własnych potrzeb. Dla każdego layoutu powinien istnieć plik konfiguracyjny /lib/layout/.layout.ini. W następnej części postaram się opisać filtr umożliwiający request-mapping.