zamieściłem nową wersję opartą o wyrażenia, lepiej działającą, drobna dokumentacja i paczka do ściągnięcia tutaj Proszę o komentarze...



Buuu... żadnych komentarzy, szkoda...

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?

Chciałem spytać o to samo...

Co do tego że istnieje wiele języków szablonów- fakt istnieje i większość z nich wygląda jak smarty {$zmienna} co wygląda dziwnie, jeżeli ktoś choć minimalnie liznął xsl to moje szablony są bardzo zbliżone...
Dodatkowym atutem ma być właśnie rozszerzalność nad którą pracuję tj. tworzenie ala' komponentów, np:

[XML] pobierz, plaintext 
<ui:define-component name="button">
<ui:param name="url"/>
<ui:param name="color">
<ui:body>
    <a href="$url"><div class="button" style="color:$color"><img src="somebutton.png" alt="some buton"/></div></a>
</ui:body>
</ui:define-component>
[XML] pobierz, plaintext 

I później zamiast ciągle powtarzać kod
<a href="$url"><div class="button" style="color:$color"><img src="somebutton.png" alt="some buton"/></div></a>
wpisujemy:

[XML] pobierz, plaintext 
<ui:use-button url="www.wp.pl" color="red"/>
[XML] pobierz, plaintext 

Co do testów dziś się przymierzam, zaraz po obiedzie wykonam i podeślę jak to wygląda

No i elementy typu {literal} normalnie denerwują człowieka

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

Pilsener: wszystko jest szybsze i lżejsze od smarty

o popatrz OPT się nie interesowałem dzięki, zaraz przejrzę

Moja ocena to nie jest, ale raczej uwaga

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


heh

Pozdrawiam, WebNuLL

Kurcze, ups ;P dzięki zaraz usunę

Przepraszam za reaktywację ale nie ma sensu tworzyć nowego tematu przecież:

Mój system szablonów nowa wersja- kandydująca:)

Opis tutaj: http://www.w3labs.pl/php/system-szablonow-ui-10rc.html
przykład na serwerze tu: http://frea.w3labs.pl/
szablon tu: http://frea.w3labs.pl/app/test/tpl.php
Paczka do pobrania z przykładem tu: http://www.w3labs.pl/wp-content/uploads/20...ea-template.zip

Bardzo proszę o opinie!

Zrobiłem dodatkowo porównanie funkcji żeby zachęcić do sprawdzenia (ui- moj szablon vs najnowsze smarty)
Nie testowałem komponentów bo nie było do czego porównać, tak samo z drugiej strony nie testowałem niektórych rzeczy bo mój projekt
jest dość młody i jeszcze nie wszystko jest zaimplementowane.
Jak widać na pętlach trochę traci będę musiał nad tym popracować

Nie lepiej zamiast tego pomóc rozwijać OPT, który ma już od dawna praktycznie wszystkie te rzeczy + jeszcze trochę, tyle że dużo elastyczniej zaprojektowane i lepiej przetestowane?

A co ja mogę tam pomóc?...
Liczyłem na jakiś konstruktywny komenarz typu:
"Twoj parser jest do dupy w nie lepiej użyć np .... rozwiązania..." albo
"Ja bym przestrzeń nazw inaczej zorbił: ..."

Mimo wszystko dzięki za odzew chociażby

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.

Teraz się czuję mile skrytykowany
Z tymże moja pętelka to nie jest podmiana na foreach tylko na while i nie do końca sama podmiana bo jest klasa która odpowiada za przesuwanie wskaźnika w tablicy i zajmuje się rejestrowaniem pętli i innych zmiennych.
Z tym że mam bazową funkcjonalność jak pętelki, marne ify itd... zgodzę się no bo przecież nie od razu rzym zbudowano, a trzeba postawić jeden kamień aby móc na nim położyć drugi itd...

Nie wiedziałem że popełniłeś OPT- chylę czoła, ale podejrzewam że nie miało całej funkcjonalności na dzień dobry.

A klamerki wyszły bo sprawdzałem chyba nawet i na Twoim blogu wprowadzenie do opt i jak zobaczyłem klamrę to pierwsze o czym pomyślałem to smarty (z góry przepraszam)

co do define component- nie spotkałem się z tym jeszcze nigdzie myślałem że tego nie ma :/ ale lipa...

OPT i używam i polecam

ps. szkoda, że nie ma portu dla Kohany, wtedy uczyłbym się dwóch za jednym razem

Pozdro

@fly474
dzięki za krytykę

fly474 -> jest port dla Kohany, tylko że zrobiony przez kogo innego: http://wiki.invenzzia.org/wiki/OPT_for_Kohana_Framework

deirathe -> wersja 1.x i owszem, nie miała, ale 2.0 była od początku pisana z myślą o byciu czymś więcej, niż tylko zwykłym PHP oprawionym w XML.