Skocz do zawartości

Szablony (template) niepotrzebne?


Elf

Rekomendowane odpowiedzi

aha, w sensie nie chodzi o samo logowanie tylko o rozroznianie tego kto sie zalogowal i w zaleznosci od tego wyswietlac content strony, no to sie zgodze ze trzeba w szablonie robic ify, bo oddzielne szabony dla kazdej grupy odpadaja, innego rozwiazania nie znam niestety

stancje Nieruchomości, stancje, Euro 2012

Odnośnik do komentarza
Udostępnij na innych stronach

  • Odpowiedzi 60
  • Dodano
  • Ostatniej odpowiedzi

Elf jest to do wykonania w PHP, sprawdzamy żądanie i ładujemy odpowiedni szablon.

Nie wiem jak to jest w smarty ale u mnie moge załączyć strone do zmiennej:

Template::assignTemplate( $varInTemplate, $codeTemplate );

A w szablonie potem używam zawartości zmiennej $varInTemplate np. {$onet} a w $codeTemplate jest kod html onetu.

stopka usunieta z wpoodu wirusa na stronie docelowej

Odnośnik do komentarza
Udostępnij na innych stronach

Jasne. Tyle, ze wtedy nie masz wszystkiego w szablonie. Logike wyswietlanai masz wtedy w PHP. Majac sam szblon nie bedziesz w stanie okreslic co on wyswietli.

Oficjalna strona serii Football Manager ( FM 2005, FM 2006 ) - CM Revolution

Forza MLKS Woźniki Śląskie!

Odnośnik do komentarza
Udostępnij na innych stronach

  • 11 miesięcy temu...
Glowna zaleta stosowania szablonow jest odseparowanie od siebie logiki i wyswietlania sajtu.

Doprawdy? Jakoś w poniższym kodzie szablonu wątpię żeby była odseparowana logika.

{BEGIN:category}

{IF:$category.categoryLevel > $category.oldLevel}

<ul>

{VAR:parentLevel = [CREATED:category.categoryLevel] }

{ELSE}

{VAR:repeatUL = str_repeat("</ul>", [CREATED:parentLevel] - [CREATED:category.categoryLevel]) }

{$repeatUL}

{/IF}

<li class="page_item"><a href="{$path}Zobacz/Kategoria/o/{$category.categoryURL}" title="{$category.categoryTitle}">{$category.categoryName}</a>

{END}

{VAR:repeatUL = str_repeat("</ul>", [CREATED:maxLevel] - 1 ) }

{$repeatUL}

I takie coś żeby zrozumieć to musimy się uczyć smarty języka. A jak się nam znudzi smarty i przejdziemy na inne szablony to znów będzie trzeba się uczyć jakihś pierdół. Tylko poco to skoro można się zamiast tego doskonalić w php?

Fakt ze smarty (jak i kazda dodatkowa wartwa abstrakcji) obciaza dodatkowo serwer i spowalnia aplikacje, ale w bardzo niewielkim stopniu.

Tak? Którego serwera? Twojego? Jak masz mało odwiedzin to i możesz sobie zrobić menu które będzie generowało 500 zapytań i też możesz mówić że to ci serwera nie obciąża. Generalnie Smarty jest niewydajne.

Niewiem poco wogóle robić takie coś jak szablony? Przecież sprawę "odseparowania" html'a od php można zrobić na wiele dużo lepszych sposobów.

Można includować pliki php z kodem html w którym mamy <?= $text ?>

Albo jak mamy dużo elementów strony to można zrobić sobie pliczek template.php i tam umieszczać funkcje które wyświetlają dany fragment strony. A w kodzie php umieszczamy tylko warunki np. if($zmienna){ logo();}

I jest pełna gitara. A jak mamy stronę główną składającą się z 20 elementów (20 niezależnych "kawałków") i wszystko na warunkach to musimy wybrać (jeśli robimy to na szablonach) czy chcemy mieć 1 szablon i w nim warunki, przez co wyjdzie nam taka sieczka jak w powyższym kodzie, lub możemy mieć 20 szablonów i każdy parserować w zależności od warunku, przez co tracimy na wydajności.

Obudźcie się ludzie...

Odnośnik do komentarza
Udostępnij na innych stronach

Tylko, że chodzi o oddzielenie nie kodu HTML od kodu PHP ale logiki biznesowej od logiki prezentacji.

Logika biznesowa:

