Invenzzia... po polsku

OPT 2.0.0-dev4

Zyx — nie, 02 mar 2008 11:14:00 +0100

Do ściągnięcia jest już czwarta wersja developerska Open Power Template'a. Projekt zaczyna nabierać kształtów, jako że na ukończeniu jest już główna klasa parsera. Oprócz wzmiankowanego wcześniej cache'u, zaimplementowałem nowe instrukcje oraz skończyłem prace nad snippetami tak, że w zasadzie już całe dziedziczenie szablonów działa, jak należy. Mam nadzieję, że pod koniec miesiąca biblioteka będzie już w takim stanie, że będzie nadawać się do ostrożnego użycia. Rzeczywiste projekty będą potrzebne, aby wykryć błędy oraz końcowe niedociągnięcia.

W snippetach pojawiła się możliwość wstawienia zawartości rodzica za pomocą znacznika opt:parent:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<opt:extend file="test_inherited_a.tpl">
	<opt:snippet name="header">
		<h1>Webmaster Of Puppets</h1>
		<p>Here is the parent content:</p>
		<opt:parent/>
		<p>End of the parent content</p>
	</opt:snippet>
</opt:extend>

W tym wypadku, jeżeli w pliku test_inherited_a.tpl zdefiniowaliśmy snippet o identycznej nazwie, jego zawartość trafi na miejsce znacznika opt:parent. Takie zagnieżdżanie działa wielopoziomowo. Gdyby i w tamtym snippecie użyto tego mechanizmu, OPT sięgnąłby jeszcze głębiej i tak dalej. Możliwe jest nawet wyciągnięcie domyślnej zawartości bloku opt:insert, do którego ostatecznie snippet będzie wstawiony. Do całości dodałem na dokładkę prosty kod wykrywający nieskończoną rekurencję. Gdy taka zostanie wykryta, programista otrzyma elegancki, czerwony komunikat błędu :).

Przy korzystaniu z nowego OPT powinna znacząco przydać się nowa konsola debugowa, rozszerzona w stosunku do analogicznej opcji w OPT 1.1.x. Główna zmiana dotyczy rozbicia listy wykonanych szablonów na mniejsze listy, które pokazują różne informacje:

Lista wykonanych szablonów
Lista aktualnie przekompilowanych szablonów
Lista szablonów wczytanych z cache'u.
Lista dziedziczenia szablonów - pokazuje użyte łańcuch zależności wraz z informacją, czy były one właśnie rekompilowane, czy nie.

Dodatkowo, konsola wyświetla wszystkie ostrzeżenia, które w tej wersji nie są już bezczelnie ładowane na ekran. Można się do nich dostać jedynie poprzez konsolę debugową lub komunikat błędu, o ile ustawiliśmy odpowiedni poziom debugowania.

Sprawa wydajności przedstawia się bardzo dobrze. Ostatecznie zamknąłem plik opt.class.php w około 25 KB, w porównaniu do 32 KB z poprzedniej wersji, a na chwilę obecną wpływ jego rozmiaru jest dość dobrze widoczny w wynikach, jako że PHP musi załadować taki parser i go wstępnie skompilować do wewnętrznego bajtkodu. Naturalnie, gdy pozałączamy dużo szablonów, nie będzie to aż takie widoczne, ale mimo wszystko cieszę się z uzyskanego efektu.

Paczkę można ściągnąć stąd. Zawiera ona również częściowo ukończoną polską dokumentację.

Invenzzia.org... od nowa

eXtreme — wto, 26 lut 2008 16:05:00 +0100

Powoli zaczynamy stawać na nogi. Miesiąc temu czas naglił i Zyx przygotował na szybko stronę naszej grupy oraz zainstalował devbloga. Dzisiaj prezentuję rozwiązanie bardziej rozbudowane. Niech będzie ono takim fundamentem i podstawą, dalszym krokiem w rozwoju naszej grupy. Strona została uzupełniona o teksty i informacje o grupie i choć wiele pracy jeszcze przed nami to z devblogiem sprawa jest już praktycznie zamknięta.

Całego dotCleara zainstalowałem i skonfigurowałem od nowa. Nie ma już problemów z mieszaniem się języków wpisów, ponieważ blogi polski i angielski są teraz osobnymi miniblogami jednej instalacji. Detekcja języka usera zintegrowana jest z systemem zastosowanym na stronie i oparta jest na ciasteczkach i języku ustawionym w przeglądarce. Stworzyłem też bardziej czytelny i przyjazny szablon.

