MACRO - стотысячная попытка сделать новый PHP шаблонизатор

StUV · 16 Окт 2007

не верю я

эх... что я могу с этим поделать?

когда фронт-логика была простой - вообще на фронте было ssi достаточно
позднее ssi превратил фронт страницы в дикую кашу
еще позднее стал невыносим в поддержке

как будет выглядеть полностью предкомпилированная страница _без_инклудов_ с разным временем жизни кеша разных участков страницы (от 0 по времени до обновления по событию)?...

Просчеты архитектуры?

где-то видел другую?

dark-demon · 16 Окт 2007

>> можно, например, в качестве значения в YAML использовать вложенный YAML?
> Какой-то прямо клинический случай идолопоклонничества XML.

то есть типа я не должен хотеть использовать внутри строк тройное тире?

>> основной контроллер должен иметь полный контроль над формированием страницы.
> Кто кому "должен"?

контроллер разработчику.

> Ты, наверное, совсем недавно прочитал PoEAA и теперь полностью и бесповоротно следуешь "библии архитектора"?

не знаю, кто такая поэаа, но не удивлюсь, если одна и та же умная мысль пришла в голову разным людям.
вот глупости - они поистине уникальны

иногда такие встретишь, что волосы встают дыбом...

> голову не придет отлаживать тот же include в PHP, просто потому, что он должен работать по-определению

ага, идеальная программа:

<?php
include( 'makemeperfect.inc' );
?>

^_^

korchasa · 16 Окт 2007

Автор оригинала: dark-demon
то есть типа я не должен хотеть использовать внутри строк тройное тире?

а неиспользовать <adasdas/>, чтобы они не стали тегами в xml вы готовы. Где разница? Тройное тире чаще встречается?

>>> основной контроллер должен иметь полный контроль над формированием страницы.
>> Кто кому "должен"?
>контроллер разработчику.

Т.е. программисту, а не дизайнеру/верстальщику?

pachanga · 16 Окт 2007

как будет выглядеть полностью предкомпилированная страница _без_инклудов_ с разным временем жизни кеша разных участков страницы (от 0 по времени до обновления по событию)?...

А мы с тобой, случаем, не о разных ли вещах говорим? Под предкомпиляцией я, например, имею в виду создание PHP скрипта, а не кеширование HTML...

StUV · 16 Окт 2007

не о разных ли вещах говорим?

не, не о разных

у меня то, что инклудится в "потенциально компилируемый" шаблон может потерять актуальность в любой момент (по событию на бэк-енде) - поэтому избавиться от пхп-инклудов полностью - я не могу (от этих данных зависит логика построения страницы и вариантов представления слишком много, чтобы на-лету их все перегенерять)
следовательно, теряется выгода от повышения производительности для тех примеров, в которых у тебя будет полная предкомпиляция всей страницы (без пхп-инклудов)

соответственно, если рассматривать шаблоны с инклудами предкомпилированных частей страницы - то для меня предпочтительнее сразу делать "красивый" пхп-натив код (проще в отладке), чем докручивать прослойку в виде "стороннего" компилера,
и оптимизировать производительность раздельным кешированием тех блоков, где это возможно

dark-demon · 16 Окт 2007

> а неиспользовать <adasdas/>, чтобы они не стали тегами в xml вы готовы.

нет, поэтому в xml есть несколько способов экранирования:
1. используя сущности
2. используя CDATA

> Т.е. программисту, а не дизайнеру/верстальщику?

а они тут причём?

korchasa · 16 Окт 2007

Автор оригинала: dark-demon
> а неиспользовать <adasdas/>, чтобы они не стали тегами в xml вы готовы.
нет, поэтому в xml есть несколько способов экранирования:
1. используя сущности
2. используя CDATA

Все равно придется писать свой storage, который будет уметь yaml2array, array2yaml. Что мешает в нем вшить, что ЩСАШФРЫШГШГМ, это "---"

>> Т.е. программисту, а не дизайнеру/верстальщику?
>а они тут причём?

При том, что программист не должен думать о том, что какой-то верстальщик вставил в его страницу модуль новостей, и поэтому ему придется, в лучшем случае "правильно" вызывать метод чужого контроллера, чтобы загрузить данные. При этом если не реализованно разделение между данными разных контроллеров, то ему еще придется и думать о возможном конфликте имен в данных.

dark-demon · 16 Окт 2007

> Что мешает в нем вшить, что ЩСАШФРЫШГШГМ, это "---"

наверное то же самое, что и в случае с > - неудобство ручной правки.

> При том, что программист не должен думать о том, что какой-то верстальщик вставил в его страницу модуль новостей,

