Witam serdecznie wszystkich,

Jakiś czas temu napisałem klasę obiektową gepard, która służy do tworzenia szablonów dla aplikacji php.
Dzieki niej, jest możliwe całkowie odseparowanie kodu źródłowego php od kodu HTML.

Jej cechy charakterystyczne to prostota, szybkość działania oraz minimalna ingerencja w kod html.

Jeśli ktoś ma ochotę, proszę zajrzeć na stronę:
www.gepard.w.pl

Bardzo mile widziane wszelkie uwagi, opienie, wrażenia.

Pozdrawiam serdecznie!

Odpowiedz na SMARTY - ROTFL Przeciez tam jest echo wiec jakie to oddzielenie ?

Witam,
jeśli chodzi o instrukcje echo - to jak zapewne zauważyłeś, użyłem ich w kodzie php tylko do wyświetlenia niezbędnych informacji, z całkowitym pominięciem kodu html.
Natomiast w kodzie html nie uświadczysz nigdy żadnych instrukcji php, tak jak to ma miejsce np.
w bibliotece SMARTY.

Użycie instrukcji echo to specyficzny przypadek, stosowany po słowie kluczowym $exit$.
Zresztą zastosowany tylko dla przykładu dla osób dopiero co uczących się.

Proszę, zobacz przykład tutaj (ostatni post).

W każdym bądź razie, dziękuję Ci za pierwszą opinię

skad wziales S.M.A.R.T.Y.?
popraw na SMARTY jak juz

nie zglebialem sie w kod, masz tam metode taka ktore nie wyswietli odrazu kodu HTML tylko bede mogl ja podstawic pod jakas zmienna?
w smarty fetch().

Gdzieś widziałem taki zapis i mi się po prostu utrwalił. Poprawiłem.


Nie, nie mam takiej funkcji.
Klasa Gepard jest tylko podstawowym zbiorem najważniejszych funkcji, dlatego jest taka szybka.
Nie widzę jednak przeszkód, by taką funkcję w przyszłości dodać do mojej klasy.

S.M.A.R.T. to raczej w hardwarze jest, a konkretniejest to technologia diagnozowania dyskow twardych.


a widzisz, czyli jak ja teraz bedziesz rozbudowywal bo duzo wiecej rzeczy bedzie potrzebnych to urosnie do takich samych rozmiarow jak Smarty i tak samo 'powoli' bedzie dzialac.

Nie do konca się zgadzam, czasem po prostu inny system zapisu moze byc szybciej parsowany...

Co do samej klasy Sam pisze w wolnym czasie podobną i dlatego w twojej nie podoba mi się:
- brak modyfikatorow ( ten sysem $exit$ jest debilny ;] )
- brak mozliwosci uzycia funkcji wewnatrz kodu html
- brat instrukcji warunkowych( czy moze byly?)
- tym samym brak tablic
- brak funkcji include

W każdym bąrdz razie nie wczytywałem się za dokladnie kod(jakos dziwnie to jest pisane). Proponuję zmianę filozofi co do wysyłania zmiennych do szablonu ;]

Smarty pozwala na trochę więcej rzeczy, niż tylko przypisanie jakiejś wartości do zmiennej w szablonie i zrobienie pętelki . Nie zgłębiałem się w to, ale na pierwszy rzut oka, ten system nie robi na mnie wrażenia.

ps. Zgadzam się z przedmówcą, że oznaczenie $cośtam$ jest nieco dziwne .

Jeżeli dodawałbym do niej wszystko co się rusza i na drzewo nie ucieka , to tak, stanie się ociążałą, pozbawioną sensu maszkarą. Moim celem, było całkowita eliminacja z kodu html znaczników php, takich jakie występują w smarty.
Wiem, ten sposób jak widać ma wielu przeciwników, ale mnie akurat bardzo ułatwia życie. Klasa ta posiada niewiele funkcji i tym samym jest bardzo łatwa do zapamiętania.

System jak system, jednym może się podobać innym nie, nie twierdzę że jest idealny.
Można go z łatwością zastąpić systemem {zmienna} lub {exit} - są gusta i guściki.
Funkcje występują w php - do wyboru do koloru - po co to mieszać z html'em?
Instrukcje warunkowe też są w php - do wyboru do koloru - po co to mieszać z html'em?
Tablice, hmm.. jeśli znalazłyby zastosowania, nie ma problemu ich stworzyć
Funkcja include jest w php.