A dlaczego nie Wordpress? Mam jakiś osobisty uraz, poza tym instytucja szablonów to tam praktycznie nie istnieje. Miałem swego czasu (nie)przyjemność tworzyć od podstaw jeden szablon i to była droga przez mękę. A z dotClearem2 już pracowałem wcześniej i bardzo przyjemnie się tu wszystko konfiguruje. Poza tym jest całkiem ciekawie napisany obiektowo na PHP5 więc za to duży plus. ;-)

Grupa Invenzzia nie posiada jeszcze oficialnego logo, to widoczne na stronie głównej jest rozwiązaniem tymczasowym.

Główna klasa OPT na ukończeniu

Zyx — śro, 20 lut 2008 22:12:00 +0100

Owocem dzisiejszych zmagań z kodem źródłowym nowego OPT jest ukończenie pliku opt.class.php, w którym (jak niektórym wiadomo) mieści się główna klasa parsera. Przyznam, że paradoksalnie plik ten był bardziej wymagający, niż kompilator. W tym drugim przypadku można sobie pozwolić na bardzo dużo, wystarczy pomysł na algorytm i przewidzenie, jak wpłynie on na resztę układu. Z główną klasą sprawa ma się troszeczkę inaczej. Jest ona dołączana za każdym razem, tak więc musi zawierać wszystko, co jest uruchamiane permanentnie. Musi to robić szybko, sprawnie i być nieduża. A tymczasem wymagania co do funkcjonalności rosną.

Nowa wersja developerska będzie niekompatybilna z poprzednimi pod kątem interfejsu programistycznego. Aby zaimplementować cache tak, jak chciałem, musiałem przebudować niemal całą obsługę systemu wyjścia. W serii 1.x.x pojęcie systemu wyjścia w zasadzie nie istniało. To, czy wynik działania szablonu trafi na ekran, czy do zmiennej, zależało od wyboru odpowiedniej metody. Jakieś skomplikowane przełączenia i sztuczki kierowały wszystko do miejsca docelowego, aczkolwiek nie było w tym konsekwencji i strategia działania była średnio dopracowana. Cóż, tak wychodzi, jak się zaczyna od zachowywania podobieństw do Smarty'ego, a trzeba przypomnieć, że w początkowych, pionierskich czasach, było to jednym z założeń projektu. W OPTv2 istnieje jawnie zdefiniowany interfejs ioptOutput pozwalający samodzielnie zaprogramować, co trzeba zrobić z wynikiem działania. Właśnie za jego pomocą realizowany będzie system cache, a jak - już tłumaczę.

Dotąd w kodzie były dwa systemy wyjścia: optNetOutput wysyłające wszystko na ekran i pilnujące przed dwukrotnym wysłaniem szablonu w trybie XML, oraz optReturnOutput zwracające przechwycony rezultat. Dodałem do obu możliwość dekorowania ich czym innym i utworzyłem optCachedOutput koncentrujące się w całości na obsłudze cache. Możliwości pozostaną po staremu, natomiast zmieni się sposób wywoływania i niestety trochę się rozbuduje inicjacja:

$cache = new optCachedOutput('./cache/'); // to jest cache, tu go konfigurujemy.
$tpl -> register(OPT_OUTPUT, 'my_cache', $cache);
$tpl -> decorate(OPT_OUT_SCREEN, 'my_cache');
$tpl -> decorate(OPT_OUT_RETURN, 'my_cache');

if(!$cache -> isCached('szablon.tpl', 'jakis_id'))
{
  // generuj dane
}

$cache -> setCache(5, 'jakis_id'); // włącz cache na 5 sekund
$tpl -> parse('szablon.tpl', 'my_cache');

Spróbuję jakoś skrócić i uprościć to, co widać na początku, zwłaszcza że mi też się to specjalnie nie podoba. Ponadto muszę sprawdzić, czy dekoracji przypadkiem w niewłaściwą stronę (niezgodnie z logiką i intuicją) pod względem nazewnictwa nie zrobiłem :).

Obsługa wtyczek nie jest jeszcze w pełni gotowa - ukończyłem jedynie część znajdującą się w opt.class.php, jako że reszta może spokojnie być z pożytkiem dla wydajności wyekspediowana gdzie indziej. Podobnie, jak w OPT 1.1.3, będzie możliwość ustawienia kilku katalogów z pluginami, lecz parser nie będzie już żądać w nich praw do zapisu. Wrzucane tam były dodatkowe pliki opisujące zawartość katalogu i pozwalające załączyć jego zawartość bez konieczności jego skanowania. Jednak wiadomo, że im więcej include'ów, tym wolniej wszystko działa, a niektórzy potrafią tych wtyczek naprodukować tyle, że mają tam więcej plików, niż liczy sobie cały mój framework :D. Dlatego teraz OPT będzie ze wszystkich pluginów składać jeden mega-plik zawierający wszystko, czego potrzeba nam do szczęścia. Przy okazji będę mieć również nowy algorytm do następcy OPT Toolsetu, który teraz będzie obsługiwać już wszystkie biblioteki Open Power.

