Dec 01 2005
Parser szablonów
Filed under PHP by Łukasz Dywicki
Wczoraj, bądź przedwczoraj wpadłem na pomysł wykorzystania DOM XML i XSL przy tworzeniu szablonów. Zainspirował mnie PHP TAL (Template Attribute Language).
Z początku szablon miał być stylem XSL, jednak pomysł ten szybko odpadł ze względu na to, że uniemożliwia to tworzenie własnych komponentów, a przynajmniej ja nie wiem jak to zrobić. W tym układzie w pamięci przechowywany byłby obiekt DomDocument z odpowiednią struktórą – odwzorowaniem dodanych zmiennych.
Drugi pomysł wyklucza użycie XSL. Szablon jest parsowany DOM XMLem a następnie rekurencyjnie przeglądany. Na podstawie nazw tagów i zarejestrowanych na początku szablonu rozszeżeń parser tworzy odpowiednie obiekty odpowiadające za komponenty. Ogólnie idea tworzenia własnych rozszeżeń jest rodem z JSP.
Nie wiem co z tego wyjdzie i wogóle czy coś z tego będzie.. ;)
Jedno jest pewne – odpada problem z gromadą wyrażeń regularnych, pozbywam się kompilatora. Zostaje parser i być może cache. Sam jestem ciekaw czy to rozwiązanie będzie szybsze niż np. Smarty.
Poniżej bardzo abstrakcyjne przykłady.
<?xml version="1.0" ?> <x xmlns:i18n="http://template.splatch.pl/i18n" xmlns:pst="http://template.splatch.pl/pst" xmlns:attr="http://template.splatch.pl/attr" xmlns="http://template.splatch.pl/" > <i18n:message select="Hello"> <pst:test equals="true" assigned:variable="AssignedVar" assigned:value="OtherVar"> Test 1 </pst:test> <pst:test identical="true" assigned:variable="AssignedVar" value="TestVar"> Test 2 </pst:test> </x>
<?php
$tpl = new PST;
$i18 = ConfigParserFactory::get('i18n-test/pl.ini');
$tpl->setI18nDatasource($i18); // ConfigParser
$tpl->assign('AssignedVar',true);
$tpl->assign('OtherVar',false);
$tpl->display('test.xml');
?>
Moim zdaniem tracisz swój czas. Spróbuj spojrzeć na ten szablon okiem kogoś, kto zajmuje się grafiką i nie zna php. Zjarzy bezproblemowo? – Nie sądzę.
PHP to naprawdę dobry język szablonów ;) Dlaczego ciągle zawracacie sobie głowę pisaniem tego typu krów, które niczego nie ułatwiają? Nie przyczepiłbym się, gdybyś użył XSLT, bo to standard (i gotowe rozwiązanie). Kwestia sensowności jego zastosowania w php to już osobny temat ;)
Spojrzenie z perspektywy osoby nie znającej PHP na szablony zawsze jest problemem, niezależnie od tego jakiego parsera sie używa i od tego czy jest to przeplatany PHP czy nie. Dlaczego? Ponieważ wielu mało rozgarniętych grafików gubi się przy pierwszej pętli foreach.
PHP nie jest najlepszym językiem szablonów. Ciągłe wskakiwanie interpretera z kodu HTML do kodu PHP znacznie go zpowialnia.
PHP jako język szablonów jest też ciężko rozszeżalny – tzn. nie ma w nim żadnej dynamiki. Jeśli na przykład chcę dorzucić jakąś funkcję muszę ją zdefiniować i zadbać o to, by była wczytana.
XSLT fakt, jest dobre, ale z pewnością mniej czytelne niż normalny kod XML/HMTL. Procesor dostarcza odpowiednich funkcji, jednak żaden grafik nie będzie w stanie ich użyć, bo najnormalniej w świecie ich nie zna.
Co do czasu – jeśli ktoś się uczy, nigdy nie traci czasu. :)
To prawda, php nie jest najlepszym językiem szablonów. Dla grafików jest tak samo niezrozumiały, co Smarty, czy np. phpTal. Jednak większość systemów szablonów zazwyczaj i tak kompiluje swój kod do php, więc twoje stwierdzenie, że ciągłe wyskakiwanie z HTMLa spowalnia kod jest trochę dziwne.
Dla mnie pisanie czegoś takiego to utrudnianie sobie życia. PHP nie jest rozszerzalny? Nie żartuj. Nie sądzę, żeby nie dało się rozwiązać w nim jakiegokolwiek problemu z szablonami w miarę elegancki sposób.
Nie każdy tez potrafi sensownie używac php w szablonach. Tutaj bardzo łatwo o burdel, dlatego staram się nie unkać używania funkcji, czy klas, które nie są w ogóle związane z prezentacją.
Smarty i pochodne dlatego kompiluje szablon do PHP ponieważ odpalenie takiego szablonu jest szybsze niż jego ponowne parsowanie i szatkowanie regexpami. Co do wskakiwania – nie pamiętam dokładnie gdzie to czytałem, ale wiele osób może to potwierdzić…
PHP Savant nie kompiluje szablonu ponieważ piszesz "zkompilowany" szablon..
Proponuje poczekać na OPT light.
pozdrawiam
krowa >> OPT ma sprytny konfigurator dzięki któremu można z kodu pousuwać różniaste niepotrzebne nam elementy, przyspieszając go tym. Można usuwać: "Autoloading plugins support", "Custom resources", "Debug console", "disableCompileCache", "GZip compression support", "Output caching", "Component support", "Predefined components", "registerXXX() methods", "Objective I18n", "httpHeaders() methods" więc całkiem tego sporo można wyrzucić.