Дело не в ORM. А в том, что без строгого описания того, что нам нужно, не важно, будет это сделано в шаблоне или в параллельном коде, нельзя гарантировать нужные данные или отсутствие ненужных загрузок на более чем одном уровне зависимости.
В общем, я пока вижу, что ты просто не сталкивался с этой проблемой на практике. Столкнёшься — продолжим обсуждение :) Хотя, сам же ты говоришь, что вопрос это пока для тебя сугубо теоретический, а не практический. Вот когда дойдёт до практики — тогда и увидишь, в чём тут проблема :)
Угу. И Post ответчит всех юзеров. Юзеры отфетчат свои последние посты. Посты отфетчат топики. Топики отфетчат новые постинги. И так — много раз подряд.
…
Нет, нам явно нужно указать что нам нужно. Всю БД фетчить мы не можем.
Или ты считаешь, что User должен различать, откуда дёргают дёргающий его Post? :)
У угла атаки есть совершенно строгое и не допускающее разночтений определение. Угол атаки у Су-27 в «кобре» — до 110°.
Но — да, в этом положении машина неуправляема. Всё, на что она способна — самостоятельно (за счёт особенностей конструкции) выйти из этого положения в нормальный полёт через секунду-другую после заброса.
Просто кроме понятия угла атаки вообще, есть понятие максимального или критического угла атаки — за которым происходит срыв машины. У Су-27 это 25-26°.
То, что на фото, с Ан-2 никак сравниться не может.
Начать можно с того, что в Ан-2 влезает 2 пилота и 11 парашютистов в полном снаряжении ;) Посмотри на кабину сабжа. Там помещается два человека _всего_. Поэтому и сравнивать его надо с ближайшим аналогом, Як-18Т. У которого, кстати, и морда практически такая же:
А вот Ан-2 для сравнения:
На кого больше похож тот, что является героем темы? ;)
Пардон, но у нас задача стоит не выводить профиль пользователя, а вывести его имя в заголовке сообщения. И, например, статус этого пользователя на форуме.
Пример фабрики непонятет. Где там указание на извлечение нужных полей данных пользователя? Скажем, нам нужны поля имени пользователя и его статуса на форуме, но не нужны его репутация и штрафы от администрации, которые, в случае если извлекать всё, будут генерировать новые запросы в соответствующие таблицы БД.
Если подходить к вопросу как «выдернем список постов. Посты зависят от юзеров. Выдернем всех связанных юзеров.», то неизбежно продолжение: «юзеры зависят от штрафов от модераторов, штрафы от модераторов cодержат ссылки на модераторов как пльзователей, у пользователей-модераторов есть последние сообщения, последние сообщения принадлежат топику, топик состоит из других сообщений........» :) И мы скоро выдернем всю БД.
Значит надо как-то описывать, что нам нужно в этом конкретном случае, а что — нет. В запросе my $posts = Post->select($condition); такого указания нет.
>если почитаете release notes для SP3, то заметите что каких-то очевидных изменений в ядро ОС не вносит, а 2.6 за 5 лет потолстело на 4 млн строк кода.
Разница в подходе. В Windows драйвера поставляют сторонние разработчики, в Linux 90% их приходится совать в ядро. Если не считать драйверов устройств и файловых систем, то в Linux-ядре в том же контексте, что и в Windows XP, за это время тоже крайне мало изменений.
Контроллер имеет практически минимальный для своего функционала размер :) Он слишком много тонкостей учитывает. Как я уже говорил, код далеко не под один проект заточнен (сейчас мною поддерживаемых один некоммерческий, штук пять коммерческих, ещё два в разработке — и почти в каждом случае масса своей специфики) — это накладывает отпечаток.
Вообще, система изначально была микроядерной с рядом разного калибра расширений. Нынешний объектный контроллер был только одним из вариантов. Потом однажды я понял, что за целый год всё новое писал только на нём и, таким образом, его функционал и расширяемость меня полностью удовлетворяет. В итоге ядро было переписано с интеграцией объектного расширения прямо в него. А старый код — частично переписан на объекты, частично пока ещё крутится на старой системе.
На размере сказывается и то, что ядро фреймворка полностью автономно во всех проектах, а расширения пишутся в отдельных группах каталогов. Это тоже несколько усложняет загрузку.
Ну и ещё масса чёрной работы по связыванию компонентов с классов вынесена в контроллер. Скажем, нужно искать представление рядом с файлом модели. Шаблон рядом с классом. Когда-то в каждом классе была строка function class_file() { return __FILE__; } Несложно, но это лишняя строка. И почти в каждом классе. Сейчас этим озабочен контроллер. Когда-то родителей объекта требовалось обязательно указывать методом parents(). Но в 90% случаев родитель только один и является надкаталогом в URL. Сейчас, если так, этим заведует тоже контроллер. И т.д. и т.п. :)
А зачем, вообще, модуль что-то должен возвращать контроллеру? Это снижает гибкость, автономность и расширяемость. Скажем, потребуется у одного модуля сменить представление на использующее другой механизм. Например, шаблонизатор со Smarty перевести на XML или чистый PHP.
В твоём случае, как я понимаю, при наличии другого шаблонизатора, требуется обучить этому контроллер. Но если оторваться от одной только идеологии MVC, то в рамках объектной парадигмы, какждый объект о всех своих механизмах должен заботиться сам. Принцип «не спрашивай, приказывай». В рамках этой модели контроллер не должен спрашивать, каким шаблонизатором пользуется модель, а отдавать ей команду отрендериться.
У меня так и делается. Контроллер по ссылке находит нужную модель. В модели прописан тип рендеринга, которым она пользуется для представления. Т.е. задача контроллера состоит только в том, чтобы найти соответствующий ссылке объект, запросить у этого объекта его контент и отдать результат запросчику (в частности — браузеру).
Модуль=объект=модель уже имеет в себе описания всего, что нужно дальше. Механизм рендеринга объекта в целом (картинка это, RSS-фид или конкретный глобальный шаблон HTML-страницы, например), механизм рендеринга контентной части в случае HTML-страницы, бэкенд данных, если требуется ORM, описание модели ORM если нужно. В общем, все требуемые данные.
И замена отлаженного Smarty-шаблона на более быстрый, но менее удобный в отработке pure-PHP субшаблон будет заключаться (кроме, собственно, переписывания шаблона) в написании/замены только одной строчки в классе — собственно, указания на класс рендеринга. Контроллеру же эти тонкости до лампочки. Он не спрашивает, он приказывает :)
Но мне интересен той вариант. Именно — как ты собираешься описывать зависимости.
Видишь ли, мне почему-то кажется, что ты не сможешь не дублировать зависимости в дереве дважды. В описании выборки и в шаблоне-описателе. Либо придётся парсить шаблон. Именно поэтому я так и прошу тебя привести пример конкретного описательского кода, который позволит вывести список сообщений топика форума с указанием имён пользователей :) Это очень простой пример.
>Надо проще =) больше классов, методов, меньше по размеру методы
Видимо, ты порылся в контроллере. Типичный класс на конечном проекте — это несколько строк. Иногда буквально 3-4 строки :) Но такое чаще в админке, например, вывести постраничный список объектов для редактирования:
Модель:
<?php
class aviaport_admin_directory_person_main extends base_page_paged
{
function main_class() { return 'aviaport_directory_person'; }
function title() { return ec('Персоны'); }
}
В том, что отдаётся юзеру, конечно, классы уже побольше. Там надо заниматься настройками, обвязками, конфигурированием… Итого размер актвных рабочих классов колеблется от 500 байт до пары-тройки килобайт.
>Но представление не должно извлекать данные само.
Так оно и не извлекает ничего. Оно обращается к методу класса.
Грубо говоря, {$post->user()->title()}.
Извлечение своих данных — это головная боль самого класса. И это правильный подход. Все внутренние процессы должны быть инкапусированы. Неважно, берётся этот title() из БД, или формируется как first_name().' '.last_name(). Это вопрос класса.
Как ты на уровне кода видишь описание формирования дерева в модели (меня тут правильно поправили, я тормозил и модель обзывал контроллером ;) )? Грубо, чисто как концепт?
Давай тогда лучше к конкретике. А то, боюсь, мы уже просто разные вещи обсуждаем. Какой плагин можно прикрутить к описываемой системе, но он будет костылём в простой системе хеш — шаблон?
В общем, я пока вижу, что ты просто не сталкивался с этой проблемой на практике. Столкнёшься — продолжим обсуждение :) Хотя, сам же ты говоришь, что вопрос это пока для тебя сугубо теоретический, а не практический. Вот когда дойдёт до практики — тогда и увидишь, в чём тут проблема :)
…
Нет, нам явно нужно указать что нам нужно. Всю БД фетчить мы не можем.
Или ты считаешь, что User должен различать, откуда дёргают дёргающий его Post? :)
Но — да, в этом положении машина неуправляема. Всё, на что она способна — самостоятельно (за счёт особенностей конструкции) выйти из этого положения в нормальный полёт через секунду-другую после заброса.
Просто кроме понятия угла атаки вообще, есть понятие максимального или критического угла атаки — за которым происходит срыв машины. У Су-27 это 25-26°.
Начать можно с того, что в Ан-2 влезает 2 пилота и 11 парашютистов в полном снаряжении ;) Посмотри на кабину сабжа. Там помещается два человека _всего_. Поэтому и сравнивать его надо с ближайшим аналогом, Як-18Т. У которого, кстати, и морда практически такая же:
А вот Ан-2 для сравнения:
На кого больше похож тот, что является героем темы? ;)
Пример фабрики непонятет. Где там указание на извлечение нужных полей данных пользователя? Скажем, нам нужны поля имени пользователя и его статуса на форуме, но не нужны его репутация и штрафы от администрации, которые, в случае если извлекать всё, будут генерировать новые запросы в соответствующие таблицы БД.
Если подходить к вопросу как «выдернем список постов. Посты зависят от юзеров. Выдернем всех связанных юзеров.», то неизбежно продолжение: «юзеры зависят от штрафов от модераторов, штрафы от модераторов cодержат ссылки на модераторов как пльзователей, у пользователей-модераторов есть последние сообщения, последние сообщения принадлежат топику, топик состоит из других сообщений........» :) И мы скоро выдернем всю БД.
Значит надо как-то описывать, что нам нужно в этом конкретном случае, а что — нет. В запросе my $posts = Post->select($condition); такого указания нет.
Давай дальше развивать твой пример :)
Ну вот. А 2.6 — 2003-й. Не так и принципиально :)
>если почитаете release notes для SP3, то заметите что каких-то очевидных изменений в ядро ОС не вносит, а 2.6 за 5 лет потолстело на 4 млн строк кода.
Разница в подходе. В Windows драйвера поставляют сторонние разработчики, в Linux 90% их приходится совать в ядро. Если не считать драйверов устройств и файловых систем, то в Linux-ядре в том же контексте, что и в Windows XP, за это время тоже крайне мало изменений.
У разных сообщений — разные пользователи.
Тебе нужно указывать зависимости.
Эта задача не такая тривиальная, как тебе, возможно, кажется на первый взгляд.
Я поэтому и прошу конкретный пример описания простейшей структуры:
Топик -> множество постингов -> пользователи.
Именно то, как ты будешь описывать эту модель в конкретном проекте.
Пример нужен, чтобы ты почувствовал разницу между примитивной идеей и её формализацией.
Увы, на словах и в мыслях часто многие вещи поначалу кажутся намного проще, чем оказывается, когда дело доходит до практики :)
А если смотреть по корням, то ядро 2.6 в Linux вышло ещё в 2003 году.
Вообще, система изначально была микроядерной с рядом разного калибра расширений. Нынешний объектный контроллер был только одним из вариантов. Потом однажды я понял, что за целый год всё новое писал только на нём и, таким образом, его функционал и расширяемость меня полностью удовлетворяет. В итоге ядро было переписано с интеграцией объектного расширения прямо в него. А старый код — частично переписан на объекты, частично пока ещё крутится на старой системе.
На размере сказывается и то, что ядро фреймворка полностью автономно во всех проектах, а расширения пишутся в отдельных группах каталогов. Это тоже несколько усложняет загрузку.
Ну и ещё масса чёрной работы по связыванию компонентов с классов вынесена в контроллер. Скажем, нужно искать представление рядом с файлом модели. Шаблон рядом с классом. Когда-то в каждом классе была строка function class_file() { return __FILE__; } Несложно, но это лишняя строка. И почти в каждом классе. Сейчас этим озабочен контроллер. Когда-то родителей объекта требовалось обязательно указывать методом parents(). Но в 90% случаев родитель только один и является надкаталогом в URL. Сейчас, если так, этим заведует тоже контроллер. И т.д. и т.п. :)
В твоём случае, как я понимаю, при наличии другого шаблонизатора, требуется обучить этому контроллер. Но если оторваться от одной только идеологии MVC, то в рамках объектной парадигмы, какждый объект о всех своих механизмах должен заботиться сам. Принцип «не спрашивай, приказывай». В рамках этой модели контроллер не должен спрашивать, каким шаблонизатором пользуется модель, а отдавать ей команду отрендериться.
У меня так и делается. Контроллер по ссылке находит нужную модель. В модели прописан тип рендеринга, которым она пользуется для представления. Т.е. задача контроллера состоит только в том, чтобы найти соответствующий ссылке объект, запросить у этого объекта его контент и отдать результат запросчику (в частности — браузеру).
Модуль=объект=модель уже имеет в себе описания всего, что нужно дальше. Механизм рендеринга объекта в целом (картинка это, RSS-фид или конкретный глобальный шаблон HTML-страницы, например), механизм рендеринга контентной части в случае HTML-страницы, бэкенд данных, если требуется ORM, описание модели ORM если нужно. В общем, все требуемые данные.
И замена отлаженного Smarty-шаблона на более быстрый, но менее удобный в отработке pure-PHP субшаблон будет заключаться (кроме, собственно, переписывания шаблона) в написании/замены только одной строчки в классе — собственно, указания на класс рендеринга. Контроллеру же эти тонкости до лампочки. Он не спрашивает, он приказывает :)
Но мне интересен той вариант. Именно — как ты собираешься описывать зависимости.
Видишь ли, мне почему-то кажется, что ты не сможешь не дублировать зависимости в дереве дважды. В описании выборки и в шаблоне-описателе. Либо придётся парсить шаблон. Именно поэтому я так и прошу тебя привести пример конкретного описательского кода, который позволит вывести список сообщений топика форума с указанием имён пользователей :) Это очень простой пример.
Видимо, ты порылся в контроллере. Типичный класс на конечном проекте — это несколько строк. Иногда буквально 3-4 строки :) Но такое чаще в админке, например, вывести постраничный список объектов для редактирования:
Модель:
<?php class aviaport_admin_directory_person_main extends base_page_paged { function main_class() { return 'aviaport_directory_person'; } function title() { return ec('Персоны'); } }Представление:
<div class="all-docs"> <ul> <li><a href="new/"><b>Добавить персону</b></a></li> </ul> </div> {$this->pages_links('all-docs')} <table class="btab w100p"> <tr><th>ID</th> <th>Персона</th> </tr> {foreach from=$items item="x"} <tr><td>{$x->id()}</td> <td>{$x->titled_admin_url()}</td> </tr> {/foreach} </table>В том, что отдаётся юзеру, конечно, классы уже побольше. Там надо заниматься настройками, обвязками, конфигурированием… Итого размер актвных рабочих классов колеблется от 500 байт до пары-тройки килобайт.
По числу классов… Ядро:
$ find /home/balancer/work/programming/php/bors-core/ -name '*.php' -exec cat {} \;|grep -P '^class \w+'|wc -l99
Надо ещё один класс дописать ;)
www.aviaport.ru:
303 класса.
Нормально, куда больше-то? :) Одна сущность — один класс.
2. Тут не примера формирования самой важной сущности — тела доумента. Пусть будет наш пример с телом топика форума.
3. А при чём тут дружелюбные URL и запросы? :) Это же чистый языковый код.
Заполнение хеша, да ещё объектами/хешами, выбираемыми по условиям — это задача нетривиальная в описательном плане.
Вот мне и интересно, как ты это конкретно себе представляешь. Дай небольшой кусок абстрактного кода.
Пока речь о линейной записи — всё хорошо. А дерево? Ну, вот в примере с форумом.
$tree = array( 'data' => array('posts' => objects_arrays_fields('post', <условие>, 'список полей'...))... );А вот как быть в этом случае с загрузкой объектов users, привязанным к posts?
Именно — описание дерева.
Покажи пример на практике.
Принципы построения/подключения модулей — в моём блоге первая запись.
А коммерческие сайты на этом движке — www.aviaport.ru или www.rp1990.ru
Так оно и не извлекает ничего. Оно обращается к методу класса.
Грубо говоря, {$post->user()->title()}.
Извлечение своих данных — это головная боль самого класса. И это правильный подход. Все внутренние процессы должны быть инкапусированы. Неважно, берётся этот title() из БД, или формируется как first_name().' '.last_name(). Это вопрос класса.
Как ты на уровне кода видишь описание формирования дерева в модели (меня тут правильно поправили, я тормозил и модель обзывал контроллером ;) )? Грубо, чисто как концепт?