Ostatnia sprawa dotyczy zestawu funkcji dostępnych w szablonach. Stormfly niedawno pisał na swoim blogu, że w OPT 1.1.x był on bezsensownie dobrany i w sumie miał rację. Popatrzyłem, co tam programiście daje Smarty i okazało się, że ma tam on w zanadrzu kilka ciekawych funkcji, które mogą być naprawdę przydatne. Wstępna lista zawiera zatem:

spacify - pomiędzy każde dwa sąsiednie znaki podanego ciągu wstawiany jest inny ciąg.
indent - robi wcięcia w tekście.
truncate - obcina tekst do maksymalnie podanej długości (można dodać nierozcinanie słów na pół)
strip - redukuje wszystkie grupy białych znaków do pojedynczego znaku.
capitalize - odpowiednik ucfirst()
upper - odpowiednik strtoupper()
lower - odpowiednik strtolower()
countWords - odpowiednik str_word_count()
countChars - odpowiednik strlen()
money - odpowiednik money_format(), lecz ustawienia można zapisać w konfiguracji OPT.
number - odpowiednik number_format(), lecz ustawienia można zapisać w konfiguracji OPT.
wordWrap - odpowiednik word_wrap()
replace - odpowiednik str_replace()
regexReplace - odpowiednik preg_replace(), lecz z ostatnim argumentem wysuniętym na początek, aby nie było niekonsekwencji.
date - odpowiednik date() :)
firstof - zwraca pierwszy niepusty element z podanych.
nl2br - odpowiednik nl2br() :)
array - tworzenie tablic po stronie szablonów.
build - to, co w poprzednim OPT się nazywało apply(), ale jeszcze nie wiem, czy ostatecznie zostanie właśnie taka nazwa.

W zestawie tym nie ma żadnych funkcji do escape'owania, ponieważ kompilator w wielu miejscach sam o to dba, a jeśli nie, będzie możliwość ręcznego zaznaczenia tego, aczkolwiek nie poprzez funkcję. W każdym razie chodzi o to, by kompilator wiedział, że coś jest escape'owane i z rozpędu sam czegoś od siebie nie dołożył, gdyż to równałoby się kaszanie na ekranie.

Naprodukowałem całkiem sporo funkcjonalności, lecz koniec końców nie zdążyłem wszystkiego przetestować, tak więc nie mam pewności, czy cały ten kod w ogóle działa, jak należy, aczkolwiek jakichś specjalnych rewelacji się nie spodziewam. W końcu np. algorytmy cache'ujące zasadą działania nie różnią się specjalnie od tego, co było w poprzednich wersjach. Kolejny dev ukaże się już za parę dni.

Na koniec mała statystyka:

- opt.class.php - 24 KB i więcej już nie urośnie. W poprzedniej wersji plik ten był o całe 8 KB cięższy, a w sumie oferował mniej.
- opt.compiler.php - 65 KB i wciąż rośnie.
- opt.instructions.php - 25 KB i wciąż rośnie.

OPT 2.0.0-dev3

Zyx — pią, 15 lut 2008 13:26:00 +0100

Zgodnie z zapowiedzią częstszego publikowania postępów prac, udostępniamy dziś trzecią wersję developerską nowego Open Power Template'a, nad którą pracowałem przez ostatni tydzień. Tym razem poświęciłem sporo uwagi przetwarzaniu atrybutów OPT, które robią różne ciekawe rzeczy ze znacznikami, do których zostały dodane. Wstępna implementacja już była - nawet przykłady dotyczące "opt:section" znajdowały się już w paczce. Jednak aby w pełni spełniała oczekiwania, trzeba było rozbudować cały kod.

Zamieszczam parę przykładów pokazujących, co ciekawego można już zrobić. Zacznijmy od czegoś prostego. W OPT do osadzania wyrażeń w treści służą nawiasy klamrowe, w których umieszczamy wyrażenie, np.

tekst tekst tekst {$blok} tekst tekst tekst

Istnieje także instrukcja opt:put, która na pierwszy rzut oka wykonuje dokładnie to samo:

tekst tekst tekst <opt:put value="$blok"/> tekst tekst tekst

Jednak dzięki temu, że to jest instrukcja, a nie nawiasy klamrowe, można z nią zrobić parę fajnych rzeczy przy pomocy atrybutów. Przypuśćmy, że chcemy uzyskać coś w stylu "Wartość 1 / Wartość 2 / Wartość 3". Wystarczy nam do tego instrukcja opt:put, sekcja i separator:

<p><opt:put value="$sekcja.wartosc" opt:section="sekcja" str:separator=" / "/></p>

