Сделал proof of concept реализацию {{tree}} макроса, посмотри на тесты - https://svn.limb-project.com/limb/3.x/trunk/limb/macro/tests/cases/tags/lmbMacroTreeTagTest.class.php и собственно реализацию - https://svn.limb-project.com/limb/3.x/trunk/limb/macro/src/tags/tree.tag.php
Ну вот смотри, у тебя есть 10 подобных "правильных контроллеров" и что каждый из них будет дублировать логику по передаче _второстепенных_ для него данных(это новости) каждый раз? А вдруг заказчик захотел, чтобы еще и последние топики из форума показывались где-то в колонке, и что, ты это опять продублируешь передачу топиков 10 раз?
Я не хочу сказать, что XML вселенское зло, но, ведь, и перебарщивать тоже не надо.
если это действительно "на самом деле" - зачем тогда этот "syntactic sugar" вообще нужен?Автор оригинала: pachanga
Воот, самое лаконичное и удачное определение, на самом деле
А зачем выносить преимущества XML за пределы HTML? XML избыточен, поэтому в конфигах все чаще применяют YAML, в AJAX - JSON, и т.д.
Зачем? С аналогом XPath, как namespaces я согласен.
Ну вот, например, я показал пример реализации дерева с помощью макроса {{tree}}, давай посмотрим, что получится, если сделать то же самое на голом PHP? Или, например, {{wrap}} макрос, который компилируется очень оптимально и не вызывает оверхеда во время исполнения при этом добавляет, на мой взгляд, крайне полезный функционал. Опять же, попробуй сделать это на голом PHP
Или {{include}} макрос - в случае статического подключения происходит включение шаблона на _этапе компиляции_, а не во время исполнения. Я могу долго перечислять pachanga, ты опускаешься до уровня банального флеймера? По моему, здесь обсуждается MACRO, и XSLT упоминался в контексте примера функциональности, которой в макро нет. Никто не говорит что у XSLT нет недостатков, и никто не воздвигает его на постамент, но та функциональность, о которой я говорил, полезна, и глупо это отрицать.
Даже в MVC реализациях есть события preExecute и postExecute, в которые можно вставить дублирующиеся участки кода, и тем самым избежать дублирования. Так что не надо тут панику поднимать, и в ладоши хлопать.
) с простым использованием подключением в самом шаблоне, или получить весь этот хкод в шаблоне, если им займется "неразумный кодер"...это я как-то пропустил, сорри, наверно не очень внимательно читал тред - что там за проблема?
хм
ну... я могу долго перечислять грабли с другой стороны
Посмотри, плиз внимательно выше я объяснил, как работает {{wrap}}, если интересно, посмотри тесты на него https://svn.limb-project.com/limb/3.x/trunk/limb/macro/tests/cases/tags/lmbMacroWrapTagTest.class.php(обрати внимание на multi и nested wrap). Вот как это можно реализовать просто средствами PHP в шаблоне?
Я даже и не знаю, какие еще аргументы приводить. Улучшения понятности, читабельности, экспрессивности, эффективности, наверное, недостаточно
Я не имел ввиду конкретную реализацию. Я подразумевал, что раз YAML претендует на лавры XML, он должен иметь необходимый инструментарий: средства для поиска (альтернативу XPath, необязательно такую навороченную) и средства управления (альтернативу DOM).
Ну ты же понимаешь, что в конечном итоге выполняется просто PHP код, что может быть быстрее?Автор оригинала: StUV
тесты производительности
возможно с предкомпиляцией, но без кеширования
Вообще, идея {{wrap}} в другом, он позволяет, избежать дублирование в шаблонах. Вместо того, чтобы в каждом шаблоне писать:
{{include file="header.phtml"}}
Content
{{include file="footer.phtml"}}<html>
...
{{slot id="content"}}
...
</html>{{wrap with="layout.phtml" into="content"}}
Content
{{/wrap}}{{wrap with="layout.phtml"}}
{{into slot="title"}}
Some title
{{/into}}
{{into slot="content"}}
Some content
{{/into}}
{{/wrap}}...
<h1>{{slot id="title"}}</h1>
...
<div class="body">
{{slot id="content"}}
</div>
...Какой-то прямо клинический случай идолопоклонничества XML.и YAML никак не может претендовать на лавры XML, потому как ему не хватает X хромосомы, те eXstensible-а
можно, например, в качестве значения в YAML использовать вложенный YAML?
И с ним тоже.
Кто кому "должен"? Мне очень забавно тебя читать. Ты, наверное, совсем недавно прочитал PoEAA и теперь полностью и бесповоротно следуешь "библии архитектора"?
Я смотрю, "в друзьях согласья нет"
Ну что, давайте теперь еще поговорим про "парадигмы MVC"...
зачем?
тесты покажут.... - все зависит от качества твоего компилера
)
Ладно, это бесполезный спор
Точнее от качества реализации конкретного макроса. Естественно накосячить можно везде, но ведь есть же тесты, бенчитесты покажут.... - все зависит от качества твоего компилера
Согласен, но как бы идея в том, чтобы предоставить базовый и максимально протестированный набор макросов, дебажить которые просто было бы бессмысленно. Например, мне в голову не придет отлаживать тот же include в PHP, просто потому, что он должен работать по-определениюв отладке проще нормальный пхп-шаблон, чем то что получается напр в смарти после компиляции (но это уже "дело вкуса"
(конечно, везде бывают баги, но я думаю ты понял, что я имею в виду)Почему?
хм