Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [PHP]szablon z pliku php
Forum PHP.pl > Inne > Oceny
sazian
14.04.2009, 16:24:03
wpadłem na pewien sposób tworzenia szablonów i chciałbym wiedzieć co o tym myślicie smile.gif
oczywiście to co tu prezentuję to wersja "robocza" tylko taki zarys smile.gif

plik główny
[PHP] pobierz, plaintext 
  1. <?php
  2. class tpl {
  3.     public $strona;
  4.     public function __construct($file,$parm=array()){
  5. foreach($parm as $key =>$value)
  6. $$key=$value;
  7. include('template/'.$file.'.php');
  8. $this->strona= $result;
  9.     }
  10. }
  11. $tpl = new tpl('head',array('tytul'=>'to jest typyl strony z szablonu','tresc'=>'a to jest tresc strony z szablonu'));
  12. echo $tpl->strona;
  13. ?>
[PHP] pobierz, plaintext
szablon (template/head.php)
[PHP] pobierz, plaintext 
  1. <?php
  2. $result= <<<HTML
  3. <html>
  4. <head>
  5.  
  6. <title> $tytul </title>
  7. </head>
  8.  
  9.     <body>
  10.   $tresc
  11.     </body>
  12.  
  13. </html>
  14. HTML;
  15.  
  16. ?>
[PHP] pobierz, plaintext
mam nadzieję że wszystko jest jasne
Moli
14.04.2009, 17:31:19
Hmmm a po co to ? Strasznie tandetny pomysl, strasznie bedzie wygląda plik szablonu (o ile można to nazwać szablonem).
Zyx
14.04.2009, 17:44:48
Ja też wpadłem na pewien pomysł tworzenia szablonów. Mianowicie po wstawieniu każdej zmiennej tekst szablonu byłby wysyłany na serwer w Mozambiku zakodowany w base64, tam byłby odkodowywany i wysyłany z powrotem. I też chciałbym wiedzieć, co o tym myślicie.

sazian -> to, że coś jest wykonalne, nie znaczy, że powinno się to realizować. Wybacz, ale głupszego algorytmu przetwarzania szablonów nie widziałem. Przyjrzyj się uważnie, co ty tam tak naprawdę robisz; mi to wygląda na zabawy kodem na oślep.
sazian
14.04.2009, 18:05:53
w założeniach miał to być jak najprostszy "system szablonów" do własnego użytku nie dający żadnych "dodatkowych" możliwości a jedynie oddzielający kod php od HTML
korzystanie z szablonów typu smary(tak wiem już się go nie stosuje) czy opt powoduje wywoływanie całej masy dodatkowych operacji co wydłuża czas ładowania strony
natomiast łączenie php z HTML'em sprawia że kod jest mało czytelny

więc szukałem jak najprostszego sposobu na rozdzielenie php i HTML'a i tak "urodziło się to" smile.gif
l0ud
14.04.2009, 18:32:47
Twój kod nie nada się do niczego winksmiley.jpg - nie wstawisz pętli, warunków itp. Jak chcesz w sposób prosty do bólu oddzielić wygląd, możesz zrealizować to w mniej-więcej taki sposób:

views.php
[PHP] pobierz, plaintext 
  1. <?php
  2.  
  3. class view {
  4.  
  5.     private $viewName;
  6.     private $contents = array();
  7.     
  8.     public function __construct($viewName) {
  9.         //można w konstruktorze przekazać też np. instancję klasy języka, konfiguracji (do wykorzystania globalnie w szablonie)
  10.         if (file_exists('sciezkadofolderuszablonow/'.$viewName.'.php') === false)
  11.             throw new Exception('Could not load view, file not exists: '.$viewName);
  12.         $this->viewName = $viewName;
  13.     }
  14.     
  15.     public function __get($name) {
  16.         if (isset($this->contents[$name]))
  17.             return $this->contents[$name];
  18.         else return null;
  19.     }
  20.     
  21.     public function __set($name, $value) {
  22.         $this->contents[$name] = $value;
  23.     }
  24.     
  25.     public function render() {
  26.         if (!include('sciezkadofolderuszablonow/'.$this->viewName.'.php'))
  27.             throw new Exception('Could not load view: '.$this->viewName,3);
  28.     }
  29.     
  30.     public function __toString() {
  31.         ob_start();
  32.         $this->render();
  33.         $output = ob_get_contents();
  34.         ob_end_clean();
  35.         return $output;
  36.     }
  37.     
  38.     //można porobić jakieś ułatwienia
  39.     
  40.     public function img($name) {
  41.         return 'ścieżkadofolderuimg/'.$name;
  42.     }
  43.     
  44.     public function js($name) {
  45.         return 'ścieżkadofolderujs/'.$name.'.js';
  46.     }
  47.     
  48.     public function css($name) {
  49.         return 'ścieżkadofolderucss/'.$name.'.css';
  50.     }
  51. }
  52.  
  53. ?>