Jak widać, taka sekcja obejmuje także znacznik, do którego została doklejona i możemy umieszczać wartości elementów w pozostałych atrybutach. Separator domyślnie akceptuje wyrażenia, lecz gdy nie mamy ochoty na pisanie separator="'cośtam'" (cudzysłów, a później apostrof), zmieniamy po prostu przestrzeń nazw na "str".

Ukończyłem również implementację odwróconych apostrof, które w stosunku do poprzedniej wersji zmieniają swoje działanie. Tym razem programista może samodzielnie zaprogramować ich obsługę, pisząc zwykłą funkcję i przekazując jej nazwę do parsera. Można to wykorzystać np. do eleganckiej implementacji systemu językowego a'la gettext:

<p>{`Parę przydatnych informacji...`}</p>
<p>{`Autor:`} {$autor}</p>

W końcu ostatnia ze zmian. Skoro mamy parser XML, potrzebujemy paru instrukcji, które umożliwią twórcy szablonów bezpośrednie manipulowanie drzewem, np. dodanie atrybutu o zmiennej nazwie. OPT będzie zawierać dwie instrukcje do tego celu: opt:tag oraz opt:attribute. Ta druga została dodana do najnowszej wersji developerskiej. Możemy jej użyć, aby móc wczytać nazwę atrybutu z bloku:

<div>
  <opt:attribute name="$nazwa" value="$wartosc"/>
  Treść...
</div>

To nie koniec - w połączeniu z sekcją uzyskujemy szybkie narzędzie do masowego dodawania atrybutów:

<div>
  <opt:attribute name="$atrybut.nazwa" value="$atrybut.wartosc" opt:section="atrybut"/>
  treść...
</div>

Jeśli do takiej sekcji wyślemy tablicę: array(0 => array('nazwa' => 'class', 'wartosc' => 'dude'), array('nazwa' => 'id', 'wartosc' => 'lol')), uzyskamy:

<div class="dude" id="lol">
  treść...
</div>

Dość dużo czasu poświęciłem na rozwój dokumentacji. Wprawdzie dalej jest ona nieco z tyłu za kodem, ale powoli zaczyna go doganiać. Na ukończeniu jest opis sekcji, pojawiły się omówienia metod chronionych w optClass, a nawet zalążki opisu kompilatora. Muszę też porządkować już istniejący kod, aby pasował do aktualnego stanu kodu oraz moich zamierzeń. Zachęcam do testowania i nadsyłania swych uwag.

Download: https://invenzzia.org/download/opt-2.0.0-dev3.tar.gz

Nowy dev

Zyx — sob, 09 lut 2008 10:52:00 +0100

Dodałem do strony dział "Download", przy okazji umieszczając w nim nową wersję rozwojową Open Power Template'a. Znalazł się tam również nieduży skrypcik "docgen", którego używamy do uruchamiania automatycznego parsowania dokumentacji w DocBooku. Nowe wersje rozwojowe będą teraz już publikowane znacznie częściej; w okresie dużego nasilenia prac być może nawet co dwa, trzy dni. Powód, dla którego nie były one dotąd tak częste, był brak automatyzacji, a przygotowanie takiej paczki pochłania trochę czasu (dla przykładu, umieszczenie nowej wersji OPT w Internecie zajmuje kilka godzin).

W kolejnym devie znajduje się wszystko, co zaimplementowałem w przeciągu ostatniego miesiąca:

Niemal ukończone sekcje.
Separatory.
Pętle "for" i "foreach".
W większości ukończone dziedziczenie szablonów.
Zarządzanie nagłówkami HTTP.
Częściowo ukończone parsowanie prologu.
Trochę poprawek w kompilatorze.

W katalogu "dev" można znaleźć skrypty, za pomocą których testuję poprawność działania poszczególnych instrukcji. Są też unitTesty: gotowy zestaw do testów parsera wyrażeń oraz częściowo ukończony test API. Próbuję także opracować automatyczny tester poprawności działania samych instrukcji, żeby nie bawić się w ręczne wywoływanie. Problemy stwarzają nowe linie i białe znaki w kodzie wynikowym, które wprowadzają straszny zamęt w przypadku porównywania rezultatu z wzorcówką, przez co przygotowanie jednego głupiego testu zabiera dużo czasu. Jednak coś się wymyśli. Do działania wymagana jest instalacja pakietu phpUnit 3 z repozytorium PEAR.

Licencjonowanie

Zyx — czw, 07 lut 2008 09:29:00 +0100

