Witam, chciałbym napisać stronę na szablonach (Template).
Z tego co przeglądnąłem gotowe rozwiązania, żadne nie przekonuje mnie, że mógłbym za jego pomocą napisać stronę, którą chciałbym "przepisać", przełożyć na Template.

Skłania mnie to stworzenia własnego systemu template i nie korzystania z żadnych gotowców (Smarty i inne) - "Mój szablon od zera".

Wobec powyższego chciałbym prosić tych, którzy znają problematykę Template o informacje i wskazówki:
- gdzie można znaleźć informacje jak zbudować taki Template od podstaw,
- jak skonstruować strukturę katalogów,
- template powinien stwarzać możliwości dla strony wielojęzycznej, o wielu stylach itp.
- byłoby dobrze, aby główne elementy były jednak już opracowane, mam tu na myśli gotową klase template przetwarzajacą kod i inne...

Pytam też o gotowe rozwiązania, których nie znam, ale krótkie rozpoznanie utwierdziło mnie, że takie gotowce znacznie przyspieszają proces tworzenia, ale i ograniczają możliwości.

Zapytanie kieruję do strony: Rekreacja i Turystyka Wędkarska, którą to chcę przełożyc na Template.

Dziękuje za każdą wiadomość

A czy na pewno jest to dobre rozwiązanie...? A zainteresowałeś się klasą OPT? http://artykuly.zyxist.com/czytaj.php/opt_w_praktyce

Tego też próbuje się dowiedzieć oraz jak zrobić, aby było naprawdę dobre.



Tak, przeglądałem w skrócie jakieś dwa miesiące temu, kiedy zdecydowałem się pisać własny Template.
Kolega proponował, abym zapoznał się z ZendFramework ponieważ do tych celów jest dobry (najlepszy)?

erix, mam pytanie szczególnie jeśli znasz problematykę Template.
- czy używająć gotowych rozwiązań, jak OPT będę mógł napisać taką samą stronę jak podana wyżej,
taką samą (identycznie wyglądającą), ale lepszą (o większych możliwościach użytkowych)
- czy gotowce nie ograniczają możliwości projektowych

W zasadzie to od dwóch misięcy piszę mój Template, nie dla ogólnego zastosowania, ale dla podanej strony.
I jest już gotowy, ale nie spełnia moich oczekiwań, wszystkiego jest nadmiar, za dużo katalogów, za dużo plików...
Jeśli dam komuś do zrobienia nowy styl dla strony zakopie się w labiryncie plików. Sam się boję, że kiedy po miesiącu przerwy usiądę do Template nie będę wiedział gdzie co jest.
Po krótce stworzyłem monstrum , a po co robić monstrum dla nieco większej strony?

Gdy zaczynałem programować w PHP, również tworzyłem własne systemy szablonów od zera, które oferowały niedużą funkcjonalność i nadawały się bardziej do prostych stronek. Fakt, były szybsze od gotowych rozwiązań ze względu na małą objętość (kilka, góra kilkanaście kilobajtów całość), ale miałem też wtedy małe wymagania, np. w obsłudze formularzy zadowalało mnie okienko "Nieprawidłowe dane, spróbuj ponownie" . Także wtedy wychodziłem z założenia, że gotowce to zbyt duże kobyły, ale później zacząłem oskryptowywać stronki bardziej zawodowo i okazało się, że tam to właśnie proste systemy szablonów generują ograniczenia, których pokonywanie zabiera zbyt dużo czasu. Znałem Smarty, jednocześnie w wyniku splotu różnych zdarzeń pracowałem już nad pierwszymi wersjami OPT i postanowiłem spostrzeżenia przekuwać na pomysły i kod.

Jeśli nie chcesz w pewnym momencie znaleźć się w sytuacji, że potrzebujesz coś zrobić, a system szablonów Cię ogranicza (i nie daj Boże doprowadzić do wniosku, że lepiej było zostać przy PHP), biblioteka musi mieć odpowiednie możliwości. Jednak po paru latach prac nad OPT 1 i OPT 2 mogę powiedzieć, że już samo zaprojektowanie dobrego systemu szablonów nie jest rzeczą trywialną, a zaprogramowanie naszych pomysłów to zagadnienie na dłuższy czas. W dodatku może okazać się, że wyjdzie Ci coś o możliwościach niewiele mniejszych od Smarty'ego, ale jeszcze gorzej zrobione i tragicznie zoptymalizowane.

