Отново ми зададоха въпроса "Ползваш ли Smarty?" Еми НЕ! Знам, че можел да кешира. Знам, че разделял логиката от визуализацията. Знам, че бил най-якото нещо. Но за човек като мен, който от години не прави лейаути, а работи в екип с дизайнери, това би се оказало огромна пречка за работата ми. Тъкмо колегата Пешо Илиев се научи да разпознава PHP таговете и командите, и сега ако му сложа Smarty дали няма да гледа като тръба? Ще! :) От друга страна, за чий кеф да товаря сървъра да зарежда веднъж целият engine с всичките му конфигурационни файлове и т.н., веднъж темплейтите, веднъж логиката на сайта, веднъж да драсне по файловата система за да кешира, и чак тогава да извади резултата от страницата. Ами ако сайтът е наистина голям и се радва на три-четирицифрено число онлайн потребители, дали това няма да е пътят към Голгота на бедното сървърче. Нека не забравяме, че на този сървър не лежат само Apache-то и MySQL-а, а и на него има накичени хиляди сайтове.
Изобщо, с какво би ми помогнал един templating engine? Щял да ми раздели логиката от визуализацията. Че аз мога и сам, посредством разделяне на output-а на елементи и тяхното include(иране). Работата е изключително проста и нямам нужда от огромен енджин, за да го свърши вместо мен.
Изобщо, с какво би ми помогнал един templating engine? Щял да ми раздели логиката от визуализацията. Че аз мога и сам, посредством разделяне на output-а на елементи и тяхното include(иране). Работата е изключително проста и нямам нужда от огромен енджин, за да го свърши вместо мен.
- Правя си един файл с темплейта на лейаута.
- Слагам вътре div-овете и всеки един динамичен елемент от тях се изтрива.
- Пише се CSS-а.
- Подлага се отдолу един PHP файл, който хвърля необходимата тежка заявка към MySQL-а, пресмята всичко, if else, if else, foreach, switch и т.н., докато всичко не се набута по необходимите променливи, които да държат съдържанието.
- Темплейтите на отделните динамични елементи генерират оптимизираният аутпут, посредством <?=$page->title?> например и т.н. и т.н.
- include_once 'footer.php';
И до там. Защо ми е Smarty? Заради кеша? PHP си има output buffering, който отлично върши същата работа. Още повече, ако не подлагам мегабайтовия templating engine, няма да ми се налага да кеширам толкова много.
И за да подплътя твърденията си още повече, бих ви препоръчал да прочетете тази статия, защото човекът го е обяснил повече от перфектно. Аз само изложих основните моменти на български език. Разделянето на output-а от логиката не е нещо, което се изисква само, за да може да се интегрира даден templating engine. Елементарната хигиена на кода го изисква.
И за да подплътя твърденията си още повече, бих ви препоръчал да прочетете тази статия, защото човекът го е обяснил повече от перфектно. Аз само изложих основните моменти на български език. Разделянето на output-а от логиката не е нещо, което се изисква само, за да може да се интегрира даден templating engine. Елементарната хигиена на кода го изисква.
15 comments:
И още една статия по темата, с практическа насоченост:
http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html
Не искам да прекратявам ентусиязма ви, но искам да е ясно на хората, които ще четат този блог в бъдеще. Мисля, че писането на блог е доста отговорна задача и трябва човек преди да го направи да прочете и проучи това онова.
На въпроса: "За какво ми е смарти?" Отговора: "Да разделиш визуалната HTML и PHP."
Идея: "Смарти кешира".
Коментар: "Вземи и разбери, че смарти компилира!"
Мисля, че самата дума 'компилира' вече обезсмисля половината от блога, за другата половина ако се постарае един човек да направи хубав темплейт енджин използвайки смарти и аджакс, то той би бил много полезен.
Ето една трудна задача: Multilanguage.
Лесно решение: Смарти.
Относно линковете за НЕ-НА-ФРЕЙМУЪРКОВЕТЕ, те са доста остарели.
Относно мнението ти, то е доста смехотворно :)
Идея: Смарти компилира!
Факт: Вземи и разбери, че това товари. И всичките му опити да прикрие товаренето си, товарят още повече. Пречи на евентуалното доразвиване на сайта. И реално погледнато не прави нищо друго, освен да представя леко опростен и твърде различен синтакс за добре познати неща. Добрият кодер ги пише тези неща рутинно и спечеленото време в написването едва ли е съизмеримо с цялото време по дизайна на архитектурата, обмислянето и тестването. И в крайна сметка един такъв темплейтинг енджин е още един огромен компонент, който може да има бъгове, дупки и за който трябва да се пишат пачове и уъркъраунди. Нещо, за което няма време в един динамичен пазар.
Всеки да ползва каквото му е удобно - това е моята идея за робата. Ако работите в по-голям екип трябва да се направи известен компромис за да може да е максимално удобно (до колкото е възможно) на всички в екипа.
Искам да вмъкна няколко детайла, без да си опитвам да оспорвам нечие мнение. Smarty кешира, компилира и прави още мноого неща :)
Компилирането -- то се използва, за да може опростения smarty синтаксис, който у по-удобен за технически неграмотните, да се транслира в PHP синтаксис. Това последното е точно това коети ти използваш, нали ? Това наистина е най-бързо понеже няма overhead, защото компилирания файл просто се include-ва. Самия компилатор се пуска само първия път, за да направи компилирано копие, и след това няма overhead. Извинявам се ако повтарям неща които са вече извесни, но все пак останах с впечетлението че архитектурата на Smarty не е толкова широко позната.
Smarty има още много плюсове, като кеширането е само един от тях. Има възможност за добавяне на много различна допълнителна функционалност на plugin принцип, чрез които работата с HTML за хората с малко опит става още по-лесна. Има много нива на които може да включиш допълнителната функционалст: преди, по време и след компилирането, преди по време и след извеждането на данните, "регионално" изключване на кеширането за определени области на HTML кода и т.н. Друг удобен feature е че може да си слагате шаблоните където искате - на файловата система, в база данни, в LDAP и т.н.
Нещо което искам да оспоря е че "(Smarty)...Пречи на евентуалното доразвиване на сайта...". Мога да кажа само, че практиката е доказала обратното (поне за пред мен).
За бъговете и патчовете - Smarty има голям `user database` (много хора го ползват), и много бързо се оправят всякакви проблеми с него. Това не важи обачи за всички template-engines :) Има такива дето ги е правил някой интернет-ентусиаст, и ако излезе някой бъг, трабва или неупределено много време да чакате за пач, или да си го направите сами. Както вече казах, това не е така със Smarty :)
good to know :) А би ли ми казал само Smarty как разбира, че един файл е променен или пък нещо друго е подложено отдолу? И този процес дали няма да натовари твърде много един сайт с габаритите на dir.bg примерно. (Не оставай с впечатление, че се заяждам. Просто провокирам малко повече аргументация в другите мнения, за да ми стане по-ясно, а ти си на прав път.)
Включва се специална опция, която следи за промени. Тя наистина дава overhead, но пък за сметка на това се ползва само докато се разработва даден проект. Когато този проект се пусне `live`, тази опция се изключва, точно както се изключват и всички други неща свързани с debug, trace и т.н.
Също така по време на разработване и кеша е изключен, само че обратната причина -- да не пречи на разработчиците. Има още неща, ама сега ни ми се пише :) Да не говоря че повече от тях не знам как да ги обесня на български :)
Ами против Smarty съм. Какво му е трудното на задачата "Multilanguage"
като без Смарти може да се реализира по един милион начина...плюс това, ако искаш да отделяш HTML и CSS от PHP, можеш спокойно да си го направиш и без Смарти.. Колкото до кеширането - то също може да бъде реализирано лесно, а и PEAR пакета също предлага кеширане...
Изобщо Смарти може само да забави работата на един разработчик според мен.
//EWEB PLD
Смарти проверява последна модификация на темплейтите, които се използват, при зареждането им и ако е по-ново от това на компилираните такива се прекомпилират, иначе просто се инклудват.
А би ли ми описал един примерен алгоритъм за това как става тая проверка. Щото аз си го представям като - компилирай некомпилираното и виж дали съвпадат. Или ако не е толкова грубо е нещо подобно. И идеята ми е именно - за чий чеп ти трябва тая проверка, като в крайна сметка стигаме тъй или иначе до инклуда?
smarty не натоварва сървъра, само при първото пускане когато темплейтите не са компилирани. А ако се пусне кеширането на темплейтите става почти като статичен сайт. Затова доводите ти са неубедителни. Големи портали използват темплейт енджини. На старата ми работа Екипа от дизайнери нямаха проблем да работят нормално с patTemplate, а и Smarty, всичко е до нагласата, единия дизайнер даже едитваше php-тата за нещо просто като ставаше дума. Относно frameworks - използвайте ги! Нещо което може да ти спести дни да не казвам седмици писане на код е добре дошло. А и с тези крайни срокове си е доста добре а пък и няма да откривате топлата вода, защото хората от години работят по тези фреймуърци и темплейт енджини също и са на Enterprise ниво.
Здравей,
най-пресните ми коментари по темата може да намериш тук:
http://kaloyan.info/blog/220/evangelizing-smarty/
включително отговор на коментара от `July 24, 2007 9:08 AM`
Хех, нещо весело ... по-рано беше писал:
good to know :) А би ли ми казал само Smarty как разбира, че един файл е променен или пък нещо друго е подложено отдолу? И този процес дали няма да натовари твърде много един сайт с габаритите на dir.bg примерно.
Сега върви на:
http://banks.dir.bg/2007/07/26/news1942209_new.html
На дъното на страницата ще откриеш следното:
Warning: Smarty error: file:/var/www/new/support/banki.dir.bg/blocks/217_cat_last_3_news.html is not readable in /usr/share/php/smarty/libs/Smarty.class.php on line 1095 Warning: _include(): Failed opening '' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /usr/share/php/smarty/libs/Smarty.class.php on line 1925
Значи Дир-а все пак ползва Smarty (въпреки че може да е само на този сайт за банките), но явно не по най-правилния начин, след като виждаме издънки като тази :)
Здравйете, първо да поясня - не съм skilled php програмист. Ползвам smarty от поне 4-5 години и немога да си представя да не го ползвам.
Ползвам го защото съм свикнал и ми върши чудесна работа. Досега в екип не съм работил и нямам опит. Всичко за мен е супер лесно със смарти. В php файла слагам всички заявки към базите данни и т.н. а в темплейта красивичко бухам променливите,цикли и т.н.
Наскоро потребителите на скромният ми сайт станаха 1000 на ден, а горкото виртуално сървърче за 35лв. на месец със 128Мб рам почна да губи разсъдък. Започнах да оптимизирам сайта. Оправих базите данни и вече не са по некадърния начин - всичко в една таблица, разделени са в отделни таблици с примари кей и индекси. Махнах PEAR DB и ползвам чисто php за връзките с базата данни. Тези промени намалиха драстично времето за генериране на страница. (особенно махането на PEAR DB)
До тук нищо общо със smarty.
Сега вече исках да оптимизирам и смарти. Имам пуснато кеширане, остана да сложа и eaccelerator за да е пълна картинката. С леки модификации, подкарах smarty.cache.handler за еaccelerator и сега всичко се кешира не на диска (напр. /cache) а в shared memory на сървъра, което за моите нужди е просто идеално.
Сложил съм Benchmark на сайта и ето примерни времена на някоя от моите страници:
0,25 сек. - с включена опция "force-compile"
0.08 сек. - кеширано
0.008 сек. - повторно кликам. (тук може би вече се намесва еAcceleratora)
(тези времена са за локалния ми сървър, който е по-мощен от виртуалня на който е сайта.)
Сега съм в дълбок размисъл има ли смисъл и мога ли да се справя да направя сайта си без смарти. Дали ще е по-бърз и дали няма да ми е много по-трудно?
Самата идея, че ще трябва да смесвам php и html ме изнервя. В benchmarka съм сложил разделения и мога да видя колко е натоварването причинено от смарти и то е доста (0,2 сек.)само когато трябва да се компилира с опцията force_compile, която обаче е изключена в реалният сайт. Иначе пренатоварването е пренебрежимо малко, когато е кеширано (0,005 сек.).
Ще ми се да опитам да направя всичко с обикновен php, за да имам реална представа за т.н. пренатоварване. На този етап обаче, съм доволен и съм свикнал със смарти.
Струва ми се много по-трудно да се направи без смарти, може би защото не съм опитен програмист :) Надявам се не съм ви отегчил с дългият си пост.
Ами прочети малко за MVC във Wikipedia и ще видиш как можеш да си разделяш html-а от PHP-то и без Smarty. Обектно ориентираното програмиране също ще ти даде много предимства. За съжаление нямам време сега да ти намеря подходящи линкове :( Напомни, в случай, че забравя.
Здравейте,
моето мнение е същото, като това на автора на блога. По принцип е доста излишно да се ползва Смарти. Има няколко неща които са удобни, но чак да е нещо гениално...
Разделянето на логиката от дизайна може да стане по същия начин както става чрез Смарти, но вместо да се позват конструкции от вида на {$variable} то може да се замени с конструкция
Конструкцията:
{foreach name='for1' from='MyList'}
...
{endforeach}
с
Някак нещата са доста идентични, но само се налага да разучаваш допълнителния синтаксис на Смарти. А ако някой мисли, че е някаква безумна сложнотия това да се позва многоезичната система - ами просто по същия начин зареждаш съответния фай, но да кажем с функцията parse_ini_file.
Другото което е направено в смарти - има някакви модификатори на изхода от сорта на големи букви, малки букви и разни такива - е за всичко това си има функция в PHP, а ако някокой толкоз държи, то може да си направи своя tpl_output($var, $func_list)
Обикновенно за програмиста няма никакво значение това как ще извежда резултата, стига да си е създал подходяща структура на сайта.
А когато някой говори за framework(работна рамка), трябва да знае, че това е съвсем друго понятие!
Post a Comment