Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Szablon w szablonie
Forum PHP.pl > Forum > Gotowe rozwiązania > Systemy szablonów
jastu
Chciałbym zrobić tak :
- mam sablon strony głównej w której przechowuję szkielet strony (divy i kolumny - jako główny widok).W szablonie tym zawartość każdego diva to zmienna (do której przesyłamy dane jak w szablonach).Tymi zmiennymi miały by być inne szablony (tworzone przez new Smarty).

Czy jest to możliwe do zrealizowania ? Pozdrawiam
mhs
Tak, jest to możliwe. Możesz wykorzystać do tego zwykłe include.
jastu
Chyba nie jest to rozwiązanie. Zapis który przedstawiłeś zawsze inkluduje plik szablonu niezależnie od tego czy został stworzony obiekt widoku dla inkludowanego szablonu . Widzę to tak :
  1. <?php
  2. // $a - główny widok 
  3. $a = new Smarty();
  4. // np menu w głównym widoku
  5. $b = new Smarty(); 
  6.  
  7. // dodajemy coś do szablonu głównego
  8. $a->assign('a','etst sekcji a');
  9. // dodajemy menu do szablonu głównego
  10. $a->assign('b',$b->display('b.tpl'));
  11.  
  12. //wyświetlamy
  13. $a->display('a.tpl');
  14. ?>


Problem polega na tym że w pierwszej kolejności zostaje jednak wyświetlony szablon menu - a chciałbym aby całość została wywołana dopiero w ostatniej lini ( $a->display('a.tpl') ) gdzie wyświetlamy główny szablon widoku.
nospor
po pierwsze: zobacz w manualu co robi display, a dowiesz sie, ze display() wyswietla na ekran. jesli wiec najpierw robisz display na menu, to nie dziw sie, ze sie wyswietla. Jak chcesz otrzymasz stringa z menu to musisz uzyc fetch:
http://smarty.php.net/manual/en/api.fetch.php

po drugie: źle do tego podchodzisz. bardzo nie optymalnie. poco na kazdy blok robisz new smarty? wystarczy jeden obiek smartiego na wszystko. Kazde inne bloki powinienes zalatwiac szablonami lub tez pluginami, ktore oczywiscie sam napiszesz smile.gif
jastu
Faktycznie fetch. Co do pluginów - szukam i kombinuję jak widzisz, ( komfort tworzenia kosztem wydajności ? ).Pzdr
nospor
Cytat
komfort tworzenia kosztem wydajności ?
Jesli tworzenie kolejnych instancji smartiego nazywasz komfortem tworzenia.... smile.gif

edit:
u ciebie nie trzeba nawet pluginow. w glownym pliku szablonu robisz
Kod
{include file="plikzmenu.tpl"}

i juz
Zyx
"Komfort tworzenia" jest tylko taki, że każdy z tych obiektów ma osobną pamięć bloków. Ale reszta? Oba musisz ręcznie konfigurować, oba wchodzą sobie w paradę z rzeczami okołoszablonowymi. Jeśli kombinujesz, to z głową! smile.gif
Cysiaczek
url=http://www.martinfowler.com/eaaCatalog/twoStepView.html]http://www.martinfowler.com/eaaCatalog/twoStepView.html[/url]
Już kiedyś pisałem : >

1. Część pierwsza (logiczna) - strona www z układem logicznym elementów (np. menu, newsy, logo)
2. Część druga - mały widok, czyli pojednyńcza instancja smarty w twoim przypadku (albo jakoś tak - zależy od implementacji)

hello.tpl
  1. Hello {$user}


układ.tpl
  1. <html>
  2. <head></head>
  3. <body>
  4. <div>
  5. <?php $view->get('hello'); ?>
  6. </div>
  7. </body>
  8. </html>


// funckja w jakiejśc klasie view - uproszczona implementacja, bo nie wiem jak to dokładnie jest w smarty
  1. <?php
  2. function get($view){
  3. $obj=new Smarty();
  4. $obj->assign();
  5. $obj->display();
  6. }
  7. ?>


plusy:
+ Eleminuje konieczność zmian w wielu plikach, gdy dokonujemy zmiany w obrębie jednego templata.
+ Łatwość implementacji z wieloma silnikami (smarty, opt itp.), bo wystarczą odpowiednie wersje metody get() - dla każdego systemu szablonów jedna.

minusy:
- Wymaga to nieco pracy np. nad stworzenem klas kolekcji przechowujących dane, nazwy widoków.
- Nie jest oryginalnie przeznaczony (wzorzec) do stron www (z ajaxem jest już lepiej)
nospor
@cysiaczek ja dzis malo spalem, wiec moze moje pytanie jest banalnie idiotyczne, ale powiedz mi, czym rózni się Twoj sposób od tego:
Kod
{include file="plikzmenu.tpl"}

w pliku plikzmenu.tpl mamy menu i go wstawiamy na strony. Jak chcemy zmodyfikować menu to modyfikujemy tylko ten jeden plik, a nie latamy juz po szablonach stron. Podobnie by bylo jakbysmy korzystali z pluginow. Modyfikujemy plugin, a nie wszystkie strony.