wyświetl użytkowników zalogowanych w ciągu ostatnich 5 dni.

Logika prezentacji:

wyświetl wynik w tabeli z pogrubionym nagłówkiem, w 3 kolumnach z co drugim wierszem w kolorze niebieskim.

Smarty też wg mnie są przekombinowane. To samo da się dużo lepiej zrobić wykorzystując php do oprogramowania prezentacji w pliku html (<?= $text ?>) (takie coś też się nazywa szablon, tylko że nie korzystamy z dodatkowej warstwy implementującej w php język skryptowy). Warstwa biznesowa do biznesowej (php, mysql), prezentacyjna do prezentacji (php, html) - jak się to pomiesza to łatwiej napisać cały projekt od nowa, niż coś w nim potem zmienić. Cała logika biznesowa powinna być niezależna od logiki prezentacji (tzn. pierwsze przetwarzamy całą warstwę biznesową a potem prezentacyjną).

Odnośnik do komentarza
Udostępnij na innych stronach

mhh, pewnie wyjde na nieuka i głupka ale powiem tak:

* pisalem bez templatów średniej wielkości serwis dla samego siebie tworząc magiczne funkcje typu head, top itd, które wyświetlały poszczególne elementy i generowałem kod html bezpośrednio w PHP, bardzo wydajne tylko zeby coś zmienić to po pewnym czasie dostawałem kurw...

Czytelność kodu (którego przybywało i przybywało wraz nowymi pomysłami, nowymi sztuczkami do pozycjonowania, czy powiedzmy po wprowadzeniu płatności online itp) stała się zerowa,

trza było coś z tym zrobić....

* w między czasie pisałem serwisy korzystając z banalnych templatów (coś na zasadzie brania pliku HTML, robienia str_replace dla zmiennych itp) i funkcji klas w PHP które odpowiadały tylko za wyświetlenie kodu HTML ale przestało to działać jak klient stwierdził zeby zrobić jeszcze dwie kopie serwisu (oczywiście płatnie) tylko aby to wyświetało się tak ale coś wyświetlało inaczej... A najlepiej aby mógł on sam pewne elementy zmieniać (np. kod reklam czy dodawać linki do pozycjonowania itp).

Tutaj doszedłem do wnioski iż robienie własnego systemu templatów mija się z celem i najlepiej skorzystać z gotowych (obsługa pętli, cachowanie wyników itp),

* W końcu doszedłem do wniosku iż należy korzystać z gotowych systemów templatów, co uzysałem:

- uprościł się kod PHP (poza rekurencją w jednym przypadku wszystko co tyczy wyglądu tworzone jest w templatach), znacznie łatwiej jest wprowadzić nową funkcjonalność czy ogólnie zapanować nad kodem

- można wprowadzać poprawki do wyglądu bez wbijania się w logike PHP (i szukania po całym projekcie gdzie jest funkcja która generuje ten kawałek strony, po roku - dwóch średnio się pamięta jakie to miało się "genialne" pomysły)

- narzuty czasowe związane z korzystaniem z systemu templatów wyrównywane są przez korzystanie z mechanizmu cachowania wyników HTML (czyli coś generuje od nowa jeżeli nie jest w cache-u i nie jest ważne)

- nie trace czasu na rozwiajnie pośrednich rzeczy (jak własny system templatów), za których nie dostaje kasy.

Fakt, korzystanie z templatów musi być sensownie zaplanowane (ja jeszcze się tego ucze).

ps. mnie się bardzo podoba system templatów "Open Power Templates" (czy jakoś tak), wydajny (co najmniej 2 razy lepszy do smarty), skompilowane templaty to czysty HTML + PHP i cachowanie wyników HTML :). I poznałem go dzięki komuś stąd...

Ale jak mówie, jestem początkujący i nie zamierzam nikogo przekonywać...

Odnośnik do komentarza
Udostępnij na innych stronach

używanie szablonów - czyli odszielenie kodu php od html to rzecz oczywista i niezbędna

uźywanie systemu szablonów to jedna jak wczesniej napisali już ludzie sztuka dla sztuki - w zasadzie bez sensu.

Jeżeli ktoś ma wątpliwości i tak błogosławi SMARTY to proszę zajrzeć do katalogu templates_c

i podjerzeć pliki z "przekompliowanymi" szablonami na php ... wydaje mi się, że średnio kumaty phpwoec takie "superpliki" przygotuje sam tym bradziej że nie są ani odrobinę bardziej skomplikowane od szablonów, z tym, że system musi je przygotować ;).