Co jakiś czas powraca jak bumerang sprawa licencji, na jakiej biblioteki są publikowane. Nie ulega wątpliwości, że jej dobór ma dość duże znaczenie dla popularyzacji projektu. Liberalne licencje są łatwe do interpretacji przez każdego oraz przez to bardzo łatwe w użyciu, lecz stwarzają prawo do pewnych nadużyć. Z drugiej strony mamy licencję GNU LGPL, na której dotąd był rozpowszechniany OPT. Zapewnia ona należytą ochronę kodowi, ale utrudnia łączenie z zamkniętym oprogramowaniem. A przecież biblioteka napisana w PHP dedykowana jest także twórcom stron WWW na zamówienie czy autorom kompletnych skryptów udostępnianych jako open-source bądź nie.

Postanowiłem sprawdzić, ile zajęłoby przystępne wyjaśnienie warunków LGPL przeciętnemu użytkownikowi, szczególnie nastawionemu na działalność komercyjną. Dodałem do roboczej wersji dokumentacji odpowiedni dodatek i zacząłem pisanie. Wynikiem była rozciągająca się na dwa ekrany lista z objaśnieniami, dlaczego i jak twórcy serwisów WWW na zamówienie mogą z niej korzystać, kiedy trzeba udostępnić kod źródłowy i tak dalej. Oczywiście jest to nie do zaakceptowania - sam nie lubię zbytnio zbyt skomplikowanych ograniczeń i nie mam zamiaru zmuszać w ten sposób bez wyraźnego powodu innych.

Powodem, dla którego wybrałem licencję GPL, była paradoksalnie chęć ochrony bibliotek przed zamianą w oprogramowanie własnościowe. Taki los spotkał kiedyś projekt Wine, rozpowszechniany początkowo na licencji MIT. Po pewnym czasie powstały zamknięte, komercyjne wersje dostępne bez kodu źródłowego. Co prawda jedna 150-kilobajtowa biblioteka specjalnej wartości handlowej nie ma, ale wolę spać spokojnie, tym bardziej, że mają pojawić się inne. Niestety nie ma żadnej licencji, która od razu pasowałaby do potrzeb:

- Dawała pełne prawa do łączenia zarówno z kodem open-source, jak i własnościowym pod warunkiem zachowania informacji o autorach, a w przypadku kodu źródłowego zachowania w stosunku do niego warunków licencji.
- Nakazywałaby rozpowszechnianie samej biblioteki (przeznaczonej do łączenia z innymi programami) także w postaci kodu źródłowego, co automatycznie implikowałoby zachowanie licencji.

Myślę, że takie ujęcie oprogramowania open-source najlepiej chroni prawa końcowego użytkownika. Zabraniając samodzielnej redystrybucji jedynie w postaci binarnej i ze zmienioną licencją, ma on pewność, że jeśli znajdzie jakąś paczkę OPT, będzie mógł z niej skorzystać na takich samych warunkach, jak z oryginału. Jeśli zaś trafi na zamkniętą wersję, oznacza to, że może być ona przystosowana, a na pewno jest przeznaczona do pracy z jednym, konkretnym skryptem.

Najpewniejszym kandydatem na licencję jest jakaś zmodyfikowana wersja licencji BSD bez klauzuli ogłoszeniowej. Niestety trzeba się pobawić w dodanie do niej rzeczonego warunku w języku angielskim. Dobór właściwego słownictwa trochę potrwa i zapewne nie obejdzie się bez jakiejś pomocy bądź porady kogoś z zachodu. Dlatego wersje rozwojowe w dalszym ciągu będą dostępne na GNU LGPLv3, natomiast wersję finalną przygotuję już na nowej, znacznie łatwiejszej w użyciu licencji.

Oprócz tego, chciałbym udostępnić także wersje płatne bibliotek, niezależnie od tego, że sam kod rozpowszechniany będzie niezwykle liberalnie. Nie byłyby one drogie - myślę, że cena wahałaby się w granicach 20-40 złotych tak, żeby mógł sobie na nią pozwolić niemal każdy zainteresowany. Dochód byłby przeznaczony głównie na utrzymanie domen, serwerów i cele promocyjne, gdyż utrzymanie tego wszystkiego trochę pieniędzy kosztuje. O ile pod względem kodu wersja taka nie różniłaby się od darmowej, nabywca dostawałby kilka bonusów. Aktualnie mam pomysły na następujące:

- Dodatkowe materiały informacyjne.
- Prawo do włączenia materiałów informacyjnych do dokumentacji końcowej użytkownika.
- Przykładowe projekty wraz z kodem źródłowym i szeregiem komentarzy.
- Wcześniejszy dostęp do nowych wersji (np. tydzień)
- Dodatkowe wydania pojawiające się np. w przypadku znalezienia jakiegoś nie-krytycznego błędu, zawierające stosowną poprawkę.
- Możliwość umieszczenia szerszych informacji o projekcie wykorzystującym biblioteki na stronie grupy.

