Witam!

Nie do końca rozumiem fascynację silnikiem Smarty. Tak naprawdę wykonuje za nas sporo pracy ale niewiele oszczędza, są spore różnice miedzy obiema technologiami XML+XSL vs Smarty. Ale wydaje mi się, no i tak wynika z mojej pracy, że jednak XML/XSL jest logiczniejszą technologia do wybrania. Jakie jest Wasze zdanie na ten temat?

Ciekawy artykuł, ale z wnioskami trudno mi się zgodzić.

Przecież Smarty (czy dowolny inny system oparty na szablonach HTML) nie implikuje generowania "ogromnych" plików HTML. Zapomniałeś o trzecim składniku (oprócz HTML i PHP), czyli szablonach stylów CSS.

W moich projektach, rzadko się zdarza, żeby wynikowy kod html niezbędny do wyświetlenia pojedynczej strony serwisu był większy niż kilkanaście kB. Cały layout (razem z grafikami, animacjami, itp.) jest zdefiniowany w zewnętrznym pliku CSS, który podobnie jak pliki XSL jest niezależnie od HTML cachowany przez przeglądarki.

Krótko mówiąc - stosując schemat XML + XSL masz oszczędności względem nieoptymalnie zaprojektowanych stron przy użyciu Smarty (PHP + HTML + CSS). Jeżeli serwis oparty na Smarty jest zaprojektowany optymalnie - przewaga znika. Ale pozostają wszystkie minusy XML + XSL które opisałeś w artykule.

Pozdrawiam wszystkich, ciekawy jestem co inni o tym sądzą.

Zgadzam się z nevt różnica pomiędzy przesyłanym XML a przesyłanym HTML nie powinna wg mnie być na tyle duża jak zaznaczyłeś to w artykule. Poza tym trzeba jeszcze wziąć pod uwagę, że przeglądarka musi to sparsować ,co również jest jakby nie patrzeć jakimś nakładem czasu (choć w zasadzie odchodzi czas na generowanie html ze SMARTY po stronie serwera)

Ja osobiście uważam, że cachowanie XSL i tak na wiele się nie zda. Aby efekt był taki jak pokazałeś layout strony musiałby być bardzo ujednolicony (co akurat nie jest tak trudno uzyskać) oraz strona musiałaby być bardzo często odwiedzana przez te same osoby (aby w końcu wykorzystać ten cache)

Wg mnie o wystarczające rezultaty jeśli chodzi o oszczędność łącza uzyskuje się poprzez cachowanie obrazków (części layoutu), css, js. Same przesyłanie już treści (html) to w zasadzie niewielka część użycia łącza, więc zamiast strzelać do muchy z armaty lepiej zastanowić się gdzie w jaki sposób lepiej łącze oszczędzać.

Pozdrawiam

Sposob jest w zasadzie glownym sposobem oszczedzania lacza w firmie w ktorej pracuje, przypada ok 1,2 mbita lacza wychodzadzacego na kazde 1k uzytkownikow. Nie sadze by taki wynik dalo sie przy rozbudowanym layoucie ( nie mowimy to w koncu o stronkach z odrobina cssa, i obrazkiem ) w lepszy sposob oszczedzac na laczu:) Zapytajcie kogos nasza-klasa jakie maja lacze to sie zdziwicie:) jak bardzo nieoptymalne potrafia byc rzeczy pisane przez 10 osob w porownianiu z tymi pisanymi przez jedna, dwie
Pozdrawiam

Czy ten sposób prezentacji danych jest logiczniejszy do wybrania ? Moim zdaniem nie. Pierwszy powód już podałeś w arcie - nie radzenie sobie z transformacjami xslt przez przeglądarki i właściwie tutaj można temat skończyć, bo jak wytłumaczę klientowi że "super technologia, nowoczesna, ale strona źle się wyświetla"
Druga sprawa to sam xslt, raz że trzeba się nauczyć składni, co proste nie jest, dwa że wyświetlenie bardziej złożonych struktur jest katorgą.
Podsumowując, technologia jest ciekawa, być może w przyszłości coś z tego będzie, ale obecnie się nie sprawdzi, smarty jest łatwiejsze do nauczenia, co przekłada się na czas tworzenia projektu i oczywiście koszt.