Hmmm, może troche źle zadałem pytanie. Może nie czym sie rózni, ale w czym jest lepszy. Sam nie wiem, poprosze ładnie o wyjaśnienia smile.gif
Cysiaczek
@nospor - różnica jes faktycznie niewielka, jeśli patrzysz na wszystko od strony przykładu, który podałem. Nie jestem bez winy - podalem mylący przykład, co pewnie wynika również z mojego zaspania laugh.gif

Ideą nie jest tu includowanie plików szablonów, tylko rezulatatów wykonania akcji . Rezultatem może być widok o nazwie 'hello.tpl', ale również 'error.tpl'. Zatem prawidłowe odwołanie przez metodę get() powinno żądać rezultatu.

np.

Akcja - wyybiea sobie templatke z zeleżności od $ok
  1. <?php
  2. function sayHello(){
  3. $ok=$this->params->post->user
  4. if ($ok){
  5. $this->template='hello.tpl';
  6. }
  7. else{
  8. $this->template='error.tpl';
  9. }
  10. }
  11. ?>


W widoku (w jego częsci pierwsze - logicznej) odowłujemy się poprzez:
  1. <?php
  2. $view->get('sayHello');
  3. ?>


Oczywiście wiele zależy od implementacji warstwy prezentacyjnej.
W czym moim zdaniem jeszcze jest lepsze? Ano. Tak jak wspomniałem - można w banalny sposób użyć kilku róznych systemów szablonów, co jest nieosiiągalne poprzez
  1. {include file="plikzmenu.tpl"}

Nie jest, bo tu z założenia mamy Smarty

Natomiast popatrz na taką prostą modyfikację akcji sayHello()

  1. <?php
  2. function sayHello(){
  3. $ok=$this->params->session->status; //status zalogowania
  4. if ($ok){
  5. $this->setTemplate('hello.tpl', 'smarty'); // dla tego szablonu użyj silnika smarty
  6. }
  7. else{
  8. $this->setTemplate('error.tpl', 'php'); // dla tego użyj tylko php
  9. }
  10.  
  11. $this->data->user=$this->params->session->user; // string - nick usera
  12. }
  13. ?>


I teraz:
hello.tpl - renderowany przez smarty
  1. Cześć {$user}


error.tpl - renderowany przez PHP używające zwykłego include()
  1. Wystąpił błąd - brak użytkownika <?php print $user; ?>


Przykład ten dalej jest obarczony wieloma błędami. np. wybór templatki w akcji jest złym rozwiązaniem.W prawdziwym systemie lepiej odseparować nawet to.
Ja to robię w pliku XML
<view engine="smarty">nazwa_pliku</view>

Wszystkie te operacje powinny być dla użytkownika frameworka przezroczyste. Za pomocą prostych tagów, czy innej konfiguracji powinien wybrać sobie silnik renderowania i po prostu pisać kod. Resztę robi system.

Tak wygląda przykładowa struktura plików, gdzie katalogi reprezentują akcje a plikiw w katalogach to dostępne szablony.
Obrazek

Jednej rzeczy ciągle jeszcze nie rozwiązałem - tzw. skórek - mam pomysły, ale nie jestem do nich przekonany.

uff : )

Pozdrawiam
nospor
No dobra, teraz widzę roznice smile.gif

Czy jest to sposob lepszy? Hmmm, zależy co kto lubi.
Mówisz, ze mozna stosować rózne szablony? Ja ci mowie: a po co mieszac rozne szablony? Jak uzywasz smarty to uzywaj smarty, jak inny to inny. Tylko zamet mieszanka wprowadza. Mowisz ze szablonem moze byc php. Ja mowie ze wiadomosci co pokazales mozna przekazac w inny sposob i wcale nie gorszy.
Wybor templatki w zaleznosci od rezultatu akcji tez mozna robic o sprytniejszymi sposobami, bez koniecznosci implementacji tego mechanizmu.

Nie zrozum mnie źle. Kazdy uzywa to co lubi. Byc moze Twoje rozwiązanie jest fajne, optymalne, praktyczne. Mi osobiscie sie nie podoba, ale ja jestem czlowiek stary, przyzwyczajony do pewnych rozwiązan i trudno mi sie do nowosci przekonac winksmiley.jpg

ps: Dzieki za dokladniejsze wyjasnienie istoty sprawy smile.gif
Cysiaczek
@nospor - Zgadzam się, z Tobą, gdy mówisz "kto co lubi" : >
Doprecyzuję jednak.
Cytat
Mówisz, ze mozna stosować rózne szablony? Ja ci mowie: a po co mieszac rozne szablony? Jak uzywasz smarty to uzywaj smarty, jak inny to inny. Tylko zamet mieszanka wprowadza.


Pokazałem jedynie możliwości ekstremalne : >
Chodzi o samo przezroczyste wsparcie dla silników szablonów (taki interfejs), nie o radosne pisanie jedengo templatu tak, a drugiego inaczej.

Pozdrawiam.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.