Post по condition сможет либо сконструировать запрос к профилям, лмбо, что скроее всего, сконструирует User->select(join=>post), либо получит набор ids.
Зависит от удобства ORM.
В любом случае ответственность Post заканчивается чаще всего на получении обьекта-множества UserProfile.
как я уже говорил, блок «вывод профиля пользователя» — это скорее всего в CMS будет отдельный класс узла дерева (умеющий фетчить узлы своего типа).
В случае с фабрикой конструирование дерева будет, например, таким:
my $posts = Post->select($condition);
предположим, что узлы типа Post на этапе fetch инстанцируют дочерние узлы типа UserProfile и Text.
Узлы типа UserProfile на этапе fetch получают данные по профилям.
на этапе рендеринга выходной фильтр HTML использует соответвующий рендере для узлов Post, которые скорее всего делегируют рендеринг профиля подузлу UserProfile, а вовод узлов Text — рендереру markup.
wiki.github.com/pure/pure/iteration-and-attributes
Речь идёт о страницах, скорее являющихся приложениями (простейший пример — магазин).
Кстати, в плане оффтопа замечу, что в том же Google Chrome Javascript включен всегда — это современная тенденция.
Кстати, телефон и адрес заведения оставьте, вдруг оно рядом со мной :)
Основное отличие от прошлого — Sizzle более расширяем и может использоваться отдеьно от jQ.
И, кстати, быстрее ветки jQ 1.2.x.
Пока не нашёл ничего, чего бы не было в jQuery.
P.S.: для истории есть плагины, в Ext.JS так вообще в ядре.
Зависит от удобства ORM.
В любом случае ответственность Post заканчивается чаще всего на получении обьекта-множества UserProfile.
что именно будет отфетчено — детали реализации Post.
Парсинг — забудьте это слово. Это применимо только к тексту/потоку.
В случае с фабрикой конструирование дерева будет, например, таким:
my $posts = Post->select($condition);
предположим, что узлы типа Post на этапе fetch инстанцируют дочерние узлы типа UserProfile и Text.
Узлы типа UserProfile на этапе fetch получают данные по профилям.
на этапе рендеринга выходной фильтр HTML использует соответвующий рендере для узлов Post, которые скорее всего делегируют рендеринг профиля подузлу UserProfile, а вовод узлов Text — рендереру markup.
Идея у меня примитивная, я ен понимаю, какие примеры нужны.
Естественно, более высокого уровня, в частности markup code — это просто тип узла дерева, без объектности на уровне разметки (в CMS она не нужна).
Плюсов несколько:
* пакетная обработка, как вы заметили
* удобство встраивания сторонних модулей (плагинов), котроые могут модифицировать дерево (это удобнее, чем модифицировать разметку).
* Легкость добавления новых форматов вывода.