Jesli chodzi o koszt, to zaleznie od wielkosci serwisu rosnie tez oszczednosc, jesli tlumaczysz wiec klientowi ze go to bedzie wiecej kosztowalo na poczatek bo poprostu nie znasz tej technologii, a nie mowisz ze jest w stanie kilka tys pln rocznie ( u mnie kilkadziesiat miesiecznie ) zaoszczedzic na laczu to cos jest nie tak:) Skladnia nie jest taka trudna do opanowania i stosukowo podobny koncept co smarty, a przy odpowiednim doswiadczeniu budowanie zlozonych struktur nie jest wcale trudne, wszystko robisz szablonami:) W efekcie koncowym koszt przejscia na inna technologie (czas posiecony na nauczenie sie, wdrozenie, testowanie, rozwiazania dodatkowe) jest znacznie mniejszy niz koszt utrymania lacza. Cala dyskusja rozbija sie o to ze znajac smarty i piszcz strone domowa jana kowalskiego, warto nauczyc sie xsla dla siebie, a nie warto wdrazac dla oszczednosci przy 10 UU miesiecznie. Jesli natoiast UU jest kilka milionow, lub tez chcemy pracowac kiedys nad czyms innym niz robieniem stronek na zamowienie to naprawde polecam:)

Pozdrawiam

Ja akurat bardzo chętnie stosuję XSL, ale po stronie serwera. Kod wynikowy HTML wysyłam do przeglądarki. Nie pozwalam aby przeglądarki same to parsowały.

Wiem, że w zasadzie zastosowanie takie niewiele rózni się od użycia SMARTY, ale w porównianiu z tą technologią ma to jedną zaletę: można w zależności od klienta generować indywidualne layouty tego samego systemu. Mało tego, każdy layout może być tworzony przez grafików klienta (nawet można XSL includować poprzez formatkę w platformie). W zasadzie sprowadza się to do tego, że takie layouty mają dokładnie (a w zasadzie "prawie") takie same zastosowanie jak CSS.

A dlaczego nie ładować gotowych szablonów SMARTY? Odpowiedź jest prosta: bezpieczeństwo. Wystarczy, że zwaliduję XSL i już mogę layoutu używać. W SMARTY jest to o wiele bardziej skomplikowane (choćby na przykład przez tag {php}).

Argument, że stosowanie XSL jest lepsze ze względów oszczędnościowych (łącza) nie przemawia do mnie.

Pozdrawiam

Jestem klientem, tylko trochę bardziej myślącym, niż inni. Żądam, by strona działała na wszystkich przeglądarkach. Temat użycia XSLT po stronie przeglądarki jest więc zamknięty i nie wiem, po co ta cała dyskusja. Technologia zaiste, ciekawa, ale kompatybilność przeglądarek skreśla ją już na wstępie.

Ponadto szablony XSLT też swoje ważą. Taki DocBook XSL Stylesheet służący przede wszystkim do formatowania tekstu pisanego i nic poza tym sam w sobie waży kilka megabajtów, a na stronie musisz też uwzględnić szereg innych rzeczy, jak choćby formularze. Czy potrafisz mi zagwarantować, że ilość powracających użytkowników lub przeglądających ją odpowiednio długo jest na tyle duża, by mały rozmiar plików XML zrekompensował pobieranie dla każdego z nich kilkumegabajtowej kobyły? Czy zafundujesz dodatkowo kawę MOIM klientom czekającym, aż im się to wszystko łaskawie ściągnie?

Pliki XML po stronie serwera też trzeba generować - będziesz to mieszać wszystko z kodem PHP, tworząc okropny syf czy użyjesz, tadam, systemu szablonów, nawet używającego czystego PHP, niekoniecznie Smarty, by to wykonać? Ponadto system szablonów w PHP może bezpośrednio komunikować się ze skryptem i pobrać pewne informacje na żądanie. Przykładowo, w stylu graficznym dla jednego klienta w danym miejscu wyświetlany jest jeden zbiór informacji, w drugim on się w ogóle nie pokazuje. Inteligentnemu systemowi szablonów możesz zamiast danych wrzucić callback do funkcji generującej dane i jeśli będą one potrzebne, zostaną one załadowane automatycznie w tle.