Co o czymś takim sądzicie? Myślę, że na czymś takim zyskają wszyscy: my, bo nie będziemy musieli opłacać serwerów z własnej kieszeni; nabywcy, bo dostaną dodatkowe materiały i bonusy, a w dalszej konsekwencji wszyscy użytkownicy, jako że w celu ich przyciągnięcia powstawać będzie więcej tutoriali, artykułów itd.

Dziedziczenie szablonów

Zyx — sob, 02 lut 2008 12:14:00 +0100

Przeważnie kod wynikowy strony komponuje się z kilku mniejszych szablonów zawierających fragmenty kodu. Istnieje wiele technik ich łączenia. W parserach dla PHP królują jak dotąd dwa rodzaje: ręczne uruchamianie szablonów we właściwej kolejności z poziomu kodu PHP oraz dyrektywa include. Podobnie było także w poprzedniej wersji OPT, jednak w nowym wydaniu pierwszy ze sposób właściwie idzie do kasacji - o ile nie korzystamy z quirks mode, parser nie dopuści do tego, by wywołać metodę parse() dwukrotnie. Początkowo miałem zamiar zrekompensować to, rozbudowując include o tzw. sekwencje, lecz dnia pewnego na moim blogu Coldpeer zapytał się mnie, czy będzie dziedziczenie szablonów. Poszukałem, popatrzyłem i stwierdziłem, że to może być niezłe. Tak zaczęły się eksperymenty z implementacją.

Dziedziczenie szablonów pojawiło się, z tego co wiem, w systemie szablonów pythonowego frameworka Django. Idea jest wzięta z programowania obiektowego, gdzie można dziedziczyć klasy, dodając do nich nowe metody, pola oraz nadpisując istniejące. Tutaj jest podobnie. Mamy szablon główny, w którym zaznaczamy pewne charakterystyczne miejsca i wypełniamy je standardową zawartością. Drugi szablon dziedziczy po głównym i może nadpisać wybrane miejsca własną treścią. Po nim może iść kolejny szablon i tak dalej.

Okazało się, że spora część niezbędnej funkcjonalności była już w OPT 1.x - instrukcje bind oraz insert pozwalały przenosić całe fragmenty kodu w inne miejsce, także pomiędzy szablonami. Niestety, nie było tam odpowiedniego mechanizmu detekcji, czy zaszły jakieś modyfikacje w plikach i to trochę psuło całą koncepcję. Tak samo jego opracowanie dla nowej wersji było najtrudniejszym zadaniem, ponieważ nie wystarczy teraz jedynie sprawdzić, czy zaszły zmiany w szablonie, który wywołujemy, ale także czy coś nowego nie pojawiło się w szablonach bazowych! Z zamiarem definitywnego rozwiązania tego problemu siadłem do kodu wczoraj i parę godzin temu wszystko zadziałało tak, jak powinno:

Szablon bazowy (test_inherited_a.tpl):

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" lang="en_US" xml:lang="en_US">
 <head>
  <title>Instruction test: snippet and insert</title>
 </head>
 <body>
  <opt:insert snippet="header">
   <h1>I'm a standard header</h1>
   <p>Foo bar joe</p>  
  </opt:insert>
  
  <hr/>
  
  <opt:insert snippet="content">
  	<p>Well, i'm also a standard content.</p>
  
  </opt:insert>
  
  <hr/>
  
  <opt:insert snippet="footer">
  	<p>And I'm a footer.</p>  
  </opt:insert>
  
  <p>&copy; Pasteright 2008 by LMAO, It seems to work!</p>
 </body>
</html>

Szablon dziedziczący po nim (test_inherit_1.tpl):

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<opt:extend file="test_inherited_a.tpl">
	<opt:snippet name="header">
		<h1>Webmaster Of Puppets</h1>
	</opt:snippet>

	<opt:snippet name="content">
		<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Phasellus ut tellus id nulla adipiscing eleifend. Sed dictum accumsan ante. Nullam at nisl vitae elit aliquet fringilla. Praesent egestas eros eget tellus. Praesent id odio a sapien rhoncus vehicula. Nunc fringilla, diam eget euismod tempor, tortor metus tincidunt sapien, eu cursus magna tellus at risus. Praesent non tellus eget magna facilisis pulvinar. Praesent libero mi, adipiscing a, pharetra eget, condimentum sodales, mi. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Donec ac elit. Duis iaculis tortor a metus. Aliquam id purus et eros faucibus fringilla. Praesent quis quam. In lectus urna, fringilla sit amet, iaculis eget, aliquet ac, quam. Donec vulputate dui sit amet lectus. Aenean tempor, orci at pretium ornare, tortor tortor venenatis ligula, eget blandit nisi risus eget dolor. Duis nunc neque, sodales porta, viverra non, tristique eu, sem. Curabitur magna neque, blandit ullamcorper, congue quis, tristique ut, felis.</p>
	</opt:snippet>

	<opt:snippet name="footer">
		<p>Bye!!!</p>
	</opt:snippet>