Co jest w nim dziwnego? Formatowany z edytorze php 'KED'. A jeśli pętelki Ci nieodpowiadają, to już witki mi opadają. Co do zmiennych, to nie są one wysyłane do szablonu, lecz do klasy Gepard. W szablonie nie ma żadnych zmiennych, są tylko znaczniki $cośtam$ zamieniane w klasie Gepard na zmienne.

Ogólnie rzecz biorąc, moja klasa Gepard, nie będzie lepsza od SMARTY, nie będzie miała więcej pożytecznych funkcji - nigdy nie miałem takiego zamiaru pisząc ją. Miała być szybka, prosta i skuteczna. I tak właśnie jest.

A Wy zawsze musicie wszystko krytykować

Polską odpowiedzią na smarty jest zdecydowanie Open Power Template.

Co do pozytecznosci instrukcji warunkowych i funkcji. Weźmy pod uwagę to co tworzy grafik(i/lub osoba od htmla). Chce stworzyć layout który będzie mial zielony top, gdy użytkownik jest zalogowany, a niebieski gdy użytkownik jest niezalogowany(+ pole do logowania). Umieszczasz warunki w php i wszystko jest pięknie. Po tygodniu grafik zmienia zdanie, postanawia jednak zrobić tak aby top był zawsze niezmienny, niech zmienia się stopka. W następnym tygodniu odbije mu coś i wpadnie na coś jeszcze innego i bedzie chciał kolejnych zmian w php.

Po co używać funkcji? Znów dla wygody programisty php. Dajmy na to grafik będzie chciał datę w pełnym formacie. Jednak później zmieni wygląd i pełna data mu się nie będzie mieścić. Co robic? Znowu zawracać głowę programiscie?

W przypadku dobrego parsera, grafik ma odpowiednie konstrukcje dzięki którym może DOWOLNIE(no prawie - pewnych rzeczy nie da się z kosmosu wziąć) zmieniać wygląd i zachowanie pewnych elementów strony bez jakichkolwiek zmian w kodzie php.


Taka nasza rola

Rozbudowany system szablonów wcale nie musi być wolniejszy od minimalistycznego. Widziałem już wiele "małych" systemów, które nie wytrzymywały konkurencji ze "przeładowanym" Smarty'm . Zrobiłem także Gepardowi mały teścik porównawczy: prosta stronka wyświetlająca liczby od 0 do 99, testowana programem Apache Bench (n == 500). Wyniki średnie:

- Gepard: 100.21 rps
- OPT: 99.06 rps

Różnice wydajnościowe są minimalne, a OPT jest niewiele szybszy od Smarty, który w tym samym teście osiągnąłby wobec tego podobną szybkość. Zwróćmy uwagę na pewną rzecz: jeśli na stronie mamy sześć różnych list, musimy utworzyć przynajmniej siedem klas Gepard i siedmiokrotnie załadować jakieś pliki z szablonami. Okazuje się, że bardzo odbija się to na wydajności. Przerobiłem nieco test, aby ukazał tę sytuację. Każdy z systemów miał wyświetlić liczby od 0 do 99 sześciokrotnie. Ponieważ nie chciało mi się wymyślać cudów, wszystkie w zasadzie miały identyczny kod, tylko Gepardowi sześć razy z osobna tworzyłem obiekt klasy, aby zasymulować sytuację, że wszystkie listy są inne. Rezultat:

- Gepard: 24.89 rps
- OPT: 87.47 rps

Prawdopodobnie da się umieścić wszystkie wersje listy w jednym pliku i obsługiwać je jedną klasą, lecz dokumentacja Geparda jest nienajlepsza - nawet przykłady tam zawarte preferują wielokrotne ładowanie tego samego pliku do pamięci, stąd też użyłem właśnie takiego podejścia.

Poniżej prezentuję kod php użyty do testów - przy okazji zwróć uwagę na długość obu z nich .

1. Gepard:

[PHP] pobierz, plaintext 
<?php
 
require('./gepard/gepard_final.inc.php');
 
$strona = new Gepard('strona');
$strona -> CreateCode();
 
$lista = new Gepard('lista', 'lista');
 
for($i = 0; $i < 100; $i++)
{
	$lista -> AssignVar('item', $i);
	$lista -> CreateCode('repeat');
}
 
$lista = new Gepard('lista', 'lista');
 
for($i = 0; $i < 100; $i++)
{
	$lista -> AssignVar('item', $i);
	$lista -> CreateCode('repeat');
}
 
$lista = new Gepard('lista', 'lista');
 
for($i = 0; $i < 100; $i++)
{
	$lista -> AssignVar('item', $i);
	$lista -> CreateCode('repeat');
}
 
