Forum PHP.pl

A co z wydajnością? Porównałeś to np. ze smarty? No i ciężko tak ocenić nie widząc w praktyce postawionej na tym strony. Poza tym wydaje mi się, że pójście w stronę pseudo-języka nie jest dobrym pomysłem, użytkownik (który dopiero co pobieżnie liznął smarty) dostaje kolejnego potworka do nauki. Ja np. idę w stronę maksymalnego upraszczania systemu szablonów - używam tylko {zmienna} i to w 90% wypadków wystarcza, można menu przedstawić tak:

1. Menu: <ul>{menu}</ul>
2. Element menu: <li><a href="{link}">{nazwa}</a></li> - ten sposób nawet kompletny laik łatwo pojmie, w końcu user chce edytować kod HTML, kwestia tylko odpowiedniego podzielenia kodu HTML, myślę, że to jest dla użytkownika prostsze niż:

[HTML] pobierz, plaintext 
<ul>  
    <ui:loop name="petla" select="$tab">  
        <li><ui:var select="@petla"/></li>  
    </ui:if>  
</ul>
[HTML] pobierz, plaintext 

No i czy warto tworzyć kolejny system szablonów, kiedy tyle ich już jest?

OPT ma podobny styl, jest PHPTAL. Nie widzę sensu chyba że będzie super szybkie.

Pilsener: wszystko jest szybsze i lżejsze od smarty

Ten post edytował viking 23.06.2009, 16:38:58

Moja ocena to nie jest, ale raczej uwaga

Znalazłem w pliku /parsed.cache w archiwum taką linijkę:


heh

Pozdrawiam, WebNuLL

Jaka składnia {} ?! O którym OPT ty mówisz, bo raczej nie o 2.0? A wersji 2.0 nie przyganiaj, bo sam masz w treści znaczników zapisy w stylu ${zmienna} .

Rzecz polega na tym, że jeśli temu zadaniu nie poświęcisz się przez dłuższy czas, to nie ma szans, by wynieść taki system szablonów na sensowny poziom. Sam XML Cię nie uratuje, bo jest to tylko pewien sposób zapisu i nic więcej - trzeba jeszcze mieć pomysł, jak go wykorzystać, tymczasem na razie w większości robisz to samo, co 90% innych systemów szablonów, czyli reimplementujesz PHP. Lista funkcjonalności:

- ui:var - wstawianie zmiennej. OPT też ma znacznik opt:put, ale klamerki zostawiłem w nim właśnie dlatego, że nie zabraniał tego standard XML-a oraz że do wstawienia zmiennej w tekście są po prostu wygodniejsze niż zapisy w stylu <ui:var select="$zmienna" /> i nawiasem mówiąc patrząc na podane przykłady, to Twój system też coś takiego ma. Silnika wyrażeń nie masz, więc nie możesz napisać np. $a+$b
- ui:if - identyczny IF, jaki można spotkać w każdym języku programowania, tylko z większą ilością ograniczeń. Parsowanie testowanego wyrażenia jest robione w bardzo prymitywny sposób, nie zapewnia żadnej ochrony przed błędami i na dłuższą metę nie daje się rozbudowywać.
- ui:loop - zwykła pętla, która nie wnosi nic ponad to, co oferuje np. foreach.
- ui:import - nie wnosi nic ponad to, co oferuje np. include w PHP.
- ui:define-component oraz ui:component - racja, funkcjonalność funkcji rzadko się w systemach szablonów spotyka, ale z tego co widzę, to ograniczyłeś się wyłącznie do powielenia tejże funkcjonalności.

Innymi słowy, robisz język szablonów z zerową świadomością, co możesz dzięki temu osiągnąć, a możesz przy odrobinie wysiłku usunąć mnóstwo ograniczeń PHP. Zamiast tego, piszesz kolejny pozdbiór PHP, tyle że dla odmiany ubrany w znaczniki zamiast w klamerki. Jest to najprostsze podejście, bo faktycznie - zamiana ui:loop na foreach zbyt wielkim wysiłkiem nie jest, ale co Ci ono daje? Przypuśćmy, że po wielu godzinach pracy uda Ci się w końcu zrobić prawdziwy parser wyrażeń tak, że będziesz mógł przepuszczać zmienne przez funkcje, liczyć i robić to wszystko, co potrafią wyrażenia PHP. Spróbujmy teraz zrobić listę zdjęć wyświetlaną w trzech kolumnach:



Ponieważ zastosowałeś XML, a Twoja pętla-klon jest zwykłym foreachem, musisz po stronie skryptu pamiętać, by podzielić to na odpowiednią ilość kolumn, uzależniając tym samym kod PHP i po części logikę aplikacji od szablonu. W Smartym mógłbyś to zrobić w całości po stronie szablonu, ale musiałbyś zaklepać cały algorytm dzielenia tego na kolumny. W OPT poświęciłem sporo czasu i obserwacji praktycznych problemów, by można było to zrobić dużo prościej:



Jak widzisz, pomyślałem i da się to zrobić w prosty, deklaratywny sposób, a OPT w tle dba, by to poprawnie skompilować. Opracowanie elastycznych mechanizmów i napisanie całego kodu kompilatora do tego elementu trochę czasu zajęło, a takich usprawnień są dziesiątki. Na dodatek sam parser to nie wszystko, bo system szablonów musi mieć API, przydałoby się, by istniały porty do frameworków itd. o infrastrukturze sieciowej i dokumentacji nie wspominając. OPT już to wszystko ma, ale dalej się rozwija i implementowana jest nowa funkcjonalność i miło byłoby gdyby zamiast tracić moc i pomysłowość na wymyślanie koła na nowo, pomóc w ulepszaniu tego, co już jest. System szablonów to nie tylko ify, pętle i klasa z assign() i display()...

PS. A nie odpisywałem wcześniej rozwlekle, bo się zbierałem do wyjścia. Mam nadzieję, że ta opinia jest już bardziej konstruktywna.

Ten post edytował Zyx 30.09.2009, 11:49:12