</opt:extend>

Do tego kod PHP:

<?php

	define('OPT_DIR', '../lib/');
	require(OPT_DIR.'opt.class.php');

	try
	{
		$tpl = new optClass;
		$tpl -> sourceDir = './templates/';
		$tpl -> compileDir = './templates_c/';
		$tpl -> stripWhitespaces = false;
		$tpl -> printComments = false;
		$tpl -> setup();
		
		$tpl -> parse('test_inherit_1.tpl');
	}
	catch(optException $e)
	{
		optErrorHandler($e);
	}
?>

A rezultat widać poniżej:

Parę faktów:

Jeżeli zmodyfikujemy dowolny z szablonów, po którym nasz szablon dziedziczy, OPT wykona rekompilację i zmiana zostanie natychmiast uwzględniona.
Jeżeli usuniemy dowolną z instrukcji "opt:snippet", wyświetli nam się domyślna zawartość zdefiniowana wewnątrz "opt:insert".
Istnieje możliwość nadpisania już zdefiniowanego snippeta przez leżący wyżej w hierarchii szablon. Będę implementował mechanizm odwołania się do zawartości rodzica (jakaś instrukcja "opt:parent").
Można to mieszać z "opt:include" oraz "opt:sequence" (mechanizm sekwencji).

Ponadto bardzo możliwe, że dziedziczenie szablonów w ostatecznym rozrachunku może działać szybciej, niż tradycyjna metoda, aczkolwiek kosztem miejsca na dysku. Po prostu jak mamy dziedziczenie "A po B po C", wywołując szablon A, caluteńki kod wynikowy ze wszystkich szablonów jest zrzucany właśnie do A. Zmniejsza to ilość odwołań do dysku, gdyż uruchomienie jednego wielkiego szablonu jest mniej kosztowne, niż tej samej treści rozbitej na 3 mniejsze pliki. Z drugiej strony, w podstawowym trybie OPT wciąż sprawdza czasy modyfikacji (tyle że robi mniej testów). Póki co są to jedynie przypuszczenia. Dopiero po skończeniu i zrobieniu porządnego benchmarku będę w stanie podać konkretne liczby. Chociaż dodam, że z ciekawości puściłem sobie prosty test (lista 15 elementów):

OPT 1.x: 1850 req/s
OPT 2.0: 2100 req/s

Nie są to wyniki ostateczne - trzeba wziąć pod uwagę, że nowy plik opt.class.php wciąż nie ma sporej części opcji, które trochę zwiększą jego objętość, a ponadto nie zaimplementowałem jeszcze niektórych optymalizacji. Tak więc można się spodziewać, że nowe możliwości nie odbiją się niekorzystnie na wydajności, a nawet jest szansa na coś odwrotnego - nowa wersja będzie szybsza.

Głębsze przetwarzanie

Zyx — czw, 31 sty 2008 13:08:00 +0100

Ostatni projekt, jaki realizowałem z użyciem Open Power Forms, ukazał kilka słabych punktów aktualnej implementacji. Było tam kilka formularzy umożliwiających masowe dodawanie rekordów jednego typu, tj. była sobie tabelka, w kolumnach pola: Imię, Nazwisko, PESEL, coś tam innego i było tak 30 wierszy. Razem można było za jednym zamachem dodać do 30 rekordów. O ile metodę map() dało się jeszcze dość łatwo zmusić do przetworzenia czegoś takiego bez rozpisywania się, o tyle połączenie z szablonem zaczęło już wtedy szwankować.

Kod prezentował się następująco:

$this -> map('names', new opfArrayContainer(
	new opfConstraint(MAP_TYPE, TYPE_STRING),
	new opfConstraint(MAP_LEN_GT, 2)
), OPF_OPTIONAL);
$this -> map('surnames', new opfArrayContainer(
	new opfConstraint(MAP_TYPE, TYPE_STRING),
	new opfConstraint(MAP_LEN_GT, 2)
), OPF_OPTIONAL);
$this -> map('pesels', new opfArrayContainer(
	new sConstraint(MAP_PESEL)
), OPF_OPTIONAL);

