Czy u was w głównym pliku php czyli najczęściej index, macie przeplatany php z html-em? Jak to się robi? Czy polecacie zastosować do przeplatania htmlu z php składni heredoc, czy ona nie wpływa negatywnie na szybkość skryptu?

Pozdrawiam

Możesz zastosować system templatów. ( Szablony... )
Wtedy masz oddzielony PHP od HTML/CSS.

Nigdy nie miałem potrzeby używania heredoc. Zawsze starczało mi echo lub print - ewentualnie printf itp.

W indeksie nigdy nie mam ani linijki kodu html. W indeksie wywołuje się funkcję lub metodę jakiejś klasy która wyświetla treść na stronie. Powinieneś poczytać sobie o oddzieleniu logiki od treści czyli o modelu MVC w aplikacjach internetowych, a także o używaniu szablonów.

@Mize - nie o oddzielenie PHP od HTML chodzi, tylko o oddzielenie logiki od widoku i to trzeba podkreślać, bo ludzie potem herezje głoszą, jakoby systemy szablonów były lepsze od użycia php (które od początku istnienia jest jednym wielkim systemem szablonów).

Pozdrawiam.

No właśnie o to mi chodzi, a czy ktoś ma może linki do jakiś artykułów/tutorialów na ten temat?

Ciekawi mnie to, bo obecnie wszystko mam w głównym pliku php, całe wyświetlanie strony no i oczywiście css, bo przecież ten plik php po przetworzeniu tworzy normalny html ...

Tu masz ładnie napisane: http://www.webday.pl/viewtopic.php?f=24&t=529

kurcze, trochę nie chcę wykorzystywać niczego więcej poza swoim dziełem ;d

Czy macie jakieś pomysły jak to wszystko zrobić bez użycia żadnych takich dzieł innych osób?

To nie używaj. Użyj PHP osadzanego w HTML. W cywilizowanych frameworkach tak się właśnie robi
o np.

[PHP] pobierz, plaintext 
Imię: <?php echo $user->getName(); ?>
[PHP] pobierz, plaintext 

ahahahahahaha. Tekst roku.
1. Smarty i OOP mijają się o lata świetlne.
2. Smarty pozwala co najwyżej na zastąpienie kodu PHP innym kodem, który i tak potem jest konwertowany do czystego PHP. Jest to nakładka na PHP dla grafików, którzy są za leniwi i zbyt przestraszeni, żeby nauczyć się podstawowej składni języka PHP.
Twierdzenie, że Smarty "pozwala" na separację logiki od prezentacji to nadużycie. Ta biblioteka przyjmuje kolekcję danych i przekazuje (tu raczej wstawia) do szablonu. To nawet nie jest 30% warstwy prezentacji. Każdy framework implementujący MVC robi dokładnie to samo. Jedyna różnica to wygląd pliku szablonu, Oddzielenie logiki od prezentacji nie ma nic wspólnego z silnikiem renderującym jakim jest Smarty i każdy inny system szablonów.

Wybaczcie taki ostry atak, ale naprawdę to już nawet nie jest śmieszne. Używane Smarty to jedna rzecz (co kto lubi), doklejanie ideologii to druga. Ja nie ze Smarty walczę ale z mitami.


Autor (ooop to admin jest) nie powinien pisać będąc na imprezie.

Pozdrawiam i sorki za lekki offtop.

@Cysiaczek - Ty taki stary wymiatacz jesteś ale tym razem to palnąłeś

add 1
Smarty ma obiektowy interfejs, a że znaczne jego fragmenty są napisane proceduralnie to ze względu na kompatybilność wsteczną oraz wydajność. Ktoś kiedyś na tym forum zadał sobie trud napisania nowego systemu szablonów, całkowicie obiektowego o możliwościach porównywalnych ze Smarty. Robił testy wydajności i porównania i wyszło mu, że kod proceduralny jest zwyczjanie szybszy od obiektowego.

add 2
Nie zgodzę sie z Tobą, że to jest tylko nakładka. Smarty ogranicza możliwość wykonywania dowolnych działań na zmiennych właśnie dlatego aby zmusić programistę do robienia tego w warstwie logiki, a nie w warstwie prezentacji, więc jeśli jakiś zespół decyduje się na użycie Smarty zamiast natywnego php to nie dla grafików (którzy i tak nie dłubią w szablonach), tylko dla webdeweloperów i to nie ze względu na ich wygodę tylko po to aby zajęli się warstwą wizualną a nie logiką.

Tak swoją drogą to składnia smarty jest przyjemniejsza w użyciu niż czysty php




Powyższe uwagi dotyczą nie tylko Smarty ale wielu innych systemów szablonów zarówno w php jak i w innych językach.

Te same właściwości mają np. szablony w django