Odnośnik do komentarza
Udostępnij na innych stronach

Możesz mi coś wytłumaczyć? bo jak pisze jestem początkujący...

skoro oddzielasz logikę HTML od PHP a jednoczesnie nie stosujesz systemów templatów to jak rozwiązujesz problemy np. pętli w swoich szablonach albo cachowanie wyników HTML ?

a co do skompilowanych templatów? to było dla Ciebie takie straszne i odkrywcze? Myślaleś że jak to działa?

Odnośnik do komentarza
Udostępnij na innych stronach

a co do skompilowanych templatów? to było dla Ciebie takie straszne i odkrywcze? Myślaleś że jak to działa?

tak kiedyś mniej znałem php i nagle to odkryłem i się zdumiałem ;) naprawdę.

kod skompilowany stopniem trudności i skoplikowania niczym nie różni się od kodu szablonów z tym, że szablony wprowadzaja dodtakowy niepotrzebny poziom.

template w PHP

<? if ($warunek==1) { ?> <strong> sialala </strong> <?}?>

smarty

{   if $warunek== 1}	 <strong> sialala </strong>  {/if}

aż do tego trzeba systemu szablonów ;)

Odnośnik do komentarza
Udostępnij na innych stronach

Może do prostych stron używanie systemu szablonów to sztuka dla sztuki ale przy bardziej zaawansowanych gdy chcemy coś zmienić od razu pokazuje jak wydajna jest praca na szablonach. Chociażby wczoraj zmieniałem całkowicie adresowanie w jednym z serwisów + zamiana klasy mysql na pdo (były podobnie rozwiązane) i kilka innych poprawek - zajęło mi to 15 min. Do innego serwisu opartego nie na szablonach a własnych rozwiązaniach czyli mieszanka php i html nawet nie chce mi się podchodzić bo nie wiem czy w dzień bym skończył.

Systemy szablonów to także automatyzacja pewnych procesów: cachowanie, wyświetlanie grup wyników itp. Prosty kod z niewydanego jeszcze OPT na kolorowanie co drugiego wiersza:

{section=products}
{cycle='class'; 'brighter'; 'darker'}
<tr>
<td opt:sectioncycle="products">{$products.name}</td>
<td opt:sectioncycle="products">{$products.price}</td>
</tr>
{/section}

Proste, łatwe, przyjemne. A napiszcie to w php i zastosujcie po kilka razy. W dobrze napisanym systemie oddzielasz całkowicie kod php od szablonu. W php wykonujesz obróbkę danych, pracę na bazie a do szablonu przekazujesz jedynie wynik i wtedy następuje to oddzielenie.

Odnośnik do komentarza
Udostępnij na innych stronach

vikingpl: ale to samo możesz zrobić bez smarty, dokładnie tak jak pisze mrtn. Rozdzielenie jest takie samo, możliwości większe a kłócić się można tylko o to co jest bardziej przejrzyste.

Odnośnik do komentarza
Udostępnij na innych stronach

No i właśnie w szablonach chodzi o tą przejrzystość. Z przykładu mrtn wolę mieć opcję 2 niż dla jednej klamerki tworzyć blok <??> (na którym zresztą możnaby się przejechać przy wyłączonych krótkich tagach więc poprawnie dłuższe <?php ?>). Wyobraź sobie później zmianę takiego kodu. Tak samo wolę mieć zautomatyzowaną obsługę tablic (sekcje) czy jak w podanym przeze mnie przykładzie liczników. Przy szablonach mam jeden plik php który odpowiada za generowanie każdej podstrony (inni mogą inaczej robić) - logika, sprawdzanie poprawności danych, obsługa baz, sesji i co tam sobie zapragniemy. Przy zmianach mam wszystko na wierzchu, przejrzyście napisane. Mogę zmienić ten plik i nawet nie tknąć szablonu. A normalnie pewnie wszystko byłoby przeplecione - pobranie danych z bazy, zaraz potem jakieś foreach, if wymieszane z htmlem. Grzebać w takim pliku jest mało przyjemne. Przy wielu projektach mamy większość rzeczy stosowanych wcześniej przygotowane, wyrobione pewne nawyki - to upraszcza i przyśpiesza proces tworzenia strony. A nauczenie się dodatkowych tagów to chwila. Tak samo nie jest prawdą że będzie wolniej bo smarty jest kobyłą i ma dużo kodu.

