Joo писал(а):FireFenix писал(а):Яркий пример - пару метров кода Веб-магазин под Джумлу. Когда я его открыл... то просто был в шоке от мяса. Я даже без понятия как они сами умудряются в нём ориентироваться.Дикий микс пхп кода с хтмл. Мало обычных конструкций с выводом, так ещё и запросы к бд и прочий хлам.
Ты пытаешься привести пример не имеющий к предложенному мной методу никакого отношения! То, что ты описал это маразм и ребята из Joomla сами себе злобные Буратино!
Я привёл пример, когда всё безобидно начиналось
echo($var); и закончилось фаршем.
Joo писал(а):Если придет новый программист в проект, откроет шаблон и увидит это {main.title}, ему придется лезть изучать доки по шаблонизатору если они есть, или примеры использования или в конце концов его реализацию, ему придется обучаться, он не сможет применить свои прошлые навыки. Хорошо еще когда используются популярные шаблонизаторы Smarty или Twiggy, с которыми приходилось сталкиваться практически каждому веб-программисту.
Ну когда пользователь видит
<?= $main_title ?> ему тоже так или иначе придётся понять смысл переменной.
Joo писал(а):Другие аргументы, всего лишь попытка защитить свое детище.
Я уже говорил - что я выдрал в одном из проектов и использую потому, что мне нравится => не моё детище.
Joo писал(а):FireFenix, единственный весомый аргумент в пользу шаблонизаторов с собственным синтаксисом привел Хакер, который я ждал от тебя.
На PHP можно делать короткие, красивые и понятные любому веб-программисту вставки, можно организовать простой и быстрый шаблонизатор, например такой, как я описывал выше, который сведет PHP код в шаблоне к минимуму. Верстальщика ничуть не сложнее обучить пользоваться <?= $var ?> <? foreach(): ?><? endforeach ?> <? if(): ?><? endif ?> чем {varname}{foreach()} {/foreach} {if}{/if}, причем от шаблонизатора к щаблонизатору синтаксис меняется, а PHP остается неизменным.
Я ненавистник мешанины шаблона и логики/логики формирования шаблона, которые успешно можно вынести в отдельный модуль/функцию, поэтому и предложил использование для заполнение переменных в шаблоне - этот код. Ну и логику формирования интерфейса вынести в отдельный модуль/шаблон.
Естественно на вкус и цвет - все шаблонизаторы разные и никто не использовать мои идеалы и подход к программированию/проектированию.
Joo писал(а):Не нужно говорить, что программисту, легче понять вставки с непонятным синтаксисом, чем PHP вставки.
Как я писал выше, что не нравиться мне микс логики и статического интерфейса => я предполагал что вставок вообще никаких не будет, кроме как место вывода содержания переменных и вся логика формирования интерфейса выделена в отдельную часть/модуль/файл
Proxy писал(а):Сомнительно. Если рассматривать код проекта до его скармливания интерпретатору, то никакого представления вообще нет в рамках проекта в таком случае (если только конечный html). В общем странно звучит. Если только шаблоны, то как же быть с фрагментами кода, генерирующими стоки, но не использующие до вывода шаблоны (да даже вывод сообщения об ошибке субд, форматирование даты в человекопонятный формат (тоже форматирование текста для получения структурированной последовательности символов), обработка bb-кода в сообщениях пользователей до вывода и т.п), чем это является? Уж всяко оно больше привязано к представлению, нежели к контроллеру и тем более к модели.
Как мне кажется, что php – это не тот случай, где представление так вот легко выделить.
С моей точки зрения, любой сайт - есть множество модулей (хеадер, контент, футер, новостная лента и т.д.), которые можно представить через MVC паттерн.
Шаблон/Конечный html-код
В данном случае я предполагал, что шаблон и весь код который его формирует есть компонент "представление".
Но если сайт имеет модуль, который имеет статическое отображение => для него будет простой вывод html, т.е. фактический сам html-код модуля и есть представление. Как то так я думаю...
Птицей Гермеса меня называют, свои крылья пожирая... сам себя я укрощаю
私はヘルメスの鳥 私は自らの羽根を喰らい 飼い慣らされる