bigZbig, zamiast używać ograniczającej nakładki można po prostu przyjąć pewne założenia na starcie i się ich trzymać. A nawet pisząc w smartach możesz bez większych problemów wszystko wymieszać.

Poza tym jakoś nie widzę przewagi składni smarty nad chociażby takim zapisem:

Nie przesadzaj. Kod Smarty to psełdo OOP. Śmietnik i tyle. Albo się pisze obiektowo albo nie.
To akurat nic nowego. Cokolwiek napiszesz, to kod proceduralny zawsze będzie szybszy.
Ogranicza?! Smarty ogranicza logikę? Wolne żarty.
Po co więc jest {include_php}, {php}, {assign}, {eval}, {math}, resources. Wszystko to nie powinno istnieć.
Smarty na pewno nie jest ukłonem w stronę webdeweloperów. Dziwaczna, koślawa składnia. Taka do niczego nie podobna. Jeśli ukłon w stronę deweloperów to PHP Tal, którego składnia bazuje na XMLu i jest przyjazna deweloperom.
Czy ja wiem?:
vs.

Obawiam się, że Smarty mają więcej wad niż zalet.

Ja widzę bo taka składnia jest uzależniona od opcji short_open_tag w konfiguracji php. Opcja ta ma zniknąć w php6, a z tego co wiem to w php 5.3 też już będzie niedostępna więc powyższy zapis będzie niepoprawny.

Nie zmienia to oczywiście faktu, że Smarty faktycznie przydałoby się przepisać od nowa - niekoniecznie zachowując kompatybilność wsteczną.

Co do funkcji wspomnianych przez mika

Konfiguracja smarty pozwala włączyć tryb bezpieczny, który uniemożliwia korzystanie choćby z bloków {php}. Eval to w ogóle powinien zniknąć z PHP. {math} faktycznie jest nadmiarowy, natomiast {assign} niekoniecznie, ale nie będę się tu już rozwodził nad przykładami jego użycia.

Wygoda korzystania ze smarty jest kwestią dyskusyjną - dla jednych wygodna dla innych nie.

Można jak pisze l0ud trzymać się założeń, ale smarty moim zdaniem ułatwia ich egzekwowanie gdyż większość nadużyć będzie wymagało jawnego użycia bloku {php}

Smarty to kod proceduralny ujęty w klasy. Jest to zrobione dla wygody użytkownika (trochę też programisty). To, że posiada kilka metod, jakieś settery i gettery, nie czyni go obiektowym. Smarty posiada interfejs i z tym się tylko zgodzę. Wydajność? Obiektowo źle, ale dziesiątki pluginów Smarty dublujących jedynie funkcje php to jest ok wydajnościowo? Przecież to też musi być załadowane do pamięci, a tych plików jest sporo.


Jedyne działania na danych jakie powinno się wykonywać w widoku, to ich formatowanie. Tu Smarty oferuje tylko wspomniane pluginy (z kilkoma dodatkowymi funkcjami). Skoro standardem jest podział na MVC, które jest zapewniane przez każdy framework i zakładając, że Smarty funkcjonuje jako renderer szablonów, to jaki jest sens jego stosowania oprócz wygody (IMO urojonej) webdeveloperów? Przecież php-owiec stosuje interfejs frameworka, który jest niezależny od renderera... Co ma zrobić i tak zrobi - Smarty mu wisi i powiewa. Odczuje to jednak sama aplikacja, bo zamiast na logikę, moc idzie na przerobienie szablonów. Stosując Smarty masz tylko zysk (urojony) dla webdevelopera - na każdym innym polu tracisz.
Dlaczego mówię, że korzyści są urojone? Bo webdeveloper ma wmawiane wszędzie, że Smarty daje jakiekolwiek korzyści, że jest po prostu lepsze. To jest zwykła propaganda. Sam też kiedyś padłem jej ofiarą i myślałem że to Smarty to Bóg wie co takiego wspaniałego i niezbędnego "profesjonalnemu programiście". Tymczasem Smarty jest po prostu alternatywną składnią php i nic więcej. Jeśli dla kogoś jest czymś więcej, pomaga mu zapanować lepiej nad kodem, to ok. Cieszę się z tego niezmiernie. To, co wywołuje u mnie białą gorączkę, to brednie o tym, że trzeba separować php od html, bezreflesyjnie powtarzane przez wannabe-programistów. "Yeah! Napisałem {$cos}, nie mam php w htmlu i jestem pro!". Sorry, jeśli kogoś to razi, ale właśnie tak to widzę.

Pozdrawiam.