Widze ze kolega nieco myli pojecia:) Szablon XSL wazacy kilka mega jest reczywiscie arcydzielem malo sprawnego programisty. Jesli klienta przekonamy ze najwiecej jego uzytkownikow wchodzi na strone z Opery ( ok. 7% polskiego internetu) lub ie 5.5 ( mniej niz 0.1% ). A do tego na strona ma 1000UU to rzeczywiscie nie ma sensu:) Jesli mamy odslony w milionach/miliardach miesiecznie - ma Jasli ktos nie ma kalkulatorka, pomoge obliczyc, zeby rozwiac watpliwosci A komunikowanie w tle moze byc i zazwyczaj jest AJAX, ktory ma z tematem malo wspolnego raczej:)

"będziesz to mieszać wszystko z kodem PHP, tworząc okropny syf czy użyjesz, tadam, systemu szablonów, nawet używającego czystego PHP"

A XSL to niby czym jest jak nie systemem szablonow? A jak kolega zamierza do SMARTY czy innego systemu wlozyc dane inaczej ?

Pozdrawiam
teu

A bierzesz pod uwagę, ile odsłon jest generowanych przez jednego użytkownika? Dla mojej strony WWW Twój przelicznik nie sprawdza się ani trochę. Niech stronę odwiedzi:

- 43 osoby, które dały 1 odsłonę.
- 27 osób, które dały dwie
- 15 osób, które dały 3
- 8, które dały 4
- 7, które dały 5

Daje Ci to 209 odsłon, czyli wskaźnik bardzo podobny do tego, jaki mam u siebie (2,04). Teraz czary:
- Wersja z XSL po stronie przeglądarki: każdy ze 100 gości pobiera 50-kilobajtowy arkusz transformacji (oparte na wielkości napisanego przeze mnie onegdaj renderera tekstów lingwistycznych), do tego średnio z jednej strony otrzymuje 500 bajtów danych. Transfer: 5100 KB
- Wersja z XHTML-em: każda z 209 odsłon waży średnio 8 KB. Transfer: 1672 KB.

Jak się chcesz w ogóle powoływać na jakąkolwiek matematykę, zacznij od przedstawienia obliczeń, a nie rzucasz paroma wziętymi nie wiadomo skąd hasełkami, które nie uwzględniają nawet tak elementarnych rzeczy, jak ilość odsłon generowana przez jednego użytkownika, że o stosunku objętości danych do szaty graficznej nie wspominając. I dopóki nie przedstawisz takiego modelu, który jasno rozstrzygnie, dla jakich kategorii witryn faktycznie możemy osiągnąć zysk, ja uważam tę dyskusję za zakończoną. Ponadto tak się składa, że jestem użytkownikiem Opery i masz już u mnie drugiego minusa za tego typu argumentację. Gdyby Twój kalkulatorek był nie do końca sprawny, to Ci przeliczę, że jeśli serwis ma milion odwiedzin i skierowany jest do każdego Polaka, to statystycznie 7% tych odsłon będzie z Opery. 7% * 1 000 000 = 70 000 strat. Faktycznie, oszczędność transferu to jest, ale pociąga ona też za sobą tysiące użytkowników, którzy mogą nie tylko nigdy więcej na stronę nie powrócić, ale i narobić klientowi obory, że taki szajs wypuścił. A co zrobisz, jeśli Opery będzie używał klient albo klienci klienta?

PS. Zanim zaczniesz cytować, o komentowaniu takich cytatów nie wspominając, najpierw naucz się to robić poprawnie.

Jesli twoja strona ma tak duzy wskaznik odrzucen, ze wiekszosc userow wejdzie raz, moze dwa, to znaczy ze albo jest w takiej tematyce, alebo jest po prostu kiepsciutka:) Tak czy siak faktycznie nie ma sensu uczyc sie podobno trudnej do zrozumienia technologii

Pozdrawiam
PJ

XSL+XML jest technologią przyszłości. Nie każmy jej używac do robienia smiesznych stronek z 200 UU. To tak jakby dac murzynom w afryce nowoczesny sprzęt.

Poza tym wydaje mi się że dyskusja na temat minusów xsl-xml jest bezsensowana, skoro takie firmy jak blizzard wzieły się już ostro za tą technologię. np http://www.starcraft2.com/

Jeżeli ktoś pracuje w 5-cio osobowej firmie i składa całe życie stronki na które wchodzi po klika userów to w jego przypadku nie ma sensu nic zmieniac. Nie potrzebnie będzie się męczył z tak skomplikowaną technologią .

