Понятно. Мне же не раз приходилось разворачивать систему там, где нет rewrite, либо там, где введение новых правил rewrite усложнено (например, в конфигах сервера). Поэтому у меня одна общая точка входа в систему и парсингом занимается контроллер (в правильной терминологии ;))
>а значит, любое изменение в иерархии урлов можно производить без изменения кода моделей и контроллера…
Это само собой. У меня привязка URL'ов и классов прописывается явно в соответствующих handler-файлах (хотя есть механизмы и неявной привязки к структуре URL, иногда удобно — но они реализованы на общем принципе. Просто, если не находится явная привязка, поочерёдно вызываются классы, повешенные на URL вида ".*", пока не найдётся отозвавшийся).
>О каком парсинге может идти речь, когда это структура данных, а не обьект?
В шаблоне вывода топика есть цикл вывода сообщения.
В субшаблоне сообщения есть показ автора сообщения.
В субшаблоне автора выполняется показ его имени.
При автоматической генерации дерева нужно понять, что мы должны заранее загрузить все объекты пользователей, которые привязаны к указанным сообщениям. Это потребует явного указания в шаблоне и его парсинга.
Если автогенерации нет и всё указывается программистом в контроллере вручную, то непонятно, в чём вообще проблема и чем это отличается от моего метода, кроме того, что передавать надо не хеш, а DOM-дерево? :)
Это может работать у меня прямо сейчас, практически из коробки :)
Насколько я понял, задача стоит шире — сделать формирование данных контроллером универсальным, на основе шаблона документа, которому предстоит скормить эти данные.
Вот это и будет слишком медленно в PHP. Нам придётся делать сложный древовидный парсинг и ловить зависимости отъектов.
Если я не правильно понял, и подразумевается построение контроллера дерева объектов программистом вручную, то, повторюсь, у меня это можно хоть сейчас запускать :) Но не думаю, что это выгоднее имеющегося механизма с хешем базовых данных и представлением, которое само извлекает потом всё, что ему нужно при рендеринге. Разве что только для того, чтобы припахать XML-представление :)
>Вообще, если брать простые случаи, то концепция PageDOM — это всего лишь более общий вариант вашего local_template_data_set.
В простых случаях (скажем, нужно вывести постраничный список объектов) этот метод у меня может отсутствовать в конечном классе, полностью реализованный в суперклассе :)
>Во-вторых, тяжёлой нагрузки на код не будет, по причине того, что эта концепция лаконична.
Зато нелаконично — парсить шаблон на тему зависимых объектов, которые нужно грузить скопом :)
>Вместо HTML мы изначально храним некий многоуровневой хэш, или обьект. Далее выполняем fetch (local_template_data_set?), далее рендерим.
Так чем тогда это от моего способа отличается? Подключаем к моей системе xml-render-engine (надобности не было, так что не разбирался. Всё, что нужно — это подобрать хороший готовый механизм засовывания хеша в XML) и имеем готовый результат :)
Пардон, но заголовок, запрашивающий данные — это контроллер. Думаю, не правильно держать его в представлении :)
…
Собственно, у меня каждый объект обычно состоит из двух компонентов — класса и локального шаблона. По сути класс — это контроллер. Шаблон — представление. Зачем их объединять — непонятно :) Тем более, что их разделение повышает гибкость. Я могу использовать разные представления для одного контроллера, могу — разные котроллеры у одного представления.
Безусловно. Но тогда почему бы контроллеру кроме этих данных не готовить и другие? :) Всё равно привязка URL не универсальная в общем случае, а объект-специфичная.
Но только не в лёгкой. Даже Су-27 за 8 лет был сделан от постановления о начале разработки до первого полёта. А под него пришлось в стране целую инфраструктуру строить. С освоением не применявшихся до того технологий.
Цикл разработки самолётов типа сабжа длится около года в отсутствии качественного финансирования. У меня товарищ за год организовал с нуля ОКБ и разработал проект вполне конкурентноспособной пилотажки низкого ценового диапазона. Сейчас решают вопросы серийного производства :)
Одним только документом всё равно не обойтись. Как ни крути, но документ не может/не должен заниматься раскруткой URL до нужных объектов. Значит, потребуется некий отдельный код, делающий это. Так почему в этот код тогда не добавить ещё пару строк для извлечения всех оставшихся данных?
А потом полученный хеш скормим XSL-процессору :)
…
Хотя, как я выше писал, возможен компромиссный вариант. Базовые параметры (topic_id для темы форума, страницы и прочее) выделяет фреймворк. Далее включается XML-парсер и извлекает из шаблона все нужные ему имена данных, занимается сведением этих данных, загрузкой и скармливанием XSL-процессору.
Будет очень медленно, и с тяжёлым не human-readable синтаксисом.
И только один сомнительный бонус — отсутствие вручную написанного кода загрузки данных в контроллере. Но это итак обычно только несколько строк :)
>как сделать так, чтобы можно было написать шаблон страницы, и, не исправляя код, выводить туда любые доступные в программе данные в нужном виде?
Например, использовать унифицированную систему именования полей объектов. Тогда {$x->title()} будет работать для всех объектов :)
А если от объекта требуется индивидуальный рендеринг — то шаблончик может храниться при нём, а отдаваться по тем же полям — {$x->body()}. При этом body() может заниматься массой умных вещей, вплоть до вопросов кеширования.
Фишка в том, что такая структура сильно повысит нагрузку на код. И в результате можно очень капитально проиграть в итоговом быстродействии более классическим структурам.
Что в этом примере, что у меня — запросов будет только два. На запросах выигрыша нет. Паритет.
По сложности восприятия на уровне низкого вхождения у меня явно проще, на высоком уровне при грамотной реализации вариант PageDOM возможно, будет проще. Хотя даже это не факт. Но пусть будет паритет :)
По скорости PageDOM потребует намного больших вычислений, что в случае PHP весьма накладно. Тут PageDOM в минусе.
>Обьектная модель документа (блоки HTML, профилей пользователя, меню и прочая).
Это реально реализовать только через что-то типа XML. Так что тогда мешает сразу делать XML-шаблоны и парсить их любым штатным XSL-процессором? :) Хоть в HTML, хоть во что-то ещё?
…
Но, ИМХО, это лишняя сущность.
>Главная беда большинства современных CMS — они мыслят на уровне HTML
За других не скажу, но у меня не важно, какой у объекта template_engine. Можно сделать и самоизвлекающий нужные данные XML. На практике фреймворк «мыслит» в сущностях HTML, PNG/GIF/JPEG, XML+RSS.
Но, с другой стороны, а почему бы и в сущностях HTML сразу не мыслить? Если это 99% рынка, а такое сужение позволяет существенно упростить разработку, повысить скорость, гибкость, а кое-где и чистоту MVC?
Есть реальные плюсы у чисто объектного описания документа, перекрывающие массу минусов?
Я думал, только я имею привычку нагруженный сайт обновлять вживую, без тестового. Но я это делаю, хотя бы, часов в 5 ночи, когда посещаемость минимальна ;)
>Обычный самолет может позволить себе сравнительно небольшой угол атаки — всего около 13°.
Что такое «обычный самолёт»? Судя по кабине, это что-то на базе Як-18Т. Критического угла атаки для него в РЛЭ не нашёл, но он явно больше 13° :) Скорее всего что-то под 20°.
Если же брать современные пилотажки, то у тех же Су-31 управляемость сохраняется практически во всех режимах полёта.
Авиация военная — ещё интереснее. 4-е поколение (МиГ-29, Су-27) летает на углах атаки до 24..26°
Як-130 управляется на углах атаки до 42°
F-22 устойчив на углах атаки до 60°
Су-30МКИ управляем на любых углах атаки ±180°
Да, пардон, был не прав :)
>Контроллер получает реврайтом нечто вроде
Понятно. Мне же не раз приходилось разворачивать систему там, где нет rewrite, либо там, где введение новых правил rewrite усложнено (например, в конфигах сервера). Поэтому у меня одна общая точка входа в систему и парсингом занимается контроллер (в правильной терминологии ;))
>а значит, любое изменение в иерархии урлов можно производить без изменения кода моделей и контроллера…
Это само собой. У меня привязка URL'ов и классов прописывается явно в соответствующих handler-файлах (хотя есть механизмы и неявной привязки к структуре URL, иногда удобно — но они реализованы на общем принципе. Просто, если не находится явная привязка, поочерёдно вызываются классы, повешенные на URL вида ".*", пока не найдётся отозвавшийся).
>
Чем «сторонние плагины дерева» лучше функций PHP, модификаторов Smarty или перегружаемого метода класса?
В шаблоне вывода топика есть цикл вывода сообщения.
В субшаблоне сообщения есть показ автора сообщения.
В субшаблоне автора выполняется показ его имени.
При автоматической генерации дерева нужно понять, что мы должны заранее загрузить все объекты пользователей, которые привязаны к указанным сообщениям. Это потребует явного указания в шаблоне и его парсинга.
Если автогенерации нет и всё указывается программистом в контроллере вручную, то непонятно, в чём вообще проблема и чем это отличается от моего метода, кроме того, что передавать надо не хеш, а DOM-дерево? :)
Насколько я понял, задача стоит шире — сделать формирование данных контроллером универсальным, на основе шаблона документа, которому предстоит скормить эти данные.
Вот это и будет слишком медленно в PHP. Нам придётся делать сложный древовидный парсинг и ловить зависимости отъектов.
Если я не правильно понял, и подразумевается построение контроллера дерева объектов программистом вручную, то, повторюсь, у меня это можно хоть сейчас запускать :) Но не думаю, что это выгоднее имеющегося механизма с хешем базовых данных и представлением, которое само извлекает потом всё, что ему нужно при рендеринге. Разве что только для того, чтобы припахать XML-представление :)
Ну да, как и я — в своей реализации ;)
В простых случаях (скажем, нужно вывести постраничный список объектов) этот метод у меня может отсутствовать в конечном классе, полностью реализованный в суперклассе :)
>Во-вторых, тяжёлой нагрузки на код не будет, по причине того, что эта концепция лаконична.
Зато нелаконично — парсить шаблон на тему зависимых объектов, которые нужно грузить скопом :)
>Вместо HTML мы изначально храним некий многоуровневой хэш, или обьект. Далее выполняем fetch (local_template_data_set?), далее рендерим.
Так чем тогда это от моего способа отличается? Подключаем к моей системе xml-render-engine (надобности не было, так что не разбирался. Всё, что нужно — это подобрать хороший готовый механизм засовывания хеша в XML) и имеем готовый результат :)
…
Собственно, у меня каждый объект обычно состоит из двух компонентов — класса и локального шаблона. По сути класс — это контроллер. Шаблон — представление. Зачем их объединять — непонятно :) Тем более, что их разделение повышает гибкость. Я могу использовать разные представления для одного контроллера, могу — разные котроллеры у одного представления.
Цикл разработки самолётов типа сабжа длится около года в отсутствии качественного финансирования. У меня товарищ за год организовал с нуля ОКБ и разработал проект вполне конкурентноспособной пилотажки низкого ценового диапазона. Сейчас решают вопросы серийного производства :)
www.youtube.com/watch?v=J3q8MDFltxI
Им не нужно по 12 тонн топлива таскать и по 8 тонн вооружений ;)
На 110° может выходить ненадолго в «кобре», но он в этом положении неуправляем, может только сам вернуться в нормальный полёт :)
…
Не понтя, скорее, а просто попытка выбить денег на производство.
А потом полученный хеш скормим XSL-процессору :)
…
Хотя, как я выше писал, возможен компромиссный вариант. Базовые параметры (topic_id для темы форума, страницы и прочее) выделяет фреймворк. Далее включается XML-парсер и извлекает из шаблона все нужные ему имена данных, занимается сведением этих данных, загрузкой и скармливанием XSL-процессору.
Будет очень медленно, и с тяжёлым не human-readable синтаксисом.
И только один сомнительный бонус — отсутствие вручную написанного кода загрузки данных в контроллере. Но это итак обычно только несколько строк :)
Например, использовать унифицированную систему именования полей объектов. Тогда {$x->title()} будет работать для всех объектов :)
А если от объекта требуется индивидуальный рендеринг — то шаблончик может храниться при нём, а отдаваться по тем же полям — {$x->body()}. При этом body() может заниматься массой умных вещей, вплоть до вопросов кеширования.
Что в этом примере, что у меня — запросов будет только два. На запросах выигрыша нет. Паритет.
По сложности восприятия на уровне низкого вхождения у меня явно проще, на высоком уровне при грамотной реализации вариант PageDOM возможно, будет проще. Хотя даже это не факт. Но пусть будет паритет :)
По скорости PageDOM потребует намного больших вычислений, что в случае PHP весьма накладно. Тут PageDOM в минусе.
Итого, получается чистый минус :)
Это реально реализовать только через что-то типа XML. Так что тогда мешает сразу делать XML-шаблоны и парсить их любым штатным XSL-процессором? :) Хоть в HTML, хоть во что-то ещё?
…
Но, ИМХО, это лишняя сущность.
>Главная беда большинства современных CMS — они мыслят на уровне HTML
За других не скажу, но у меня не важно, какой у объекта template_engine. Можно сделать и самоизвлекающий нужные данные XML. На практике фреймворк «мыслит» в сущностях HTML, PNG/GIF/JPEG, XML+RSS.
Но, с другой стороны, а почему бы и в сущностях HTML сразу не мыслить? Если это 99% рынка, а такое сужение позволяет существенно упростить разработку, повысить скорость, гибкость, а кое-где и чистоту MVC?
Есть реальные плюсы у чисто объектного описания документа, перекрывающие массу минусов?
Что такое «обычный самолёт»? Судя по кабине, это что-то на базе Як-18Т. Критического угла атаки для него в РЛЭ не нашёл, но он явно больше 13° :) Скорее всего что-то под 20°.
Если же брать современные пилотажки, то у тех же Су-31 управляемость сохраняется практически во всех режимах полёта.
Авиация военная — ещё интереснее. 4-е поколение (МиГ-29, Су-27) летает на углах атаки до 24..26°
Як-130 управляется на углах атаки до 42°
F-22 устойчив на углах атаки до 60°
Су-30МКИ управляем на любых углах атаки ±180°