W 5.0.3 są jakies problemy z Domem ;]

Ide zrobić update

Ok, z tego do czego doszedłem w nocy wychodi, że można stosować kodowanie "rodzime" po paru przeróbkach... W każdym razie będzie jako tako wyświetlać. Kod dam póxniej. Hymm, a moze wprowadzić obowiązek zapisywania dokumentów językowych w utf-8 i koniec? chodzi o późniejszą funkcjonalność

Po pierwsze się nie da

Po drugie jest iconv ;]

Jest, ale częstsze użycie do każdej zmiennej językowej (czy czegokolwiek innego zawierającego tekst w danym języku) zmniejsza wydajność...
Więc trzeba wymyślić metodę wstawiania dowolnych treści w różnych kodowaniach... Z tego chba parser templatów przypadkiem powstanie
EEE, większa wydajność Nowak (nie moglem się powstrzymać od OT)

EDIT i EDIT2
Można zrobić kontroler, który sprawdzałby kodowanie danego tekstu i w razie potrzeby konwertowł go iconv();
Przykładowa funkcja:

[PHP] pobierz, plaintext 
<?php
 
//Tablica językowa (może byc inne źródło) zawiera kodowanie dokumentu
//Gdy nie zgadza się z uniwersalnym (leniwi tłumacze) odpalamy
//konwerter i z głowy, a jak standart wejdzie powszechnie, wtedy odłączymy funkcje
konwertera
$_LANG = array( 
	'encoding' => 'iso-8859-2',
	'a' => 'To jest tytuł tej strony',
	'b' => 'To jest nowy naglowek strony Jestem wesoły romek i mam żółwia.',
	'c' => 'To jest nowa zawartosc sciema Powstaje w języku PHP5',
);
//wycięte z klasy
function prepareEncoding( $sEncoding, $sString ) {
	if( $sEncoding != self::$_CONFIG['encoding'] ) {
	return iconv( $sEncoding, self::$_CONFIG['encoding'], $sString );
	}
	else {
		return $sString;
	}
 
?>
[PHP] pobierz, plaintext 

Dzięki temu umożliwiamy leniwym tłumaczom pisanie w ojczystym języku bez konwersji, ale kosztem wydajności...
Trochę zboczone z tematu ideii, ale przyda się kiedyś

EDIT3
Pomęczyłem się (może i na darmo) ale sekcje to nie problem (zobaczymy jak z wydajnością), problemy sa tylko z includowaniem...

Sekcje były by najpierw tworzone, potem poprzez DOMXPath znajdowano by stary wpis i zamieniano na nowy, np:

Byłaby metoda assignSection( $sID, $aValues, $sOpenTag, $sCloseTag );
Do tabel byłaby specjalna funkcja.
Nad includowaniem jeszcze popracuję...
I jeszcze zmiana atrybutów (np widoczy/niewidoczny) + oprawa w klasach i prosty i zasobożerny template gotów.

Ja właśnie pracuję nad własnym systemem szablonów.
Na razie myślę nad czymś takim:
Tak wygląda mój artykuł:

[XML] pobierz, plaintext 
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xml" href="article.xsl"?>
<!DOCTYPE article SYSTEM "article.dtd">
<article>
    <title>Mój artykuł</title>
    <date>22.04.2005 18:30</date>
    <author>Mateusz 'matid' Drożdżyński</author>
    <content>
        <intro>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec non purus vel metus pretium consequat. Aliquam arcu. Cras elementum sagittis nulla. Integer ac erat. Phasellus elementum, mauris quis adipiscing sollicitudin, arcu ligula tempor libero, ut convallis purus wisi sed wisi. Integer sed massa. Cras eu sapien non tortor pellentesque facilisis. Suspendisse potenti. Nunc nulla quam, accumsan eu, consequat eu, adipiscing vel, lorem. Integer molestie erat ut erat. Curabitur consequat. Aliquam ullamcorper pulvinar lectus. Donec ac lorem ut purus dictum venenatis.</intro>
        <chapter>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec non purus vel metus pretium consequat. Aliquam arcu. Cras elementum sagittis nulla. Integer ac erat. Phasellus elementum, mauris quis adipiscing sollicitudin, arcu ligula tempor libero, ut convallis purus wisi sed wisi. Integer sed massa. Cras eu sapien non tortor pellentesque facilisis. Suspendisse potenti. Nunc nulla quam, accumsan eu, consequat eu, adipiscing vel, lorem. Integer molestie erat ut erat. Curabitur consequat. Aliquam ullamcorper pulvinar lectus. Donec ac lorem ut purus dictum venenatis. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec non purus vel metus pretium consequat. Aliquam arcu. Cras elementum sagittis nulla. Integer ac erat. Phasellus elementum, mauris quis adipiscing sollicitudin, arcu ligula tempor libero, ut convallis purus wisi sed wisi. Integer sed massa. Cras eu sapien non tortor pellentesque facilisis. Suspendisse potenti. Nunc nulla quam, accumsan eu, consequat eu, adipiscing vel, lorem. Integer molestie erat ut erat. Curabitur consequat. Aliquam ullamcorper pulvinar lectus. Donec ac lorem ut purus dictum venenatis.</chapter>
    </content>
</article>
[XML] pobierz, plaintext 

Do tego plik .dtd:

[XML] pobierz, plaintext 
<!ELEMENT article (title, date, author+,content)>
<!ELEMENT content (intro, chapter+)>
 
<!ELEMENT title (#PCDATA)>
<!ELEMENT date (#PCDATA)>
<!ELEMENT author (#PCDATA)>
<!ELEMENT intro (#PCDATA)>
<!ELEMENT chapter (#PCDATA)>
[XML] pobierz, plaintext 

oraz plik XSLT, czyli całe w waszym wypadku plik szablonu:

[XML] pobierz, plaintext 
<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
      <xsl:output method="html" encoding="UTF-8" doctype-public="-//W3C//DTD XHTML 1.1//EN" doctype-system="http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" />
    <xsl:template match="article">
        <html>
            <head>
                <title><xsl:value-of select="title" /></title>
                <link rel="stylesheet" type="text/css" href="article.css" />
            </head>
            <body xml:lang="pl">
                <h1><xsl:value-of select="title" /></h1>
                <div id="subheader">
                    [<xsl:value-of select="date" />]<xsl:text> - </xsl:text>
                    <xsl:for-each select="author">
                          <xsl:value-of select="." /><xsl:text>; </xsl:text>
                    </xsl:for-each>
                </div>
                <xsl:apply-templates select="content" />
            </body>
        </html>
    </xsl:template>
    <xsl:template match="content">
        <p id="intro"><xsl:value-of select="intro" /></p>
        <xsl:apply-templates select="chapter" />
    </xsl:template>
    <xsl:template match="chapter">
        <p><xsl:value-of select="."/></p>
    </xsl:template>
</xsl:stylesheet>
[XML] pobierz, plaintext 

Do tego trochę kodu php:

[PHP] pobierz, plaintext 
<?php
 
	$iStart = microtime( true );
 
	$bCache = true;
	$bDebug = false;
 
	$sDocument = 'article.xml';
	$sXSLT = 'article.xsl';
 
	if( file_exists( $sDocument ) && file_exists( $sXSLT) )
	{
		if( $bCache == true &&  file_exists( 'cache/' . md5( $sDocument . '.' . $sXSLT . '.' . @filemtime( $sDocument ) . '.' . @filemtime( $sXSLT ) ) ) )
		{
			echo file_get_contents( 'cache/' . md5( $sDocument . '.' . $sXSLT . '.' . filemtime( $sDocument ) . '.' . filemtime( $sXSLT ) ) );	
		}
		else
		{
			try
			{
				$XMLDocument = new DOMDocument;
				$XMLDocument->Load( $sDocument );
				if ( @$XMLDocument->validate() === false )
				{
					throw new Exception( 'Document does not follow the DTD.' );
				}
				$XSLDocument = new DOMDocument;
				$XSLDocument->load( $sXSLT );
				$XSLProcessor = new XSLTProcessor;
				$XSLProcessor->importStyleSheet( $XSLDocument );
				$XHTMLDocument = $XSLProcessor->transformToDoc( $XMLDocument );
				echo $XHTMLDocument->saveXML();
				if( $bCache == true )
				{
					file_put_contents( 'cache/' . md5( $sDocument . '.' . $sXSLT . '.' . filemtime( $sDocument ) . '.' . filemtime( $sXSLT ) ), $XHTMLDocument->saveXML() );	
				}
			}
			catch ( Exception $e )
			{
				if( $bDebug === true )
				{
					echo 'Exception caught: ' . $e->getMessage();
				}	
			}	
		}
	}	
 
	$iTime = microtime( true ) - $iStart;
	if( $bDebug === true )
	{
		echo '<hr />Generation time: ' . $iTime . ' s';	
	}
 
?>
[PHP] pobierz, plaintext 

I mamy bardzo fajne wyświetlanie dokumentów z cachem. Myślę, że takie coś, oczywiście przerobione na klasę jest bardzo ciekawym rozwiązaniem. Transformacje to idealne szablony, w dodatku zgodne z wytycznymi W3C. Zastanawiam się tylko teraz, jak rozwiązać modułowość takiego szablonu, czyli mamy np. jeden szablon główny, a w jakieś jego pole ładujemy wyniki działania całego skryptu.
Jakieś pomysły?

Całkiem nie głupie rozwiązanie... Gdzieś widziałem coś podobnego (ez ?), ze aby dodać artykuł wystarczy go napisać i wrzucić na serwer w pliku xml, a mechanizm sam go wyświetli, żadnego bawienia sie w formularze etc.

Dla treści takie rozwiązanie jest bardzo dobre. Ale xsl do samych szablonów to już jest raczej przesada.

Tja... Dla niektorych bawienie sie formularzami jest latwiejsze niz wrzucenie czagos na serwer

A co do xsl+xml+php - to to jest troche jakby uzywac choinki do wieszania bombek na innei chince, if you get my point...

A mógłbyś rozwinąć swoją nad podziw głęboką myśl

Uwaga! Rozwijam!

Więc zastanówmy się czym jest php? php jest sam w sobie językiem templatowym. Z biegiem czasu, rozwinął się tak, że można w nim dokonać żeczy znacznie bardziej zaawansowane - to fakt. XSL i XML są bardzo dobrymi technologiami samymi w sobie - XML na przykład jest genialny gdy przychodzi do transportu informacji lub wywolywania metod na innych serwerach, vide RSS i RPC. Transformacje XSL też są świetnym narzędziem - ale bardzo zaawansowanym narzędziem.

Rozwijając moją myśl, php to język templatów, XSL służy do tego samego... Nazwijcie mnie purystą, ale nie widzę czemu utrudniać sobie życie X'ami, które dokonają tego samego co czyste php.

Zresztą ostatnio z biegiem czasu przeżucam się na myślenie że php jest lepsze od jakiegokolwiek systemu szbalonów - przynajmniej przy frameworkach

Hymm..., tak używanie XSL (szablonów) do tworzenia szablonów raczej odpada. Generowanie przez php XML z wynikami działań, które należy wstawić do skryptu też jest za wolne. Tak więc zostaje ładowanie do DOM dokumentu HTML i obróbka.

Raczej były templatami, jeśli można tak to nazwać, a co teraz mamy to zgodność wstecz, to że php zostało stworzone jak narzędzie, zagnieżdżone w HTMLu, nie oznacza, iż dalej ma musi być w ten sposób wykorzystywane.


Sztuka dla sztuki ?


To chyba dobrze, że coś jest zaawansowane, nie? Dzięki temu możemy korzystać z narzędzia a nie szukać metod rozwiązywania błahych problemów.


To że php może robić to samo co XSLT, nie oznacza że robi to równie dobrze
Po za tym, jak chcesz prezentować zagnieżdżoną strukturę danych ( drzewo XML ) poprzez zserializowanie wielowymiarowej tablicy? Czytelność czegoś takiego jest zerowa, XMLa sam wiesz

W skład XSL wchodzi, oprócz XSLTa, XSL-FO, dzięki któremu można łatwo generować PDF i inne formaty, a przy php ?


Czemu ? To świetne, potężne rozwiązanie


A cache to pies ?:]

Ale się rozpisałem :]

@Bela -> ok, może i dobre rozwiązanie, ale:

• Cache nie pies - ale {dynamic} ?
• Czasy i tak będą o wiele niższe niż np w OPT lub Smarty - użytkownicy wybiorą szybsze rozwiązania i nie będą patrzeć na ich zaawansowanie
• Dla zwykłego usera jest wszystko jedno jak działa, ważne aby działało
• Jak rozwiążesz wstawianie wyników pracy php (tak jak pisał @Chmolu?)
• Skomplikowana struktóra, bo trzeba będzie .dtd i XSL tworzyć - nie kazdy musi to umieć...

OK, mam nadzieję, że argumenty coś tu pomogą ;P

Wygeneruje XML ?

Panowie!

Myslalem, ze chodzi o to aby sobie prace ulatwic i przyspieszyc, a jakie ja tu propozycje widze? Wygenerowac xml przy pomocy php poto aby go przetwarzac przy pomocy xsl.

A ja sie pytam po jaka chol...?

Odczytam sobie dane z bazy. Poukladam w tablicach. Przemiele i przemluce na 10 roznych sposobow aby otrzymac pozadany wynik. Potem przeksztalce w drzewo xml, a nastepnie znowu zamieszam.

Kontrola bledow na poziomie php, potem trzeba zadbac o DTD formatu xml i tak zamiast zajmowac sie logika aplikacji, ja zajme sie kolejnymi przeksztalceniami i kontorla ich poprawnosci.

A graficy, o ktorych beztroske tak sie wiekszosc tutaj martwila beda musieli opanowac xml i xsl, co moim zdaniem jest trudniejsze od htmla, css i tej odrobiny logiki ktora narzuca smarty razem wziete.

Jaki jest tego sens, to zwiększa komplikacje, czas i po co przetwarzać kilka razy te same dane, jak można zrobic to prościej...?

Ja też się pytam

Chodzi oto, aby było jak najprościej dla grafika, czy designera a nie aby musial znać inne standardy. Łatwiej mu napisać:

Choć dtd i xml powinien robić programista, a xsl tylko grafik

Tak na marginesie, a czy nie jest przypadkiem tak, że jeśli system generuje kod zgodny ze standardami ( xhtml ) to grafik tylko CSSem się martwi ?

Trafiłeś w sedno. xHTML ma właśnie taki cel - by oddzielić w całości treść od prezentacji (coraz bardziej zbliżyć się do XML'a). Prezentacja powinna być w całości określona przez style. Zobaczcie na CssZenGarden - każdy layout na tej stronie korzysta z jednego dokumentu HTML. Ja byłem pod wrażeniem

Czyli możemy stwierdzić, że kod html może być wygenerowany programowo (np.: przez DOM - tak jak XML), a grafik zajmuje się tylko CSS,

--
Wracając do dyskusji nad poszczególnymi systemami szablonów: jak sądzicie, co jest nie tak z szablonami w stylu

phpLib/phpBB2? Dlaczego nie używalibyście czegoś takiego:

[HTML] pobierz, plaintext 
<!-- BEGIN newslist -->
  <table>
   <tr>
     <td>{$user_name}</td>
     <td>{$user_email}</td>
   </tr>
  </table>
<!-- END newslist -->
[HTML] pobierz, plaintext 

Dość długo korzystałem z podobnego rozwiązania i w zasadzie nie wiem, dlaczego z niego zrezygnowałem. Bardzo minimalistyczne i proste dla designerów.

Ogólnie jestem zdania, że szablony nie powinny zawierać elementów charakterystycznych dla imperatywnego stylu programowania (np. if, foreach, while), ale w tym wypadku, dla czytelności, byłbym skłonny dodać instrukcje IF, ELSE - w końcu XSLT też ma if i foreach . Różnica ze Smartym polegałaby na tym, że nie stosowalibyśmy żadnych obliczeń typu <!--IF $zmienna eq 10 --> itp. Po prostu mamy <!-- IF show_login_box -->.

Rozwiązanie mało innowacyjne, stare jak świat. Na pewno wielu z Was zaczynało właśnie od podobnych rozwiązań. Back to the primitive


Druga sprawa:
Rozwiązanie z DOM omawiane wcześniej jest po prostu idealne dla ludzi od htmla. Pomimo zalet tego rozwiązania nadal nie jestem przekonany do jego użycia. Pierwsze problemy zaczynają się z pętlami. Powiedzmy, że mamy:

[HTML] pobierz, plaintext 
<div id="userlist">
   <span id="name">Dummy name</span>
 </div>
[HTML] pobierz, plaintext 

Trzeba byłoby pobrać wszystkie 'dzieci' tagu 'userlist', powielać je w pętli a następnie zastąpić oryginalną zawartość wygenerowaną listą. Mało efektywne.

Dziwiło mnie dlaczego obiektów z rozszerzenia DOM nie można serializować. Zgłosiłem to jako błąd. Dwóch developerów z php teamu uświadomiło mi, że taka funkcja jest niepotrzebna, bo libxml2 jest tak szybkie, że nawet zserializowany obiekt DomDocument nie będzie się wczytywał szybciej od uruchamiania DomDocument::loadHtml()/loadXML.

libxml jest szybki, ale nie wystarczająco szybki. Dla warunków php takie drzewo jest zbyt duże. Zresztą i tak nie będziemy potrzebowali manipulować wszystkimi tagami HTMLa, lecz tylko niewielką ich częścią. Sposobem mogłoby być dodanie do interesujących nas tagów specjalnego atrybutu (np. <div id="userlist" runat="server">). Wtedy tylko z tych elementów generowalibyśmy drzewo.

Do tego trzeba byłoby parsować dokument 'ręcznie', za pomocą parsera SAX z php (bądź XML_HTMLSax z PEAR) i generować kod tworzący drzewo w czasie wykonywania szablonu (WACT tak działa - tyle, że tu nie mamy żadnych dpdatkowych tagów i komponentów - po prostu czysty HTML). Niestety wymaga to złożonej 'kompilacji' do kodu php. Na koniec można zostać z kolejną kobyłą do szablonów. Ale może warto bliżej się tym zająć?

Moja opinia na temat pętli:
Po co w takim szablonie pętle? IMO powinno to wyglądać tak:
Skoro twierdzicie, że XSLT jest przegięciem do pisania całego systemu szablonów, to jest to rozwiązanie pośrednie.
Mamy szablon w XHTMLu:

[HTML] pobierz, plaintext 
<div id="userlist">
<span id="name">Dummy name</span>
</div>
[HTML] pobierz, plaintext 

Teraz tak. Całą listę urzytkowników trzymamy w XML. Za pomocą mojego systemu (XSLT + cache) generujemy sobie z niej dokument XHTML. Mamy zaimplementowane pętle, mamy gotowy dokument, mamy cache. Teraz DOM wkleja w tego DIVa ten dokument XHTML.

Podsumowując, mamy:

• System cache danych
• Proste dla grafika szablony (sam HTML!)
• Duże możliwości dzięki XML i XSLT

Teraz tylko trzeba zrobić kilka testów wydajnościowych.

@Chmolu -> proste szablony są za proste Też używałem i jakoś nie przypadły mi do gustu...
@matid -> hymm..., czemu by tak nie zrobić?

to poważne ograniczenie, jak XSLT poradzi sobie z obsługą 10 tyś. użytkowników w takim pliku? Optymalniejsze byłoby trzymanie użytkowników w bazie danych (tak jak i wszystkich innych danych)

Co jeśli chcielibysmy wybrać tylko niektórych użytkowników, i jak zdecydować które dane mają zostać wyświetlone?
Pozatym rozpatrujecie trochę inną koncepcję, mi bardziej podoba się szablon jako widok, tj. tworzący i komunikujący się z obiektami. Ot. stworzenie takiego 'jsp' w php Napisałem plugin do savanta (phpsavant.com) umożliwiający używanie obiektów z poziomu szablonu i w tej chwili mnie wyobrażam sobie innego sposobu tworzenia widoków we wzorcu MVC.

A dokładniej? Czego im brakuje?

@chmolu -> jakmentarze jakoś mi nie idą, lepiej napisać: {section} niz <!-- BEGIN SECTION --> i raczej jeśli już to wyższą idęą jest Smarty lub inny system szablonów tego pokroju niż phpBB

Mało przekonywujące. Akurat składnia <!--BEGIN xx --> jest o wiele mniej skomplikowana niż

[PHP] pobierz, plaintext 
<?php
 
{section name=customer loop=$custid}
	id: {$custid[customer]}<br>
	name: {$name[customer]}<br>
	address: {$address[customer]}<br>
	<p>
{/section}
 
?>
[PHP] pobierz, plaintext 

Ale każdy robi tak jak lubi.

Jakieś inne argumenty przeciw szablonom phpLib?

@chmolu -> ja ci odpowiem dlaczego temlates pochodzenia phpBB sa dla mnie za proste. Nie wiem jak to jest w phpLib bo nigdy nie uzywalem ale w przypadku rozwiazania grupy phpBB glowna wada byl brak mozliwosci zagniezdzenia petli.

Podam przyklad

[HTML] pobierz, plaintext 
<!-- BEGIN newslist -->
<table>
<tr><td>{$news}</td></tr>
  <!-- BEGIN commentlist -->
  <tr><td>{$comment}</td></tr>
  <!-- END commentlist -->
</table>
<!-- END newslist -->
[HTML] pobierz, plaintext 

To nie dzialalo.

Poza tym chwale sobie mozliwosci jakie daje mi "if", inaczej warunkowanie sposobu formatowania musialbym przeprowadzac na warstwie logicznej.

@matid -> polaczenie xml i xslt zeczywiscie ma duze mozliwosci, ale:
1. Tak jak juz zauwazyl ebe trzymanie danych w bazie danych jest bardziej efektywne, a nie widze sensu przeksztalcac danych pobranych z bazy w format xml, aby za pomoca xslt otrzymac xhtml skoro moge to uzyskac bezposrednio uzywajac php.
2. Skoro mozesz przeslac grafikowi do obrobki plik xhtml wygenerowanego przy pomocy xslt dzialajacego na xml to rownie dobrze mozesz mu przekazac strone zgodna z xhtml uzyskana przy pomocy smarty.

Moim skromnym zdaniem prosciej jest utworzyc szablon w smarty niz w xslt (nawet ignorujac kwestie DTD).

Osobiscie bawie sie w xml tylko jesli musze. Jesli otrzymuje dane w tym formacie wtedy najchetniej przeksztalcam je w tablice np przy pomocy ponizszej funkcji.

[PHP] pobierz, plaintext 
<?php
 
/**
 * Get contents from XML file and insert into an array
 *
 * @param string $file
 * @return mixed
 */
function xml2php($file) {
 
   $xml_parser = xml_parser_create();
   if (!($fp = fopen($file, &#092;"r\"))) {
	   die(&#092;"unable to open XML\");
   }
   $contents = fread($fp, filesize($file));
   fclose($fp);
   xml_parser_set_option($xml_parser, XML_OPTION_CASE_FOLDING, 0);
   xml_parser_set_option($xml_parser, XML_OPTION_SKIP_WHITE, 1);
   xml_parser_set_option($xml_parser, XML_OPTION_TARGET_ENCODING, 'UTF-8');
 
   xml_parse_into_struct($xml_parser, $contents, $arr_vals);
   xml_parser_free($xml_parser);
 
   return $arr_vals;
 
}
 
?>
[PHP] pobierz, plaintext 

Pewna zaleta polaczenia xml z xslt w kontekscie stron internetowych jest to iz technologie te mialy z zalozenia dzialac rowniez po stronie klienta. Jednak nie wszystkie przegladarki maja zaimplementowany parser xml, a jesli nawet to w rozny sposob realizuja przeksztalcenia xsl. O obsludze dtd, a co za tym idzie walidacji w zasadzie mozna zapomniec.

@bigZbig: zagnieżdżone pętle da się zaimplementować. IF'y też mogłby by ewentualnie się znaleźć w szablonach, ale bez żadnych obliczeń (patrz wcześniejsze posty).

Jak na razie wychodzi na to, że tak prosty system szablonów nie ma większych wad

OT
1. Każda aplikacja (bardziej złożona od Hello world) posiada błędy.
2. Jeżeli aplikacja nie posiada błędów patrz punkt 1.
/OT

Hymm, to może napiszemy język programowania tempaltów. Teraz już jestem pewien, najlepiej używać gotowych rozwiązań, ponieważ są supportowane i rozwijane i testowane. I niewiele się męczysz
I to mówiłem ja Nievinny (zaawansowany użyszkownik php )

PS Sam nie wiem dlaczego moje poglądy się zmieniły

Jedna nawrócona duszyczka

To sie wiedziało od hoho i nawet dłużej
Po co wyważać otwarte drzwi ? (to się nie tyczy sesji)

@chmolu -> Jestem jak najbardziej za skladnia, jak to nazwales "uproszczonych templatow". Napisalem Ci jedynie dlaczego przestalem uzywac rozwiazania grupy phpBB. Nie wykluczam, ze gdyby wspomniany system szablonow zostal wzbogacony wlasnie o zagniezdzane petle i pewne struktury kontrolne to nie wykluczam, ze wrocilbym do niego.

Kwestia sporna pozostaje czy w szablonach potrzebne sa funkcje typu upercase(), lub trim(). Pierwsza z wymienionych mozna rownie dobrze zrealizowac przy pomocy css-ow. Natomiast obcinanie za pomoca php tyle, ze powstaje pytanie czy to jest formatowanie czy obrobka danych na poziomie logiki. Inna sprawa jest to, ze akurat funkcja trim() zrealizowana w smarty jest bardzo wygodna i elastyczna.

Zgadzam sie, ze obliczenia nie powinny byc wykonywane w szablonach, ale np. includowanie jak najbardziej bo inaczej ogolny uklad strony musialbym realizowac niejako poza systemem szablonow, a tak tworze sobie najpierw szablon ogolny do ktorego dolaczam poszczegolne czesci.

A propo's jeszcze xslt jako technologii do tworzenia szablonow. Przy pomocy xslt dokonujemy nie tylko formatowania danych ale mamy takze mozliwosc selekcji danych, a wiec dzialan zarezerwowanych w tradycyjnej aplikacji php dla bazy danych. Dla jednych to zaleta, natomiast dla zwolennikow maksymalnej prostoty oraz purystow lubiacych wyrazny podzial na "wladze ustawodawcza i wykonawcza" to wada.

Mówiąc o szablonach phpLib/phpBB2 miałem na myśli głównie składnię, a nie konkretną implementację.

Jak na razie jestem zdania, że <!-- INCLUDE -->, <!-- BEGIN x -->, <!-- END x -->, <!-- IF x -->, <!-- ELSE --> kompletnie wystarczą do wszelkich celów i są stosunkowo przyjazne dla osób nie znających php.

Całą wartość szablonów dostrzegłem dość niedawno, kiedy próbowałem zrobić styl do forum Simple Machines. Spróbujcie, a się przekonacie, co mam na myli

Co do zmiennych w szablonach, to osobiście uważam, że {zmienna} lub {$zmienna} będzie lepsze niż <!--zmienna-->. Powiedzmy, że musimy zrobić coś takiego:

[HTML] pobierz, plaintext 
<img src="./obrazek.jpg" alt="<!--opis-->" />
 
<img src="./obrazek.jpg" alt="{opis}" />
[HTML] pobierz, plaintext 

Mimo wszystko komentarze HTMLa w atrybutach wyglądają dość dziwnie, a zgodność ze specyfikacją HTML'a też się kończy

Jeśli chodzi o funkcje typu capitalize(), trim(), nl2br(), Zyx ma rację - szablony przydają się także do generowania zwykłego tekstu (np. emaili do użytkowników) i wtedy CSS nam nie pomoże. Jednak nie widzę większego sensu w dodawaniu takiej funkcjonalności do szablonów.

Dostalibyśmy wtedy {zmienna|trim}, które zostanie zamienione na <?php $zmienna = trim(zmienna); ?>. Może i ładniej to wygląda, ale dokłada niepotrzebnego balastu do kodu. Dodając coraz to nowe 'nakładki' na standardowe funkcje php skończylibysmy z kolejnym systemem parsującym swój język programowania (patrz Smarty )

capitalize(), strtoupper() można zastąpić stylami CSS. Poza tym takie operacje można wykonywać z kodu, który stoi za szablonem. Dzielimy wtedy 'widok' na dwie części: kod php zajmujący się logiką i szablon HTML. W Smarty cała logika jest w szablonach, a to jest złe

Też z początku byłem zwolennikiem XSLT jako języka szablonów. Jednak w php takie rozwiązanie jest 'przekombinowaniem' - keep it simple , php to nie Java. XSL świetnie spawdza się jednak w CMS'ach. Treść przechowywana w XMLu może być dowolnie przekształcona do HTML'a, PDF, czy RTF. Ale do generowania całych stron... :/

@Ociu -> a jednak czytałeś? ;P Nie sądziłem, że ktoś kiedyś mi to przytoczy..., jak pisałem mojego powyższego posta to mi się to przypomniało :X Dzięki :*

Więc ogólnie ustaliliśmy, że XSL się nie nadaje, a więc zostaje nam Smarty i OPT oraz phpLib/phpBB i koniec dyskusji skoro woszliśmy do punktu wyjścia...

od Zyx'a:
hmmm... miałbym do dodania co najwyżej tyle, że capitalizy i te inne mogą być zależne od szablonu (np. w designie A tytuły pisane dużymi, w designie B - małymi). I co wtedy? W php na sztywno tego nie zakodujesz. No... co prawda ten przykład to da się na samym CSS zrobić, ale przecież mogą być bardziej skomplikowane rzeczy. Trzeba brać naprawdę dużo czynników pod uwagę, a nie iść wszędzie z głosem "w CSS2 jest taka możliwość, więc płoń święty ogniu i spal polecenia typu capitalize, ten ciemnogród głupi" . Szczególnie, że tu też wszystko może zależeć od przeglądarki...
Jednym słowem: jak ci nie pasuje, to tego nie używaj, w koncu nie dostajesz przez to bonusowego spowolnienia

Przepraszam, ze sie wtracam ale troche smieszy mnie ta wymiana dyskusji miedzy Zyx'em a forumowiczami.
Na litosc boska czy to jest jakas spraw rozwodowa, ze do udzialu w dyskusji potrzebni sa rzecznicy ?

Sorry, ze to poruszylem ale czytam sobie ten watek i sadze, ze delikatnie mowiac wyglada on niepowaznie.

zgadzam sie


z tym tez sie zgadzam