Вон у нас умники смарти в топку кидают, публично жгут на форуме. (Фашисты) Так как их СУГУБО ЛИЧНО ДЕЛО это реальность для всех. Код (Text): draak, это не невежество, это реальность. Кстати та статья неважная мне не понравилась, ну работаю я в студии - без смарти бы пропал просто напросто.
Между прочим про смарти я писал, а не simpson. И я за свои слова всегда отвечаю. А вас попрошу посдержаннее себя вести. Я про ваш мозг ничего не писал, а могу! Мне смарти не нравится. Не вижу никакого смысла использовать этого монстра. Хотя, для тех, кто любит извращения в жёсткой форме, смарти - самое оно! При этом я не заявляю, что сам смарти, как программный продукт, выполнен на низком уровне, смарти - качественный продукт! А его использование - это личное дело разработчика и лично я нашёл для себя другое гибкое, быстрое и надёжное решение, которое разработал сам. p.s. Использовать готовенькое может каждый, а своё сделать - воля нужна.
Использую свой собственный шаблонизатор, который имеет такие конструкции как блоки, условия и отображение переменных. Вполне хватает. Smarty смотрел, весьма громоздкое решение. Все равно что ядерной боеголовской по гусенице
Имхо. Чтобы написать гостевую книгу не обязательно использовать смарти, так же как и необязательно для приготовления яишницы использовать огнемет...
а если это будет быстрее чем классическим способом? и при чем даже из скорлупы не нужно вынимать (оптимизация процессов)... К сожалению, рыночные условия и потогонная система довольно часто заставляют людей принимать решения не соответствующие здравому смыслу, лишь бы "схавать" побольше...
Согласен. Но именно поэтому если за дело будет браться профессионал, а особенно если за переделку чужого наделанного, денюжка будет очень неплохо капать... Согласись, не все могут себе позволить разработать нестандартное, быстрое решение: ведь "в лоб" куда быстрее и начхать что там десяток ненужных запросов от которых БД стонет и т.д.
Ну зачем этот Смарти? Я считаю, что использования конструкций require и функций пользователя - супер решение. При этом *.php давать только файлам где есть только php, а *.html - где Html, echo, foreach.
У заказчика есть задача/потребность и деньги на ее реализацию. Он даже понимает, что наиболее эффективно для него разбить работу на части: - для сути нанять маркетолога/технолога/дизайнера, - для оформления нанять художника/дизайнера, - для интерактивности нанять программиста. Можно спорить о значимости каждого из них для проекта, но для самого заказчика очевидно что программист тут занимает далеко не ведущую роль! Он для заказчика всего-лишь как кукловод - заставляет казаться живой эту игрушку... Так вот если дизайнер (в первой или второй роли) скажет что ему для исполнения задачи нужен "черт с рогами" - программист будет писать под это... Добавлено через 2 минуты. Добавлю. Чтобы избежать разногласий (и как следствие - достижение более качественного результата) нормальный заказчик привлечет стабильную сложившуюся группу этих специалистов, которые внутри уже разобрались как и на чем они вместе работают. Идеальный случай - это когда программист еще на этапе разработки технологического процесса убедил всех остальных специалистов в наиболее правильном техническом решении, и научил их всех эффективно пользоваться этим инструментом.
Как только узнал что есть смарти, сразу же начал его использовать. Но медленно он работает что не говори. На глаза попался старенький сайтик (еще о смарти не знал), и решил немного поправить и спросить в чем заключаются минусы такого подхода? Есть какой нить файл с так сказать "шаблоном" файл_с_шаблоном.php PHP: <html> <head> <title><?=$content['title']?></title> </head> <body> <table> <tr><td colspan="3">Тут шапка</td></tr> <tr> <td>Тут меню</td> <td><?=$content['body']?></td> <td>тут баннеры</td> </tr> <tr><td colspan="3">Тут всякая ерунда</td></tr> </table> </body> </html> и возьмем index.php PHP: <? $content=array(); $content['title']='Главная'; $content['body']='тут все что угодно'; include('файл_с_шаблоном.php'); ?> По своему опыту знаю что обычно на разных страницах сайта изменяется только одна какая то часть, если больше(например меню), можно $content['menu']='генерация какого хошь меню' и в файле с шаблоном вставить в нужное место. Кто шо думает по этому поводу....
Я вот использую иногда такой подход. У меня в одном скрипте список категорий сайта (с вложенными под-категориями неограниченного уровня вложения) так я в админке когда добавляю/убавляю/правлю категорию то кидаю в кеш готовый HTML-код и его использую, аналогично и с другими частями скрипта которые меняются только в админке. Это конечно не совсем правильно с точки зрения некоторых "понятий" однако это позволяет 1 - максимально снизить нагрузку на БД 2 - сильно упростить код 3 - не беспокоиться о шаблонизации ибо такие куски кода стандартны не зависимо от дизайна (список он и в африке <ul>, таблица она и в африке <table>, а дизайн прекрасно задаётся стилями) Из минусов только то что выкладывать в публику такой скрипт я не могу так как мне репутация дороже
smarty smarty однозначно лажа. как по производительности так и например тем что.... smnarty тот же код программирования. нах нам еще один язык когда есть php??? в чем выгода тогда того же смарти. изменение литералов? в моей цмс построено все следующим способом. в конкретной папке хранится дизайн всей страницы. назовем его main.inc в нем, к примеру, в конкретных местах вставляем "зоны дизайна": <?=$_LEFT_?> <?=$_TOP_?> <?=$_RIGHT_?> <?=$_BOTTOM_?> <?=$_CONTENT_?> все что надо будет дизайнеру верстальщику это в нужных местах вставить <?=_....._?> код. идем дальше.... в другой папке создаем "блок1". в этом блоке вызывается файл index.inc который подготавливает данные и затем передает массивом в файл table.htm в той же папке. ядро цмс сразу все эти выводы перехватывает средствами ob_ и записывает в переменные. В админке мы создаем страницу на которой подключаем к каждой из зон "блок". и тем самым к одной зоне можно подключить любое количество блоков. отсюда получается высокая производительность (т.к. не надо парсить чужой код (smarty)), легкочитаемость кода (всегда понятно где что откуда берется и не приходится рыться в тоннах), повторность использования кода без использования includов, что в своем выигрывает быстрым изменением содержания страниц. к тому же код реально уменьшается в размерах. у меня сайт парнишка делает на этой системе, что то на подобии km.ru и кода у него написано около 1 мб, и ядро почти 2 мб. самая требовательная страница формируется не более чем за 2-3 секунды и mysql запросов не более 30. от дизайнера верстальщика требуется при таком подходе только лишь сделать главный макет страницы (main.inc) а дизайн блоков (например для меню) сможет доделать и сам программист. все же он должен знать основы css и html )))))