Zaczniemy w kolejności chronologicznej. Rzecz pierwsza to tzw. nazywane parametry funkcji. W dotychczasowym kodzie funkcje wywołuje się dokładnie tak samo, jak w PHP - w nawiasach podajemy listę argumentów oddzieloną przecinkami i musimy pamiętać ich kolejność. eXtreme proponował, aby można było przypisywać wartości także według nazwy parametru, coś na kształt poniższego: funkcja(parametr1 := wartość, parametr2 := wartość, parametr3 := wartość). Pomysł byłby niegłupi, gdyby nie ograniczenia techniczne powodujące sprzeczność z samą ideą funkcji w OPT. Funkcja jest zrobiona tak, że od strony szablonu w ogóle nie musimy przejmować się, gdzie została ona zaimplementowana: normalnie w skrypcie, w silniku PHP, w pluginie czy też może jest metodą statyczną (tak, jest taka możliwość :)). Gwarantowała to uniwersalna składnia oraz możliwość przypisania jej innej nazwy w momencie rejestrowania, niż miał oryginał. Co więcej, składnia ta była przenośna, bowiem identycznie wyglądało odwoływanie się do metod. Nazywanych parametrów nie da się wprowadzić do wszystkich tych rodzajów i nagle zaczyna nabierać znaczenia ich rzeczywista postać funkcji, dotąd przed twórcą szablonu schowana. W grę przy odczytywaniu dozwolonych nazw parametrów wchodziłoby ReflectionAPI (bez obaw - miałoby to miejsce tylko raz, w czasie kompilacji, a tam specjalnie się wydajnością nie trzeba martwić). Sytuację komplikuje dodatkowo wprowadzenie przestrzeni nazw w PHP 5.3, a biblioteka musi być z tą wersją kompatybilna. Mamy więc:

1. Funkcje w aktualnej przestrzeni nazw - da się uzyskać listę nazw parametrów.
2. Funkcje w innej przestrzeni - nie da się bez znajomości budowy skryptu. Przestrzeń nazw może być równie dobrze nazwą klasy statycznej. Aktualnie nie mam pojęcia, w jaki sposób przestrzenie nazw będą realizowane w Reflection API, a nawet gdyby były, kod musi być kompatybilny choć trochę wstecz.
3. Metody statyczne - jw. tylko na odwrót. Nazwa klasy może być równie dobrze przestrzenią nazw, nie wiem, jak takowe będą obsługiwane, a kod musi być trochę kompatybilny wstecz.
4. Metody w obiektach - nie ma szansy pobrania takich informacji bez posiadania obiektu, a poza sekcjami dynamicznymi w jednym z trybów nie ma obowiązku rejestrowania przed kompilacją wszystkich bloków, jakie są używane w szablonie. Ponadto skoro metoda zależy od obiektu, ciężko jest prorokować na podstawie jednego z nich, co może się trafić.

Ostatecznie zgodziłem się na następujący kompromis: nazywane parametry będą tam, gdzie jest taka możliwość, ale jako niestandardowe rozszerzenie składni, jako że kłóci się z założeniami OPT. Domyślnie będzie ono wyłączone, a gdyby komuś strzeliło do głowy napisać własną implementację OPT, nie ma obowiązku ich implementowania :).

Drugi pomysł jest mojego autorstwa i powstał z chęci oddzielenia szablonów od API skryptu, który ich używa. Wiele tego typu elementów już się w bibliotece znajduje: bloki językowe, instrukcja systemu stronicowania czy sekcje. Problem pojawia się w przypadku danych z systemu uprawnień. Przekazywanie każdej głupoty jako osobnego bloku jest dość męczące i stwarza ryzyko popełnienia błędów. Można udostępnić w szablonie cały obiekt, lecz wtedy wiążemy go na stałe z jednym, konkretnym API (a ja np. mam jedną szatę graficzną do panelu administracyjnego, która przeżyła już kilka zmian silników :)). Jeśli mamy szczęście mieć metody statyczne, wtedy rejestrujemy to jako funkcję i problemów jest trochę mniej. Natomiast ja pomyślałem następująco: w OPT mam dwa ograniczniki ciągów tekstowych, które poza wyglądem się niczym nie różnią. Jeden z nich można zaakceptować do systemu uprawnień. Oto próbka:

<opt:if test="`attachments`">
  ... wyświetl formularz dodawania załącznika
</opt:if>

Napis `attachments` zostanie przekonwertowany na wywołanie żądanej przez autora skryptu funkcji/metody i powinien on dać w efekcie wynik logiczny true lub false. Co myślicie o takich ulepszeniach?

Oczywiście gdyby ktoś nie chciał ani jednego, ani drugiego, z pomocą przyjdzie mu nowy OPT Toolset. Sądząc z opinii znalezionych w sieci, pomysł takiego preprocesora wycinającego z kodu to, co niepotrzebne, bardzo się ludziom spodobał i w nowej wersji narzędzie to będzie bardziej dopracowane. Na pewno pojawi się obsługa alternatyw, a być może także pobieranie i konfigurowanie w locie nowych wersji z sieci? Nowa domena i serwer są już załatwione. Oczekuję tylko na dokończenie szaty graficznej i zakończenie sesji, by się za to wziąć.

Powrót

Na Zyxist.com panuje swoboda wyrażania opinii oraz krytyki pod dowolnym adresem. Jedyny warunek: musi być ona kulturalna i rzeczowa. Na chamstwo, prostactwo lub jawne obrażanie kogokolwiek nie ma tu miejsca i takie komentarze są bardzo szybko usuwane. Jeśli zamierzasz polemizować z treścią wpisu, wpierw uważnie ją przeczytaj.