Z mojego punktu widzenia przygotowanie dobrych danych wyjsciowych to jeszcze logika, a nie juz prezentacja. Wystarczy $line['nazwa_lok'] zawieralo juz wyescapowany string i nie ma problemu z jego uzyciem. A dlaczego logika ma się dostosowywać do prezentacji? To ta ostatnia powinna wiedzieć jak wyświetlić przekazane dane - czy w stanie surowym jako czysty tekst, czy z zamianą na encje w atrybutach HTML czy też może w objęciu w cudzysłowy w pliku CSV.
Silverstorm pisze:
<input type=text size` name=p_nazwa value="<?PHP echo $line[nazwa_lok]; ?" Poprawna wersja to: A jeszcze poprawniejsza: ;-)
i takim oto krokiem dojdziemy do
Ogolnie tez radze skozystac z template engine'a
Yaaay, po co? W wielu sytuacjach niepotrzebny i ograniczajacy balast. PHP przeciez sam w sobie _jest_ template engine. Wystarczy dobrze przygotowac logike, zeby do plikow PHP generujacych output dochodzily dobre stringi. Z mojego punktu widzenia przygotowanie dobrych danych wyjsciowych to jeszcze logika, a nie juz prezentacja. Wystarczy $line['nazwa_lok'] zawieralo juz wyescapowany string i nie ma problemu z jego uzyciem.
-- Mateusz Papiernik, Maticomp Webdesign Projektowanie i realizacja witryn WWW maticomp.net,maticomp.net "One man can make a difference" - Wilton Knight Zgadzam sie, php jest wystarczajaco dobrym template engine sam w sobie ..ALE.. oczywiscie zalezy od zadania. jezeli takich php&html stron bedzie wiecej niz 5 - bez zastanowienia sie skorzystalbym z jakiegos engine'a. Bo to oszczedzanie na zapalkach bedzie.
A dlaczego logika ma się dostosowywać do prezentacji? To ta ostatnia powinna wiedzieć jak wyświetlić przekazane dane - czy w stanie surowym jako czysty tekst, czy z zamianą na encje w atrybutach HTML czy też może w objęciu w cudzysłowy w pliku CSV.
Borys Pogoreło pisze:
Zalezy od aplikacji. Rownie dobrze moge zapytac, dlaczego prezentacja (i tym samym - autor szablonow) moze miec jakiekolwiek prawo do decydowania o tym, w jaki sposob zostana przedstawione dane. Systemy szablonow sie przydaja, zwlaszcza te ulatwiajace tworzenie dokumentow o prawidlowej strukturze - ale w moim mniemaniu czesto jest to zupelnie niepotrzebna armata na muche, a wyklinanie czystego PHP jako sposobu na szablonu jedynie tworzeniem sobie wlasnych problemow.
Jakos zarowno Symfony, jak Magento (oparta o ZF) w czystym wydaniu radza sobie bez zaprzegania do roboty dodatkowej warstwy parsujacej szablony i zyja - nie bez przyczyny.
A dlaczego logika ma się dostosowywać do prezentacji? To ta ostatnia powinna wiedzieć jak wyświetlić przekazane dane - czy w stanie surowym jako czysty tekst, czy z zamianą na encje w atrybutach HTML czy też może w objęciu w cudzysłowy w pliku CSV.
Zalezy od aplikacji. Rownie dobrze moge zapytac, dlaczego prezentacja (i tym samym - autor szablonow) moze miec jakiekolwiek prawo do decydowania o tym, w jaki sposob zostana przedstawione dane. Systemy szablonow sie przydaja, zwlaszcza te ulatwiajace tworzenie dokumentow o prawidlowej strukturze - ale w moim mniemaniu czesto jest to zupelnie niepotrzebna armata na muche, a wyklinanie czystego PHP jako sposobu na szablonu jedynie tworzeniem sobie wlasnych problemow. Jakos zarowno Symfony, jak Magento (oparta o ZF) w czystym wydaniu radza sobie bez zaprzegania do roboty dodatkowej warstwy parsujacej szablony i zyja - nie bez przyczyny. Bo tego często wymaga konkretny typ prezentacji?
Nie piszę przecież o tym, by autor szablonu zmuszał Cię do kolorowania tekstu na różowo. Tylko o tym, by szablon HTML zajmował się np. zamianą znaków , ", & na odpowiadające im encje jeśli np. dane mają trafić do atrybutów lub do textarea. Z kolei szablon tekstowy z reguły nie musi się tym przejmować.
Dlaczego takie np. Smarty miałoby być "armatą na muchę"? Przecież w rezultacie otrzymujesz dokładnie to, o czym piszesz - szablon w "czystym PHP" ;) Co prawda lepiej do niego nie zaglądać, ale po skompilowaniu narzut nie jest wielki - ot, przekazanie i przetworzenie danych.
ZF przy ich podejściu aż się prosi o wsadzanie logiki do szablonów.