Krótki rzut oka na Twoją stronkę pozwolił mi już określić niektóre miejsca wymagające szeregu rozmaitych rozwiązań:
- Kalendarz - aby osiągnąć taki efekt, Twój system szablonów musi udostępniać operacje matematyczne i swobodę w konstruowaniu pętli, albo gotowy komponent ogólnego przeznaczenia.
- Galeria - aby tak poukładać zdjęcia, potrzebne Ci jest to, co wyżej.
- Stronicowanie - jeśli nie chcesz kopiować całych kilobajtów na kolejne podstrony wymagające stronicowania, potrzebujesz jakiegoś mechanizmu używania kodu w wielu miejscach.
- Formularze - jeśli zamierzasz robić jakiekolwiek inteligentne raportowanie błędów lub nawet uzupełnianie pól wartościami, przydałyby się instrukcje warunkowe. Jednak tutaj ponadto oprogramowanie pojedynczego pola to spory arsenał ifów, nawet w PHP, więc przydałoby się coś prostszego. A wnioskując, że chcesz korzystać z Zend Frameworka, pewnie się tym zainteresujesz prędzej czy później.
- Strona wielojęzyczna - jeśli nie chcesz się zajechać przy przenoszeniu komunikatów do systemu szablonów, biblioteka powinna zawierać wbudowane wsparcie.
- Mapa strony - nie wiem, jak głęboka jest struktura serwisu, ale potrzebujesz przynajmniej mechanizmu prostego zagnieżdżania pętli i obsługi relacji między poszczególnymi elementami, a w wersji extra - pełnego renderowania drzew.

W warstwie prezentacyjnej raczej nie ma skomplikowanych algorytmów, a te które są, można policzyć na palcach jednej ręki. Jednak w praktyce, aby się nie zawiesić, system szablonów de facto musi oferować nowy język programowania. Co więcej, aby z kolei nie klepać ogromnych ilości niepotrzebnego kodu, konieczne są mechanizmy jego ponownego wykorzystywania, a także upraszczające wiele typowych operacji - to jest pięta achillesowa wielu tzw. gotowców, tzn. albo coś takiego tam w ogóle nie występuje, albo jest potraktowane po macoszemu (Smarty!!!). Naprawdę, nie dziwię się, że wiele osób zniechęca się przez to do systemów szablonów i wraca do klepania warstwy prezentacyjnej w czystym PHP. Choć jest to język wybitnie niewygodny do takich zadań (nawet mimo iż teoretycznie był początkowo do tego celu tworzony - cóż, projektował go ktoś, kto o robieniu dobrych systemów szablonów nie miał pojęcia ), ale za to jest skalowalny. Tak więc mimo iż używanie obiektówki do wyświetlenia paru głupot to przegięcie do siódmej potęgi, ale istotne jest, że ta obiektówka ISTNIEJE, daje pewne możliwości, których wielu systemom szablonów brakuje, a które są potrzebne.

Tworząc system szablonów, projektujemy nowy język programowania, a wiele osób nie zdaje sobie nawet sprawy, że daje to fantastyczne możliwości manewru i szansę do zaimplementowania rozwiązań, które w PHP N-I-G-D-Y nie będą możliwe lub ich realizacja jest bardzo problematyczna nawet przy największych chęciach. Jednak aby skorzystać z tej szansy, trzeba po pierwsze mieć pomysł, po drugie czas i dalsze pomysły na zaimplementowanie tego. Skłaniałbym się zatem ku twierdzeniu, że właśnie takie robione na szybko systemy szablonów generują znacznie większe ograniczenia, a w pewnym momencie będą także wymagać znacznie większego czasu na pisanie samych szablonów.

Jeśli chodzi o możliwości, to sprawa jest dość banalna. Niektóre strony wykorzystują banalne rozwiązania, gdyż na stworzenie zaawansowanych potrzeba zbyt dużo czasu. Gdy jednak masz pod ręką gotowe do użycia i przetestowane rozwiązanie, okazuje się, że w tym samym czasie możesz osiągnąć znacznie więcej i nagle prosty serwis robi się bardziej rozbudowany. W przypadku systemów szablonów i frameworków widać to na przykładzie systemów obsługi formularzy i kontroli danych.

Poruszę jeszcze kwestię "monstrualności", "kobylastości" - wiesz, widziałem już kilka prostych systemów szablonów, które "monstrum" Smarty rozkładało wydajnościowo na łopatki zaraz po wejściu na ring . Sporo zależy od samego projektu i umiejętności programistycznych; jeśli te same rozwiązania zastosujesz do prostych systemów, oczywiście - uzyskasz przyrost wydajności, ale niekoniecznie wszyscy te rozwiązania znają i stosują. Pracuję już wiele lat nad systemami szablonów i ciągle uczę się czegoś nowego. Podam Ci kilka faktów:

Najpierw - objętość poszczególnych bibliotek:
1. OPT 1 - 162 KB
2. Smarty - 321 KB
3. OPT 2 - 630 KB

