Obie te rzeczy mijają się dość mocno z prawdą - w OPT, jak ktoś ma zaśmiecony szablon przypominający groch z kapustą, to jest to wyłącznie jego wina, ponieważ system oferuje na wejściu wystarczająco dużo narzędzi, by tak nie robić, natomiast nawet w Smarty przy pewnym wysiłku ze strony programisty da się pisać dość czytelnie. Zaowocowało to mailem do autora z przykładami paru moich szablonów na OPT będących zaprzeczeniem tez w treści artykułu, jednocześnie przyznając się, że tryb kompatybilności z XML-em najlepszy nie jest, (w sumie ma nie być). Jako że o przekonanie Pornela do samego projektu nie chodziło w myśl zasady "każdy używa tego, co mu pasuje", nie powinna dziwić zatem odpowiedź, gdzie podał zalety oparcia systemu szablonów na XML-u i przyznał słuszność sprawie elegancji kodu.

Przytoczenie tej krótkiej, acz rzeczowej oraz interesującej dyskusji nie jest przypadkowe, ponieważ dała mi impuls do wyobrażenia sobie, jak mógłby OPT wyglądać, gdyby zamiast autorskiego, wyposażony był w rzeczywisty parser XML dający możliwość głębszej ingerencji w XHTML-owe znaczniki, a przy okazji dokładniej kontrolował składnię zarówno szablonu, jak i generowanego wyniku. Warto poprowadzić prace badawcze w tym kierunku, by przekonać się o możliwościach działania takiego systemu. Szkoda tylko, że dopiero gdzieś w drugiej połowie roku, gdy już uporam się z maturą i rekrutacją na studia. O pryncypiach XML-owego kompilatora za dużo napisać teraz nie mogę, jednak jeśli wyniki eksperymentów okażą się obiecujące, powstanie pełnowymiarowy kompilator i trafi on do OPT. Jestem jednak pewien, że wymusi to utratę wstecznej kompatybilności, stąd taki pakiet wypuszczony byłby już jako zupełnie nowa edycja, czyli Open Power Template 2.

OPT2 posiadałby podwójny kompilator, jako że stary jest zbyt dobry i użyteczny, by go się tak brutalnie pozbywać. Przeszedłby on jednak gruntowny lifting związany z uściśleniem składni i wyeliminowaniem niektórych niekonsekwencji, jakie zdążyły do tej pory narosnąć. Dualizm wymusi opracowanie nowej metody tworzenia instrukcji skonstruowanej tak, aby kod mógł współpracować z oboma kompilatorami jednocześnie. Programista nie byłby zmuszony do określenia się na samym początku: scu czy bescu, mogąc dynamicznie dobierać odpowiedni parser do swoich potrzeb.

Źródło inspiracji: już istniejące parsery XML-owe, oczywiście wzbogacone tym, co OPT już potrafi (ponadto, znając życie, uda mi się całą funkcjonalność w kilkunastu kilobajtach zmieścić :)). Czas realizacji: druga połowa 2007 roku, na pewno nie będę zabierać się za to przed wydaniem finalnej wersji Open Power Forms. Tak więc OPT nie mówi "nie" XML-owi i jest gotowy do ekspansji w tym kierunku, tyle że jako kolejna opcja, a nie zamiennik dla autorskiego parsera.

Powrót

• Artykuł Pornela

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.