[PHP] pobierz, plaintext


przyklad.php
[PHP] pobierz, plaintext 
  1. <?php
  2. require('views.php');
  3.  
  4. $szablon_glowny = new view('glowny');
  5. $szablon_glowny->logo = new view('logo');
  6. $szablon_glowny->logo->tekst = 'Tresc w logo itd.';
  7.  
  8. $szablon_glowny->render();
  9. //albo
  10. //echo $szablon_glowny;
  11. ?>
[PHP] pobierz, plaintext


sciezkadofolderuszablonow/glowny.php
[PHP] pobierz, plaintext 
  1. To jest szablon glowny. Moze byc tu kod html i kod php (ale odpowiedzialny tylko za wyswietlanie)
  2.  
  3. <?php echo $this->logo; ?>
[PHP] pobierz, plaintext

sciezkadofolderuszablonow/logo.php
[PHP] pobierz, plaintext 
  1. To jest szablon z logo. Tekst to: <?php echo $this->tekst; ?>
[PHP] pobierz, plaintext


Takie szablony mają jednak taką wadę, że łatwo w nich namieszać. Koniecznie trzeba przyjąć zasadę aby kod w szablonie był odpowiedzialny tylko za wygląd. Pobieranie jakichkolwiek danych to pomyłka. Skrypt który tworzy obiekt tego szablonu musi zająć się np. przekazaniem mu tablicy z wynikami, które już w szablonie możesz wyświetlić za pomocą pętli.
sazian
14.04.2009, 19:00:11
Cytat(l0ud @ 14.04.2009, 19:32:47 ) *
Twój kod nie nada się do niczego winksmiley.jpg - nie wstawisz pętli, warunków itp. Jak chcesz w sposób prosty do bólu oddzielić wygląd, możesz zrealizować to w mniej-więcej taki sposób:


wstawiłem smile.gif
[PHP] pobierz, plaintext 
  1. <?php 
  2. $result= <<<HTML
  3. <html>
  4. <head>
  5.  
  6. <title> $tytul </title>
  7. </head>
  8.  
  9.     <body>
  10.   $tresc
  11. HTML;
  12. for($i=0;$i<10;$i++){
  13.     $result.=<<<HTML
  14.     i=$i<br />
  15. HTML;
  16.     
  17. }
  18.   
  19. $result.=<<<HTML
  20.   
  21.     </body>
  22.  
  23. </html>
  24. HTML;
  25.  
  26.  
  27. ?>
[PHP] pobierz, plaintext

przecież to plik php więc ma pełną funkcjonalność php
co prawda dodawanie fętli czy instrukcji warunkowych jest nieco utrudnione przez konieczność dodawania $result.=
zrobiłem tak poniewarz chciałem mieć możliwość wczytania wyniku do zmiennej

edit:
a mógłby mi ktoś powiedzieć w czym jest lepsze <?php echo $this->tekst; ?> od mojego rozwiązania questionmark.gif oczywiście nie chodzi mi o odpowiedzi typu bo to głupi pomysł tylko o jakieś wyjaśnienie dlaczego to głupi pomysł
guitarnet.pl
14.04.2009, 19:08:49
http://www.massassi.com/php/articles/template_engines/
l0ud
14.04.2009, 20:03:26
sazian, zrobiłeś jedną pętlę i już wygląda paskudnie. tongue.gif A teraz spróbuj zagnieździć jeszcze jedną i dodać kilka warunków. Moim sposobem też masz możliwość wczytania zawartości pliku do zmiennej - tylko bez cudowania. I z tego co widzę kolega guitarnet.pl też zaproponował podobne rozwiązanie.
sazian
14.04.2009, 20:08:37
no fakt wygląda paskudnie tongue.gif ale działa biggrin.gif
teraz gdy to dokładniej przemyślałem muszę przyznać wam rację to nie był najlepszy pomysł