должен. иначе верстальщик может много чего понавставлять...
есть три роли:
1. дизайнер. он определяет что, где и в каком виде должно находиться.
2. верстальщик. он пишет шаблоны, которые трансформируют выданные программистом данные в то, что хочет дизайнер.
3. программист. он обрабатывает запросы и формирует данные.

как происходит добавление новостного блока:
дизайнер приходит к программисту и говорит, что на главной странице он хочет видеть новости помеченные тэгом "бонусы", на остальных - все, которые не помечены тэгом "внутренние", а в админке - только "внутренние".
программист идёт и пишет класс TaggedNews, который наследуется от News. в админке при редактировании новости добавляет дополнительное поле. потом прописывает в контроллерах в нужных местах формирование нужных новостей. и вот теперь в дело вступает верстальщик, который должен привести новости к презентабельному виду. или не вступает и будет использован шаблон написанный для News.

и не надо про рафинированные условия, когда у нас есть модуль, модифицировать его не надо, контекстных зависимостей у него нет, а бедному верстальщику приходится править все шаблоны каждый раз, когда программисту потребуется создать новый класс или дизайнеру захочется добавить ещё каких-нибудь правил. при таком подходе получается либо дофига шаблонов (даже без учёта разных скинов ) либо в шаблонах содержится сложная и витиеватая логика.

pachanga · 16 Окт 2007

Автор оригинала: dark-demon
> Ну вот смотри, у тебя есть 10 подобных "правильных контроллеров"
> и что каждый из них будет дублировать логику по передаче _второстепенных_
> для него данных(это новости) каждый раз?

да, так.

Я представляю, как выглядят твои контроллеры на странице с большим количеством второстепенных элементов. Вместо того, чтобы сконцентрироваться на выполнении конкретной задачи, котроллер перегружен "шелухой". Продолжай в том же ключе, ведь это "правильно"

-~{}~ 16.10.07 20:23:

Автор оригинала: StUV
не, не о разных

Ты меня заинтриговал

Не мог бы пожалуйста описать схему работы твоего приложения на концептуальном уровне?

korchasa · 16 Окт 2007

Автор оригинала: dark-demon
>> Что мешает в нем вшить, что ЩСАШФРЫШГШГМ, это "---"
>наверное то же самое, что и в случае с > - неудобство ручной правки.

Что мешает защить функционал во что-то? Вы же данные из базы не в xml получаете? Значит его кто-то конвертит...

>> При том, что программист не должен думать о том, что какой-то верстальщик вставил в его страницу модуль >>новостей,
>должен. иначе верстальщик может много чего понавставлять...
>1. дизайнер. он определяет что, где и в каком виде должно находиться.
>2. верстальщик. он пишет шаблоны, которые трансформируют выданные программистом данные в то, что хочет >дизайнер.
>3. программист. он обрабатывает запросы и формирует данные.

Вы сами запутались, кто что должен. Перечитайте эти строчки. Все таки программист, или дизайнер?

Автор оригинала: dark-demon
>> Ну вот смотри, у тебя есть 10 подобных "правильных контроллеров"
>> и что каждый из них будет дублировать логику по передаче _второстепенных_
>> для него данных(это новости) каждый раз?
>да, так.

Пипец котенку. Т.е. у вас либо паутина из контроллеров(если вы их вызываете друг из друга), либо огромные вонючие горы дублирующегося кода? Вы за мат на работе не штрафуете надеюсь?

Почитайте про CompositeView (еще ). Если вам Java не нравится, то есть и на РНР.

dark-demon · 16 Окт 2007

pachanga, если это - "шелуха", то это вообще не стоит выводить на страницу. коли уж это выводится, значит это - "сопутствующие данные", которые могут формироваться как в этом контроллере, так и в вызываемом им подконтроллере, но уж никак не в шаблонах вывода.

-~{}~ 16.10.07 21:36:

korchasa, во-первых мне не надо про это читать, ибо я наработался уже с таким подходом, когда контроллер страницы не может избавиться от обязательных для всех "шапки" и "подвала", когда контроллер не может послать заголовки, ввиду того, что "они уже посланы", и приходится лезть во фронт-контроллер, чтобы вписать туды исключения.
во-вторых, composite-view не имеет ничего общего с вызовом контроллеров из вьюх.
диаграмки не просто так там приведены:

pachanga · 16 Окт 2007

dark-demon
Пожалуй, вот на этом месте, я прекращу с тобой спор. Передавай привет копи-пейсту

korchasa · 16 Окт 2007

Автор оригинала: dark-demon
во-первых мне не надо про это читать, ибо я наработался уже с таким подходом, когда контроллер страницы не может избавиться от обязательных для всех "шапки" и "подвала", когда контроллер не может послать заголовки, ввиду того, что "они уже посланы", и приходится лезть во фронт-контроллер, чтобы вписать туды исключения.