Napiszę tak: Smarty pozwala zachować jaką taką estetykę kodu, dodatkowo ułatwia modyfikowanie tego co wyświetla się userowi, a szukanie w kodzie gdzie jest konkretny element szablonu może przyprawić o zawrót głowy. Zdaję sobię sprawę, że ze Smarty trochę przedobrzyli bo większość tych wszystkich bloków i funkcji jest zbędna, ale lepsze to niż html i echo.

Oj nie dziesiątki i nie tylko dublujących. To co w Smarty nazywa się pluginami w nowych frameworkach nazywa się helperami widoku i to też trzeba załadować do pamięci.


Wybacz, ale nie rozumiem o co ci chodzi w tym fragmencie Twojej wypowiedzi. Smarty może być tzw. warstwą widoku we wzorcu MVC, ale nie musi. Ja tylko pisze, że jeśli jest to mogą być z tego pewne korzyści.


O wygodzie już pisałem i nie zamierzam się powtarzać co do mocy przerobowej to Smarty (dla niezorientowanych) przerabia dany szablon do natywnego kodu php tylko raz. Przy kolejnym wywołaniu sprawdza tylko czy dany szablon został już "przekompilowany" i czy coś się w szablonie nie zmieniło co wymagałoby ponownego przetworzenia. Poza tym jak sobie zajrzycie w przerobione przez Smarty pliki to dojrzycie, że kod tam jest zoptymalizowany pod względem wydajności np. poprzez usuwanie zmiennych zaraz po tym jak stają się niepotrzebne.

Jest rendererem szablonów, nie warstwą widoku. Warstwa widoku/prezentacji to pojęcie szersze. Temat: Widok_renderowanie_widoku

[PHP] pobierz, plaintext 
<?php
public function action()
{
  $this->variable='value'; // nie używamy obiektu Smarty jawnie, więc programiście wisi jaki silnik to przetworzy :)
  $this->setTemplate('nazwa_szablonu'); // też niezależne od smarty
}
?>
[PHP] pobierz, plaintext 

To jest separacja logiki od widoku i Smarty jest tutaj zbędne. W niczym nie pomaga - to tylko kupa kodu przetwarzającego inny kod ,aby w nim upchać dane. Po prostu nie jest wyjątkowe, a cechy, które się mu przypisuje są obecnie implementowane na poziomie frameworka (każdego MVC)

Pozdrawiam.

Hmm, z pytania zrozumiałem, że autor nie chce mieć przeplatanego kodu html i php.
Wiem o tym, że oddziela się logikę od warstwy prezentacyjnej, ale uznałem że nie trzeba go od razu rzucać na głęboką wodę. ( MVC... )



Smarty to przestarzały syf, wystarczy przejrzeć źródła.
Mix kiepskiej struktury i niby OOP. Jaki jest sens pisania templatów używając składni Smarty, które i tak są potem konwertowane do PHP ?

Tego artykułu to już w ogóle nie komentuje. Oo

Programiście wisi ale interpreterowi PHP i webdeveloperowi już nie wisi, a jak jesteś takim przeciwnikiem nakładek to pewnie nie używasz też ORM-ów a w Symfony nie korzystasz z YAML-a. W przypadku wszelkiego rodzaju ORM-ów trzeba się uczyć nowej składni i logiki jakby nie można było wszystkiego napisac SQL-u, a Symfony ze swoimi konfigami w YAML-u to co robi. Stosuje wprost czy sprowadza do postaci php-a? Jakby nie można tego było od razu w postaci tablicy zapisać? Kupa kodu... Cały PHP to nic innego jak tylko kupa kodu przetwarzającego inny kod.


Jakie cechy? MVC niczego nie implementuje bo to tylko wzorzec projektowy. Natomiast poszczegolne frameworki narzucają co najwyżej interface.

Ok Panowie na zgode. Smarty nie jest jedynym systemem szablonów i wcale nie twierdze, że najlepszym (w sumie nie mam wyrobionej opinii w tej kwestii). Nie uważam też, że trzeba koniecznie używać jakiegokolwiek systemu szablonów, choć jetem przekonany, że stosowanie szablonów ułatwia separację warstwy widoku od warstwy logiki. W przypadku małych projektów używanie natywnych szablonów php jest dobre. Przy dużych projektach jest to niewygodne.


Jaki jest sens pisania w PHP skoro wszystko i tak jest potem sprowadzane do kodu 01 -kowego

Nie jestem przeciwnikiem nakładek - jestem przeciwnikiem robienia wody z mózgu.
ORM daje policzalne zyski. Szablony nie dają, bo są tylko alternatywą dla składni PHP. To różnica na poziomie jak poniżej

[PHP] pobierz, plaintext 
<?php
echo ('tekst');
echo 'tekst';
?>
[PHP] pobierz, plaintext 

Kilka nawiasów mniej lub więcej - kwestia gustu