Innymi słowy, do skryptu musiało przyjść np. pole "names" będące tablicą z 30-ma komórkami, w których były poszczególne imiona. Okazało się, że gdy w takiej strukturze zrobiło się gdzieś błąd powodujący, że nie chciało to przejść przez kontrolę poprawności, renderer formularzy wariował i w ogóle nie wiedział, który komponent ma oznaczyć jako błędny. Ostatecznie dodałem do kodu biblioteki na sztywno obsługę stałej IGNORE_OPF_ERRORS, tak aby po prostu siedział wtedy cicho i wyświetlał formularz bez żadnego oznaczania na czerwono itd.

Oczywiście takie rozwiązanie na dłuższą metę nie przejdzie i trzeba wymyślić jakieś usprawnienie. W dodatku dobrze, aby to usprawnienie elegancko komponowało się z resztą kodu i faktycznie było intuicyjne do pojęcia, bo nie sztuka dodać coś w 20 minut, a miesiąc później klnąć, że się nie chciało dokładniej pomyśleć. Najlepsze są rozwiązania proste i skuteczne, dlatego zacząłem się zastanawiać, czy można opisać formularz kilkoma definicjami i przekształceniami tak, aby na ich podstawie można było uzyskać dowolną konfigurację z gwarancją, że OPF ją obsłuży. Mój pomysł opiera się na tym, aby zejść nieco głębiej i zrównać w definicji formularz oraz pole formularza. Powodem jest kilka podobieństw:

Oba mogą mieć pewną wartość (przy czym dla formularza definiujemy ją jako zbiór wartości wszystkich pod-elementów)
Oba mają pewien stan oraz mogą go zmieniać w trakcie przetwarzania.
Oba są przetwarzane.

Teraz wystarczy, że potraktujemy formularz jako kontrolkę, która może przechowywać inne pola. Jeżeli spróbujemy teraz wymodelować powyższy przykład, wyglądałoby to mniej więcej tak: tworzymy sobie formularz dla pojedynczej osoby: Imię, Nazwisko, PESEL i coś tam jeszcze. Następnie osadzamy go w większym formularzu i zapętlamy tak, aby mógł pojawić się do 30-tu razy. Możemy także łatwo uzyskać efekt umieszczenia w opfArrayContainer() pojedynczego pola tak, jak to było dotychczas - po prostu umieszczamy w takiej pętli nie cały formularz, ale pojedynczą kontrolkę.

Pozostaje jeszcze kwestia nauczenia komponentów korzystania z takiej struktury, ale nie sądzę, aby było przesadnie skomplikowane, zwłaszcza w świetle tego, co szykuje nowy Open Power Template.

Zaczynamy

Zyx — śro, 30 sty 2008 12:29:00 +0100

Witam na devblogu nowej grupy programistycznej Invenzzia. Jest kilka powodów, dla których ją powołałem. Pierwszy i najważniejszy to chęć zapewnienia porządnej organizacji i infrastruktury projektom open-source, które już tworzę i które dopiero powstaną. Na początek przetransferowałem na jej poczet istniejący już od trzech lat system szablonów Open Power Template, który tutaj stanie się zalążkiem rodziny bibliotek Open Power Libraries. Aktualnie jesteśmy na początku etapu samoorganizowania się i nasza witryna internetowa będzie uruchamiana po kawałku w miarę jak powstaną kolejne jej elementy. Postaram się, aby nie potrwało to długo.

Invenzzia ma zupełnie odmienny charakter, niż to, co miało miejsce przy Open Power Board. Niemal wszystkich znam osobiście, zaś ze wszystkimi utrzymuję stały kontakt, co oczywiście pozwala na aktywniejsze angażowanie się w prace. Poza nazwą jednego projektu i jego kodem nie odziedziczyliśmy po wcześniejszych reinkarnacjach absolutnie nic, tak więc sprawa własności poszczególnych elementów oraz odpowiedzialności za ich utrzymanie jest zupełnie jasna. Własny serwer pozwala też na uruchomienie paru usług, o których wcześniej mogliśmy tylko pomarzyć.

Pora przedstawić członków grupy:

eXtreme - programista PHP/JavaScript, a także spec od XHTML/CSS. Prywatnie mój brat.
Radzio - programista PHP/JavaScript. Prywatnie kumpel z roku.
Slump - konsultant-menedżer-PR. Prywatnie jedyna osoba, która w OpenPB oprócz mnie faktycznie robiła coś pożytecznego.
Zyx - czyli ja, odpowiedzialny za projekty bibliotek, silników itd.

Naszymi pierwszymi zadaniami będzie ukończenie Open Power Template 2 oraz Open Power Forms. Mamy też kilka dalszych pomysłów, których realizacja rozpocznie się nieco później. W każdym razie postaramy się dostarczyć świetny zestaw wysokiej jakości narzędzi open-source dla PHP prezentujący zupełnie nowe podejście do wielu zdawałoby się, oczywistych spraw.