$lista = new Gepard('lista', 'lista');
 
for($i = 0; $i < 100; $i++)
{
	$lista -> AssignVar('item', $i);
	$lista -> CreateCode('repeat');
}
 
$lista = new Gepard('lista', 'lista');
 
for($i = 0; $i < 100; $i++)
{
	$lista -> AssignVar('item', $i);
	$lista -> CreateCode('repeat');
}
 
$lista = new Gepard('lista', 'lista');
 
for($i = 0; $i < 100; $i++)
{
	$lista -> AssignVar('item', $i);
	$lista -> CreateCode('repeat');
}
 
$strona -> CreateCode();
 
?>
[PHP] pobierz, plaintext 

2. OPT:

[PHP] pobierz, plaintext 
<?php
 
define('OPT_DIR', './opt/');
require(OPT_DIR.'opt.class.php');
 
	try
	{
		$tpl = new optClass;
		$tpl -> root = './templates/';
		$tpl -> compile = './templates_c/';
 
		$result = array();
		for($i = 0; $i < 100; $i++)
		{
			$result[] = array('item' => $i);
		}
		$tpl -> assign('lista', $result);
		$tpl -> parse('strona.tpl');
	}
	catch(optException $e)
	{
		optErrorHandler($e);
	}
?>
[PHP] pobierz, plaintext 

W OPT (oraz w Smarty'm) raz załadowanego zestawu danych mogę używać wielokrotnie w różnych miejscach, jeśli jest mi to potrzebne. W Gepardzie nie dość, że każde kolejne użycie musi być dodatkowo oprogramowywane w php, to jeszcze jest to porozrzucane dość nieładnie po kilku plikach. Przy większym projekcie zapewne bym się w tym pogubił.



Argument "im więcej opcji, tym jest to wolniejsze" jest mitem. Tak naprawdę wszystko zależy od wykorzystanego sposobu kompilacji szablonów. Gepard całą mechaniką zajmuje się samodzielnie, co w przypadku prostych rozwiązań może dawać spore zyski, ale dla bardziej zaawansowanych faktycznie skutkuje coraz poważniejszym spadkiem wydajności (iterpreter interpretuje interpreter interpretujący kod). Smarty oraz OPT są w zasadzie kompilatorami, które cały szablon przetwarzają do postaci czystego kodu php, który w kolejnych odsłonach jest zwyczajnie dołączany np. przez include(). Dlatego instrukcje warunkowe, pętle itd. działają tam z taką samą prędkością, jak w php, ponieważ tak naprawdę one są napisane bezpośrednio w php, a nie interpretowane przez napisany w php interpreter. Trochę zawile to opisałem, ale myślę, że sens da się zrozumieć . Oba systemy ładują podczas normalnej pracy jedynie fragment swego własnego kodu do pamięci. Kompilator oraz algorytmy przetwarzające znaczniki w szablonach na kod php wczytywane są tylko, gdy zachodzi potrzeba skompilowania czegoś. Dlatego w obu możesz mieć na dobrą sprawę nawet i tysiąc różnych instrukcji, ale podczas normalnego użytkowania nie odczujesz żadnego spadku wydajności z tego powodu, ponieważ kod ten będzie co najwyżej miejsce na dysku zajmował i nic ponadto.

--edit (sab) Poprawiłem bbcode listingów.

Witam serdecznie,
bardzo się cieszę, że moja klasa cieszy się taką popularnością.

A teraz do rzeczy,
z uwagi że moja klasa Gepard, nie posiada niestety danych typu "array",
powyżej przedstawiony dowód jest oczywisty do przewidzenia.

Skoro postawiliście mnie pod murem, mówi się trudno, będę musiał dopisać pare rzeczy do niej,
gdyż bardzo chciałbym sprawdzić jak pójdzie mojej Klasie, gdy takowa będzie miała wbudowane listy

Jestem pewien że równie dobrze lub nawet lepiej niż klasie Smarty.

Kilka uwag: a) nie trzeba tworzyć nowego obiektu Gepard, by móc wyświetlić dany element jeszcze raz,
wystarczy na nowo przypisac zmienne i kolejny raz wywołać funkcję CreateCode().

#Niestety moja dokumentacja nie jest kompletna, za co bardzo przepraszam#

w jednym pliku można umieścić kilka różnych elementów i wyświetlać je wielokrotnie - bez wielokrotnego przetwarzania tego samego kodu.

Postaram się w niedługim czasie, przedstawić odpowiedni kod.

Tymczasem pozdrawiam wszystkich bardzo serdecznie.