pytam czysto teoretycznie:
poza tym że paskudnie wygląda macie jakieś zastrzeżenia od samego sposobu questionmark.gif
guitarnet.pl
14.04.2009, 20:17:46
@l0ud
kolega guitarnet.pl nie nazywa sie Brian Lozier, czytaj artykul do konca zanim sie wypowiesz..

akurat-przyklad ktory podalem posluzyl mi do napisania wlasnego systemu szablonow w duzym stopniu opartym na tym wlasnie rozwiazaniu
zanim zabralem sie za kodowanie testowalem dosc dlugo czasy wykonywania roznych skryptow szablonow i roznych rozwiazan od momentu przypisania zmiennych do wyrenderowania gotowego htmla (bez udzialu cache) oraz zuzycie pamieci takiego skryptu, dodatkowo cale rozwiazanie musialo dzialac w srodowisku mvc a rozwiazanie mialo skracac do minimum czas pomiedzy standardowymi operacjami w php bez wdrazania dodatkowych procedur czy koniecznosci prekompilacji szablonow, alternatywa?

nie wiem co dokladnie cie razi w tamtym rozwiazaniu z artykulu, nie podales zadnych przykladow tylko ogolnikowe zdanie, zadnych alterntywnych rozwiazan wiec ciezko sie ustosunkowac do twojej "opinii", wlasciwie nie da sie ustosunkowac do czegokolwiek w twojej wypowiedzi?
l0ud
14.04.2009, 20:54:26
Oj, chyba nie zrozumiałeś mojego posta sad.gif

Dając link do jakiegoś rozwiązania, automatycznie je sugerujesz. Nie musisz być przecież jego autorem winksmiley.jpg Poza tym stwierdziłem, że ten sposób jest bardzo podobny do mojego, który uważam za słuszny - na czymś podobnym oparłem już kilka stron.
guitarnet.pl
14.04.2009, 21:01:27
zrozumialem ze "kolega guitarnet.pl" zaproponowal podobne rozwiazanie jak kolega sazian, ktore oczywiscie odbiega od "norm" smile.gif
ok my bad, pozno juz jest za dlugo przed monitorem... smile.gif
Zyx
15.04.2009, 14:03:22
Tak, są zastrzeżenia. Prosiłem, byś się przyjrzał kodowi, najwidoczniej nie przyjrzałeś się, bo dość bezkrytycznie podchodzisz do parsowania tego samego szablonu co najmniej kilkanaście razy, zanim ostatecznie wygenerujesz rezultat. Dodaj sobie do szablonu linijkę $i++ i na końcu ją wyświetl, to zobaczysz (przynajmniej w teorii), co mam na myśli... Chciałeś skrócić czas generowania strony, a tymczasem "ten przeładowany" Smarty czy OPT bez problemu pobiją Twój kod przy pierwszym lepszym szablonie z dokładnością do rozmiaru ładowanego kodu.

Twoja wiedza o działaniu systemów szablonów bazuje w większości na mitach niemających pokrycia w rzeczywistości. Każdy system szablonów potrzebuje jakiegoś interfejsu programistycznego, większość dodaje także dedykowany język do tworzenia szablonów. Mimo tego, ze względów wydajnościowych są one kompilowane do kodu PHP i jedyny dodatkowy narzut czasowy to dwie operacje dyskowe na porównanie czasów ostatniej modyfikacji, by sprawdzić, czy plik źródłowy nie został zmieniony. Na dokładkę na serwerze produkcyjnym najczęściej można to bezproblemowo wyłączyć. Poza tym - ZERO! Aby pracować, OPT potrzebuje wczytać zaledwie niecałe 25 KB kodu + ew. 12 KB źródeł funkcji + 15 KB jądra (5 plików) bez względu na to, jak bardzo zaawansowane możliwości wykorzystujesz, gdyż i tak podczas kompilacji są one redukowane do najprostszego kodu PHP. Pozostałe 0,5 MB kodu przydaje się tylko podczas kompilacji i tak poza zajmowaniem odrobiny miejsca na dysku nie ma żadnego wpływu na wydajność. I gdzie tu masz "całą masę dodatkowych operacji"? Dla porównania, Zend_View, który także jest systemem szablonów bez względu na to, jak nazwą go autorzy, to 35 KB kodu robiącego prawie to samo + kod każdego helpera, jakiego użyjesz, nawet jeśli służy on po prostu do zrobienia pętli... tak naprawdę jedyne usprawnienie wydajności, jakie można uzyskać, to mniejsza objętość kodu do załadowania podczas uruchamiania skryptu i nic poza tym.
guitarnet.pl
15.04.2009, 15:49:32
twierdzisz ze 15kB skrypt nie moze zarezerwowac 50MB pamieci a 100kB skrypt 2MB?
raczej odnosilbym sie tu do czasu wykonywania skryptu i rozmiar pamieci rezerwowanej przez skrypt a nie objetosc kodu zrodlowego
Zyx
16.04.2009, 09:35:48
Bardzo dziwnych twierdzeń się doczytałeś. Czytaj to, co jest napisane, a nie dorabiasz jakieś dziwne teorie, bo nic takiego nie napisałem. Po prostu wiem, jak działają systemy szablonów i w tych wydajnych żadna tego typu alokacja nie zachodzi sama z siebie, bo niby co tam by miało być trzymane? Cały "algorytm", jaki jest tam wykonywany to:

Kod
$dane['foo'] = 'tralala';
$dane['bar'] = 'xyz';
// itd...

require('./templates/szablon.php');


A w systemach z dodatkowym językiem require jest dodatkowo obudowany jednym ifem, który sprawdza czy szablon nie uległ modyfikacji i w razie potrzeby dopiero ładuje kompilator, który może już alokować dużo pamięci i mieć skomplikowane algorytmy. Oczywiście, jest kwestia obsługi błędów, sposobu jej realizacji, ale tu też nie ma specjalnie skomplikowanych rzeczy - trochę dodatkowych warunków i ewentualnie doładowywanie i wykonywanie bardziej skomplikowanego kodu, gdy wystąpi błąd. Kombinowanie z innym rozstawieniem warunków, szukanie podwójnie wykonywanych testów... - to już są małe detale. De facto wszystko redukuje się do stopnia złożoności interfejsu i właśnie objętości podstawowego kodu, który trzeba załadować. PHP też potrzebuje czasu na jego przeparsowanie, a jeśli podczas wykonywania nie ma właściwie nic, co mogłoby kod spowalniać, czas parsowania zaczyna być decydujący. I żeby nie było, kiedyś, bawiąc się w benchmarki, dołączyłem do nich dla zabawy minimalistyczny system szablonów, ale z identyczną zasadą działania, upakowany na paru kilobajtach kodu. I różnica na jego korzyść była wyraźnie widoczna...

Tak więc nie ma tu żadnych herezji - za bardzo uogólniłeś, by się do czegoś przyczepić. Te "wydajne" systemy szablonów mają taką, a nie inną specyfikę, że za bardzo tam nie ma czego przyspieszać i właściwie wydajność sprowadza się do tego, ile rzeczy musi być załadowanych i z jakich elementów PHP skrypt korzysta... a na złość cioci mnóstwo osób twierdzi, że to właśnie dzięki wywaleniu pętli, warunków itd. system szablonów staje się szybszy.
guitarnet.pl
16.04.2009, 13:35:05
Cytat
tak naprawdę jedyne usprawnienie wydajności, jakie można uzyskać, to mniejsza objętość kodu do załadowania podczas uruchamiania skryptu i nic poza tym.


czy smarty czy zend, czy inne paskudztwo czy tez prywatny system to parsowanie/renderowanie zajmuje podobana jednostke czasu, bo dzieki autoload z 1MB zrodla czy 60kB zrodla jadowane jest tylko to co potrzeba np 300 bajtow wiec ilosc kodu jest tu bez znaczenia moim zdaniem bo i tak nie jest ladowany
Cysiaczek
16.04.2009, 13:47:46
Panowie - to nie miejsce na dyskusje. Są od tego tematy, ot chociażby: Temat: Widok_renderowanie_widoku
Kildyt
16.04.2009, 21:01:15
Kombinujecie jak koń pod górkę.
IMHO zwykły include do php-owego pliku jest najlepszym rozwiązaniem.
Takie klasy to tylko zbędne utrudnianie sobie życia i marnowanie cennego czasu.

Nie jestem specjalistą w obiektowym programowaniu, ale jaki jest sens deklarowania, że konstruktor jest funkcją publiczną?
Pisanie klasy dla jednej funkcji też nie jest zbyt rozważne.
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.