PS. Ja też długo wzbraniałem się przed korzystaniem z szablonów tłumacząc sobie właśnie w ten sposób - po co używać szablonów skoro mam praktycznie to samo tylko inaczej zapisane. Ale trzeba z nich skorzystać żeby zrozumieć i poczuć różnicę. Teraz żadnej, nawet najprostszej strony nie robię już "normalnie".

Odnośnik do komentarza
Udostępnij na innych stronach

No i właśnie w szablonach chodzi o tą przejrzystość. Z przykładu mrtn wolę mieć opcję 2 niż dla jednej klamerki tworzyć blok <??> (na którym zresztą możnaby się przejechać przy wyłączonych krótkich tagach więc poprawnie dłuższe <?php ?>). Wyobraź sobie później zmianę takiego kodu.

nie przemawiają do mnie twoje argumenty. Zmiana kodu w obu przypadkach jest identyczna, więc w czym problem? Że w pierwszej wersji masz 4-7 znaków więcej (klamerki php)? Przecież od kilku stuków więcej w klawiaturę nie można od razu skreślać tej metody :)

Tak samo wolę mieć zautomatyzowaną obsługę tablic (sekcje) czy jak w podanym przeze mnie przykładzie liczników. Przy szablonach mam jeden plik php który odpowiada za generowanie każdej podstrony (inni mogą inaczej robić) - logika, sprawdzanie poprawności danych, obsługa baz, sesji i co tam sobie zapragniemy. Przy zmianach mam wszystko na wierzchu, przejrzyście napisane. Mogę zmienić ten plik i nawet nie tknąć szablonu. A normalnie pewnie wszystko byłoby przeplecione - pobranie danych z bazy, zaraz potem jakieś foreach, if wymieszane z htmlem. Grzebać w takim pliku jest mało przyjemne.

chyba zupełnie źle interpretujesz podany przykład. W obu przypadkach jest identyczny rozdział M, C od V. W jednym i drugim przypadku wszystkim związanym z obsługą aplikacji i danych zajmujesz się w kontrolerze i modelu. Różnica jest tylko taka, że w pierwszym sposobie uzywasz bezpośrednio php w widoku do prezentacji danych, a w drugim przypadku zaprzegasz to php aby jeszcze poparsowało sobie wymysloną wcześniej składnie szablonów.

Tak samo nie jest prawdą że będzie wolniej bo smarty jest kobyłą i ma dużo kodu.

to akurat jest prawda ;) wolne to jest tak, że szkoda gadać ;)

PS. Ja też długo wzbraniałem się przed korzystaniem z szablonów tłumacząc sobie właśnie w ten sposób - po co używać szablonów skoro mam praktycznie to samo tylko inaczej zapisane. Ale trzeba z nich skorzystać żeby zrozumieć i poczuć różnicę. Teraz żadnej, nawet najprostszej strony nie robię już "normalnie".

ja się nie wzbraniam, epokę smarty mam już parę lat za sobą ;)

Odnośnik do komentarza
Udostępnij na innych stronach

{section=products}

{cycle='class'; 'brighter'; 'darker'}

<tr>

<td opt:sectioncycle="products">{$products.name}</td>

<td opt:sectioncycle="products">{$products.price}</td>

</tr>

{/section}

Proste, łatwe, przyjemne. A napiszcie to w php i zastosujcie po kilka razy. W dobrze napisanym systemie oddzielasz całkowicie kod php od szablonu. W php wykonujesz obróbkę danych, pracę na bazie a do szablonu przekazujesz jedynie wynik i wtedy następuje to oddzielenie.

finction pro($prodyctname, $productprice){

echo '<tr>

<td opt:sectioncycle="products">'.$productname.'</td>

<td opt:sectioncycle="products">'.$productprice.'</td>

</tr>';

}

Odnośnik do komentarza
Udostępnij na innych stronach

Zarchiwizowany

Ten temat przebywa obecnie w archiwum. Dodawanie nowych odpowiedzi zostało zablokowane.

  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.

×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Umieściliśmy na Twoim urządzeniu pliki cookie, aby pomóc Ci usprawnić przeglądanie strony. Możesz dostosować ustawienia plików cookie, w przeciwnym wypadku zakładamy, że wyrażasz na to zgodę. Warunki użytkowania Polityka prywatności