Teutates za bardzo ambitnie podszedłeś do omawiania problemu

Zyx to że xsl-xml nie składa się dobrze w niektórych przeglądarkach nie oznacza że nie można dla nich parsowac xsl-a po stronie serwera, przez co poprawny kod strony ma 100% użytkowników.


Podsumowując XSL-XML albo stosujemy ze względy na wygodę albo dla portali "potworów" .

Mi do gustu przypadł TAL z Zope. Jest czymś pomiędzy zwykłym szablonem a xslt - łączy wady obydwu podejść - ale zdecydowanie wolę go niż IMHO niezbyt przyjazną składnie xslt - a przynajmniej mi osobiście zawsze sprawiało problemy domyślenie się jak zrobić niektóre rzeczy za pomocą/w stylu(w dosłownym znaczenie, a nie pliku) xslt. TAL także wygląda przyjaźnie w każdym edytorze xhtmla, a podobno nawet istnieją jakieś narzędzie przerabiające xml szablony TALa na xslt, choć domyślam się, że to co generuje automat wygląda koszmarnie.
Tak z palca ( banalne i nieco przerysowane )
Smarty:

[HTML] pobierz, plaintext 
<table>
	{foreach from=table item=row}
		<tr>
		{foreach from=row item=cell}
			<td>{$cell}</td>
		{/foreach}
	</tr>
	{/foreach}
</table>
[HTML] pobierz, plaintext 

(PHP)TAL:

[HTML] pobierz, plaintext 
<table>
	<tr tal:repeat="row table">
		<td tal:repeat="cell row" tal:content="cell" />
	</tr>
</table>
[HTML] pobierz, plaintext 

XHTML to też poprawny plik XML tyle, że często z uwagi na layout jest inaczej zorganizowany, zawiera często kilka zbędnych tagów i rzadko odzwierciedla logiczną strukturę danych jak to teoretycznie w przypadku XML-i powinno być. Idea XLST mi się podoba z uwagi zawłaszcza na wyżej wspomniany porządek w danych. Pomijając argumenty dotyczące oszczędności łączy - bo jest to nieco wątpliwe - wyobraźcie sobie zalety przesyłania danych użytkownikowi w dobrze zhierarchizowanym XML-u. Dostępność, przenośność, możliwość eksportu do innych formatów. Teraz męczymy się z mającym wiele do życzenia CSS-em, który tylko teoretycznie umożliwia dowolną stylizajcę danych, a w rzeczywistości wymaga odpowiedniego spreparowania dokumentu (kolejność danych, nadmiarowość tagów itd.). Rozbieżności w interpretacji są problemem tak jak były (są) w przypadku JS i CSS. XLST nie jest prostą technologią i osobiście jeszcze nie odważę się jej stosować w swoich projektach, ale jestem gorącym orędownikiem tego typu rozwiązań.

zważywszy na fakt ze xhtml jest poprawnym xml-em to może zbudować system szablonów opartych o DOM?
Ja właśnie próbuje moich sił w tejże dziedzinie, jednak dla mnie problemy zaczynają się z zagnieżdżonymi pętlami. Dokument wygląda np tak:

[HTML] pobierz, plaintext 
<?xml version="1.0" encoding="utf-8"?>
<html xmlns:tpl="http://www.cos.pl">
<head>
<title>
    <tpl:value-of select="$tab.tytul"/>
</title>
</head>
<body>
<ul>
<tpl:for-each name="@tt" select="$tab">
    <li><tpl:value-of select="@tt"/></li>
</tpl:for-each>
</ul>
</body>
</html>
[HTML] pobierz, plaintext 

php:

[PHP] pobierz, plaintext 
<?php
$tpl = new Template("plik.tpl");
$tab = array("title"=>"coś","dwa"=>2,"trzy"=>3);
$tpl->apply();
?>
[PHP] pobierz, plaintext 

wynik:

[HTML] pobierz, plaintext 
<?xml version="1.0" encoding="utf-8"?>
<html xmlns:tpl="http://www.cos.pl">
<head>
<title>
    coś
</title>
</head>
<body>
<ul>
    <li>coś</li>
   <li>2</li>
   <li>3</li>
</ul>
</body>
</html>
[HTML] pobierz, plaintext