Так у вас и объекта-синглтона, который бы отвечал за вывод нет? Чур меня, чур. Вы как же работаете то? Качайте Zend и смотрите, спасите психику программистов.

во-вторых, composite-view не имеет ничего общего с вызовом контроллеров из вьюх.
диаграмки не просто так там приведены:

А вот эта картинка нам о чем говорит

pachanga · 16 Окт 2007

во-вторых, composite-view не имеет ничего общего с вызовом контроллеров из вьюх.

Не удержался, да, сколько же можно твердить, что контроллер тут ни при чем. hint: модель!

dark-demon · 16 Окт 2007

вьюха, самостоятельно выбирающая себе модель и самостоятельно же запрашивающая у неё данные - это химера контроллера и вьюхи. SQL в HTML - из той же оперы.

-~{}~ 16.10.07 22:01:

> Так у вас и объекта-синглтона, который бы отвечал за вывод нет?

что понимается под "отвечал за вывод"?

> А вот эта картинка нам о чем говорит

она говорит нам, что ко вьюхе, как и к любой другой сущности, может быть применена декомпозиция.

С. · 17 Окт 2007

я наработался уже с таким подходом, когда контроллер страницы не может избавиться от обязательных для всех "шапки" и "подвала"

Ну это как ты свой фреймоворк устроил. Отсутствие шапки и подвала конечно больше исключение, но достаточно распространенное, чтобы быть обработанным достойным образом во фреймворке.

когда контроллер не может послать заголовки, ввиду того, что "они уже посланы", и приходится лезть во фронт-контроллер, чтобы вписать туды исключения.

А вот это закостенелость прошлого века -- работать напрямую с HTTP. Абстрагирующая прослойка поверх HTTP позволит и заголовки посылать когда вздумается и еще кучу всяких прелестей.

Dagdamor · 17 Окт 2007

dark-demon
Представь себе задачу: в дизайне сайта используется меню с надписями каким-нибудь экзотическим шрифтом (славянским например) + надписи очень художественно оформлены. Понятно, что возможностей шаблона для этого недостаточно, но и выносить это в бизнес-логику тоже нельзя - не имеет эта задача никакого отношения к логике работы сайта. На мой взгляд, остается только использовать pull view; пусть шаблон, отображающий меню, вызывает некий контроллер, который генерирует картинку с надписью при помощи GD, кеширует ее и возвращает имя файла, которое потом можно вставить в <img>.

korchasa · 17 Окт 2007

Автор оригинала: dark-demon
вьюха, самостоятельно выбирающая себе модель и самостоятельно же запрашивающая у неё данные - это химера контроллера и вьюхи. SQL в HTML - из той же оперы.

Это откуда такие выводы? :confused:

В первой ссылке это делает VIewManager, во второй ScreenFlowManager

>что понимается под "отвечал за вывод"?

Объект который "знает/умеет" правильно выводить на экран, выставлять статус, делать различные редиректы (HttpResponse), и прочие мелкие радости. Еще раз скажу - скачайте Zend Framework, или любой другой "правильный"

dark-demon · 17 Окт 2007

С., своему фреймворку я б уже давно сделал рефакторинг

Dagdamor, когда мы формируем страницу, никаких картинок у нас нет. есть только лишь текст, который преобразутся к <img src="..." />. а формирование картинки через GD и её кэширование - это уже отдельный запрос c отдельным циклом обработки, где вьюха вообще может не выделяться в отдельную сущность.

> В первой ссылке это делает VIewManager

"The View Manager manages the inclusion of portions of template fragments into the composite view"

> во второй ScreenFlowManager

заметь, что во второй вообще нет выделения контроллеров. там от фронт-контроллера управление передаётся сразу ко вьюхе. то есть, каждая вьюха является по совместительству и контроллером.

pachanga · 20 Окт 2007

Добавил в MACRO экспериментальную возможность использовать "вложенные" шаблоны(чем-то похоже на XSLT), например так:

Код:

{{template name="tpl1"}}
Hello, {$name}
{{/template}}

{{apply template="tpl1 name="Bob"/}}

Тесты можно посмотреть здесь https://svn.limb-project.com/limb/3.x/trunk/limb/macro/tests/cases/tags/lmbMacroTemplateTagTest.class.php

MACRO - стотысячная попытка сделать новый PHP шаблонизатор

Rotaredom

d(^-^)b

LIMB infected

Новичок

Rotaredom

d(^-^)b

LIMB infected

d(^-^)b

Новичок

LIMB infected

d(^-^)b

Новичок

LIMB infected

Новичок

d(^-^)b

Продвинутый новичок

Новичок

LIMB infected

d(^-^)b

Новичок