Framework implemementuje MVC, które rozdział logiki od prezentacji zawiera z definicji i nie potrzebne mu do tego systemy szablonów. To, co chwali się jako cechę Smarty jest cechą każdego frameworka MVC niezawierającego innego systemu szablonów niż PHP.
Gdyby szablony były takie cacy, to by istniałyby w każdym FW. Obecnie raczej omija się te systemy szerokim łukiem. Duży projekt z użyciem Smarty? To ja podziękuję, zwłaszcza że używam Symfony - z miejsca straciłbym 50% z zalet tego frameworka

Pozdrawiam.

Zapraszam do pisania w systemie 01.

Chodzi właśnie o to, że to jest coś więcej niż kilka nawiasów. Masz składnię dzięki której piszesz o wiele mniej kodu zarówno php jak i html - do tego system cache-owania, który umożliwia ci buforowanie całych stron lub tylko ich fragmentów. Masz gotowe pluginy ale możesz też samodzielnie napisać nowe dzięki którym standardowe operacje na widoku staną się jeszcze łatwiejsze. Masz zbiór zasad i reguł których musisz się trzymać i które wymuszasz także na innych członkach grupy.


Nikt nie każe Ci używać Smarty z Symfony. Można jednak wydajnie używać Smarty z Symfony, ZF czy Kohana - wymaga to jednak wiedzy i przekonania do tego systemu szablonów.

@bigZbig:
jakie konkretnie korzyści daje Ci Smarty? Bo ja bez większego namysłu mogę podać Ci kilka wad:
1) Konieczność poznania kolejnego pseudo-języka
2) Żaden edytor tekstu nie będzie Ci kolorował poprawnie składni kodu XHTML ze Smarty
3) Niepotrzebne obciążenie

ad 1. Eclipse z php-eclipse koloruje kod smarty, ale traktuj to jako ciekawostkę bo to wyjątek - tu się z tobą zgodzę
ad 2. Konieczność poznania pseudo-języka jest faktycznie wadą podobnie jak konieczność poznania specyficznej składni, kiedy chce się używać np. ORM-a albo jquery, albo konieczność poznania metod jakiejkolwiek klasy którą chce się włączyć do własnego projektu.
ad 3. Dlaczego niepotrzebne?

O zaletach Smarty już troszkę napisałem w tym temacie więc wybacz ale nie chce mi się powtarzać. Poza tym choć o Smarty jest tu głównie mowa to tak naprawdę problem brzmi czy używać natywnego php czy dodolnego systemu szablonów, który ma swój własny pseudo-kod.

CoreEditor radzi sobie całkiem dobrze.

Smarty to jednak przykład przerostu formy nad treścią, bo 80% z metod lub bloków jest bez sensu, ale przecież nikt nie każe nam tego używać, a edycja szablonów dla takiego prostego użytkownika jest dużo łatwiejsza niż grzebanie w kodzie PHP który nie ma żadnego dla niego sensu.

Problemem tej dyskusji nie jest "Czy używać systemów szablonów", tylko wypunktowanie nieistniejących korzyści przez osoby polecające Smarty. Dlatego właśnie się z tego śmieje (choć raczej powinienem płakać).
- Smarty pozwala odzielić kod php od html
- Smarty pozwala odzielić logikę od widoku
- Kod szablonów jest bardziej przejrzysty

Ostatnie zdanie to kwestia gustu. Dwa pierwsze tracą znaczenie gdy:
- Uświadomimy sobie, że rozdzielenie kodu PHP od HTML nie jest naszym celem - ono wynika z użycia smarty, czyli jest konsekwencją zastosowania Smarty, ale nie celem
- Uświadomimy sobie, że każdy framework z natury rozdziela logikę od widoku, nawet jeśli w szablonach korzysta z gołego PHP. W tym widoku nadal możemy korzystać ze Smarty. Zyskujemy wówczas jedynie inną składnię

Dalej. Zaawansowany FW jakim jest np. Symfony posiada własne mechanizmy cechowania, partiali, komponentów i inne. Zastosowanie Smarty byłoby jedynie zastąpieniem natywnej obsługi zewnętrzną. Przy czym - natywne mechanizmy zostają zastąpione tylko ze względu na chęć posiadania innej składni szablonów. Te mechanizmy są tak samo wydajne jak te od smarty, więc innych przesłanek nie ma.

Z mojej strony EOT, bo nie umiem już prościej wyrazić tego, o co mi chodzi

Pozdrawiam

Ok ja też jestem za zakończeniem tej dyskusji. Na sam koniec chciałbym jeszcze zapodać odsyłacz do Proof of Concept Smarty 3.0 Alpha 1. Pełna obiektowość, możliwość stosowania natywnego php i parę innych udoskonaleń.

Pozdrawiam