Jednak rozmiary nie odzwierciedlają wydajności, gdyż (uwaga: dane mocno uproszczone, gdyż w ogólności nie da się jednoznacznie powiedzieć, który z dwóch robiących to samo programów jest szybszy):
1. Kompilacja szablonów, czyli rzecz wykonywana raz na dłuuuuuuuuuuugi czas - Smarty, potem OPT 1, a niezły kawałek za nimi OPT 2.
2. Codzienne użytkowanie - OPT 1 przed Smarty'm, zaś niezależne wstępne benchmarki pokazują, że OPT 2 albo zachowuje czas z OPT 1, albo działa ciut szybciej.

Jak widać, rozmiar kodu ma się nijak do jego szybkości, a klucz leży w wydajności algorytmów, sposobu użycia operacji dyskowych i tego, co i kiedy jest ładowane. Przykładowo, jeśli nie kompilujemy szablonów, OPT 2 ładuje jedynie ok. 20-30 KB kodu, podobnie jak OPT 1. Analogicznie ma się sprawa z możliwościami - OPT 1 niby był dwa razy mniejszy, a miał sporo rzeczy, których w Smarty'm nie ma lub kiedyś się pojawią (parser leksykalny). Nie przeszkadza to także w istnieniu relacji odwrotnej; stary OPT miał uboższy zestaw funkcji. W OPT 2 natomiast prę ostro w kierunku deklaratywnego tworzenia szablonów, tj. mówisz, co chcesz mieć w szablonie i nie martwisz się w ogóle o implementację oraz optymalizację i stąd tak duża objętość kodu (do tego dochodzi wciąż ulepszany autorski parser XML-a).

Myślę, że odpowiedź Cię satysfakcjonuje i że udzieliłem odpowiedzi na wszystkie nurtujące Cię pytania. Pamiętaj, że sporą część tych informacji można bez trudu zastosować do innych rodzajów bibliotek i skryptów.

Tak też myślę, że dla celów zawodowych trzeba korzystać z gotowych rozwiązań. Co do prostych systemów generujących ograniczenia nie jestem przekonany, czasowe owszem (to ogromna ilość pracy, aby z niczego zrobić coś dobrego), ale nie ograniczenia projektowe (programowe), ponieważ taki system ograniczony jest "tylko" umiejętościami programisty.
Chyba trzeba być naprawdę mocnym, aby podjąć się takiego zadania, albo to drugie

Zadam proste pytanie:
Czy używająć gotowych rozwiązań, jak OPT będę mógł napisać taką samą stronę jak podana wyżej,
taką samą (identycznie wyglądającą, posiadającą takie same elementy, podstrony również te nie dostępne dla każdego użytkownika), ale lepszą?
Lepszą, ponieważ po to piszę ten Template, gdzie samo PHP nie wystarczy, wręcz powiedziałbym jest przestarzałe bez rozszerzeń jakie daje np. TPL. Przestarzałe hm..., nie wykorzystane.

Thank's Zyx

Taką samą zrobisz na pewno, a czy lepszą, to zależy od tego, jak wykorzystasz możliwości oferowane przez te narzędzia i co rozumiesz pod pojęciem "lepsza" . W każdym razie da się, a przy znajomości używanych narzędzi, nie jest to nawet takie trudne. Robiłem już jeden eksperyment praktyczny z nowym OPT i szkielet warstwy prezentacyjnej przygotowałem w kilkanaście minut, nie mając jeszcze żadnych informacji o strukturze skryptu, formatach danych itp. itd.

Z drugiej strony pamiętaj, że systemy szablonów stanowią coś w rodzaju "frameworka", tak samo jak czyste PHP. Aby pisało się w tym komfortowo, trzeba wypracować pewną metodykę i rozszerzyć je o zestawy funkcji/instrukcji/co tam jeszcze jest charakterystyczne dla Twoich skryptów. W Smarty'm i PHP bez tego pisze się koszmarnie, bo najmniejsza głupota wymaga od Ciebie zaklepania niewspółmiernej do zadania ilości kodu. W OPT jest z jednej strony lepiej, bo od strony szablonów wszystkie typowe rzeczy, jakie tylko przyszły mi do głowy, są już oprogramowane i zaprojektowane, ale tu z kolei przynajmniej część z nich wymaga, aby skrypt nauczył się je wykorzystywać (komponenty, bloki...). W planach mam stworzenie kompletnej platformy wraz z jak najlepszym wsparciem dla paru frameworków (ZF - mam prototyp, Symfony - jest gotowy port, ale do OPT 1, Kohana - jeden z użytkowników pracuje nad tym), ale to jeszcze trochę potrwa.