Przyznam szczerze: nawet w swoich projektach, choć tryb zgodności z XML-em mam włączony, nie zawsze z niego korzystam i robię np. sekcje na klamerkach. Szybciej się to pisze, a zgodności kodu HTML po stronie serwera i tak nie sprawdzam, tak samo jak pliku szablonu w przeglądarce nie wyświetlam. W każdym razie powoli dochodzę do wniosku, że całkowita rezygnacja z klamerek byłaby dość głupim posunięciem. "N" osób by się wtedy do OPT przekonało, ale jest też "m" osób, które właśnie za obecność klamerek ten parser sobie cenią. Weźmy choćby eXtrema, który wprost mi powiedział, że mając włączone klamerki, od razu widzi, gdzie ma znaczniki systemu szablonów, a gdzie HTML (ach, to kolorowanie "Smarty" w edytorach :)), a ponadto sporo rzeczy znacznie łatwiej mu wykonać, gdy statyczna treść jest traktowana jak zwykły tekst. Co prawda jest sam sobie winny, że pisze takie zaśmiecone szablony, ale jednak ma sporo racji. Czy koniecznie trzeba palić doszczętnie dotychczasowe mosty tylko dlatego, że pełną zgodność z XML-em się wprowadza? XML jest standardem, ale przeznaczonym bardziej dla języków opisu. Rzecz zbliżona możliwościowo do języka programowania oparta o XML może być w wielu miejscach (i zazwyczaj jest) zwyczajnie niewygodna w użyciu. Przykładowo, osobiście gdybym miał korzystać z cudzego systemu szablonów, to w życiu nie wziąłbym czegoś, co nie oferuje alternatywnej składni dla takiego potworka:
tekst tekst <parse:put name="zmienna"/> tekst tekstNie jest to wyssany z palca przykład, na forum już dostałem propozycję, by iść za ciosem i umożliwić TYLKO taką formę osadzania danych w szablonie. Aby racjonalnie pracować z tego typu formami bez ataku nerwicy, edytor musiałby obsługiwać skróty klawiszowe do 10 schowków naraz (czyli zamiast Ctrl+C,Ctrl+V dać jeszcze 9 innych), by mieć pod ręką najczęściej używane elementy składni.
Oczekiwania ludzi co do systemu szablonów są niesamowicie różne i często ze sobą sprzeczne. Postawy, jakie daje się zauważyć, to:
- Programowanie po stronie szablonów is cool.
- W szablonie nie powinno w ogóle być programowania.
- Przenoszenie programowania do szablonów w jakiejkolwiek postaci jest złe.
- Programowanie w szablonach bywa czasami (i w pewnym ograniczonym zakresie) użyteczne.
- Programowanie w szablonach jest konieczne!
- Precz z pseudojęzykiem!
- Przenoszenie logiki do warstwy prezentacji to pomyłka, ale warstwy prezentacji do logiki już jest OK.
- Przenoszenie logiki do warstwy prezentacji jest OK, ale na odwrót to pomyłka.
- Przenoszenie czegokolwiek do czegokolwiek jest złe.
- Na #$%$% szablony! PHP wszystko zniesie!
- Na #$%#% szablony! DOM to jedyna słuszna droga.
- Składnia klamerkowa jest nieczytelna.
- Składnia klamerkowa jest czytelna.
- Składnia a'la XML jest prosta w użyciu i daje dużo swobody.
- Składnia a'la XML niekoniecznie jest prosta w użyciu, ale daje dużo swobody.
- Składnia a'la XML ani nie jest prosta w użyciu, ani nie daje swobody (czyt: używaj klamerek).
- Sprawdzanie poprawności kodu HTML to niezbędny atrybut poważnego systemu szablonów.
- Nie chcę systemu szablonów ze sprawdzaniem poprawności! Mam inny format szablonów, a tak w ogóle to niekoniecznie muszę pracować z XHTML-em!
Skoro ludzie sami do końca nie wiedzą, czym powinny być szablony, w jaki sposób im dogodzić? Na pewno zawsze ktoś będzie kręcił nosem, że nazwa nie ta, że zamiast klamerek mogłyby być hasze albo słowo "ASS". OPT 2.0 będzie bardziej próbą odpowiedzi na pytanie, czy kilkadziesiąt kilobajtów odpowiednio zorganizowanego kodu jest w stanie choć część zdawałoby się, że wykluczających racji, pogodzić. Ci, co koniecznie chcą XML-a i sprawdzania składni XHTML, dostaliby ją. Ci, co wolą mieć trochę więcej swobody i mają negatywny stosunek do czegokolwiek mającego związek z programowaniem opartego na XML-u, też by to dostali. Myślę, że to jest wykonalne, i to wykonalne w elegancki sposób. Kluczem jest złoty środek, a nie próba wskazania "jedynej słusznej" drogi, która w dodatku nie zawsze lub nie dla wszystkich jest słuszna, o popadaniu ze skrajności w skrajność czy wręcz fanatyźmie nie wspominając.















Napisał Bob w czwartek, 19 lipca 2007 o 17:26
Odnośnie przykładu z <parse:put name="zmienna"/> to wystarczy dowolny edytor xml uzupełniający składnię na podstawie dtd lub schemy. I wtedy już powinno być szybciej i od razu byłoby widać co można używać.