[Вопрос] А как народ конструирует свой PHP-фреймверк, так чтоб прогать «как на обычном языке программирования»?

На сабжекте мой парсер сломался, так что только по вопросам в тексте.

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

Данные для форм прекрасно хранятся и в сессиях. Ну, или даже тупо из POST/GET-параметров берутся и повторно используются.

Во всех остальных случаях данные, всё же, удобнее хранить в тех же БД или в memcache.

Естественно, что работа со всем этим не ручная, все вопросы связывания, загрузки, кеширования берёт на себя фреймворк.

...

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

> И если что-то в программе меняется (например добавляется/удаляется/переименовывается GET/POST/SESS переменная), надо прыгать по всем контроллерам, чтобы состыковывать эти изменения и обеспечить правильную логику

Явные проблемы с архитектурой. Все зависимости от внешних факторов надо аккумулировать в одном месте и уже оттуда распределять их по реквестам от модулей.

> Протокол HTML

Лютый фейл

> Протокол HTML
Лютый фейл

HTTP, опечатался.

> Все зависимости от внешних факторов надо аккумулировать в одном месте и уже оттуда распределять их по реквестам от модулей.

По-простому объяснить можно? На каком-нить примитивном примере.

Лор колбасит, нажимаем Ctrl+Enter для отправки сообщения.

>По-простому объяснить можно? На каком-нить примитивном примере.

Вот я потому и спрашиваю пример конкретной задачи, чтобы на её примере показать как решение делал бы я в своём фреймворке :)

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

Ну например да, работа с формами.

В форме несколько полей.
Некоторые поля обязательны к заполнению.
Некоторые поля - выбор из справочника (или даже цепочки справочников).

Работа должна вглядеть так:

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

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


Этот код заполнения формы должен работать как сам по себе, например, в режиме ДОБАВЛЕНИЯ одной записи в базу, так и легко срабатывать в режиме РЕДАКТИРОВАНИЯ, когда пользователь выбирает (либо напрямую, либо по цепочке вложений) нужную запись, а потом вызывается вышеописанный код работы с формой.


Как бы ты вот это все реализовал?

> Этот цикл очень неестественен

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

1. виджет-валидатор на обязательные поля. либо, аяксом без рефреша проверять.
2. эмм. что это значит? поподробнее плиз.

> Этот код заполнения формы должен работать как сам по себе, например, в режиме ДОБАВЛЕНИЯ одной записи в базу, так и легко срабатывать в режиме РЕДАКТИРОВАНИЯ, когда пользователь выбирает (либо напрямую, либо по цепочке вложений) нужную запись, а потом вызывается вышеописанный код работы с формой.

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

>Ну например да, работа с формами.

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

Я же прошу привести пример какой-нибудь другой задачи :)

>Как бы ты вот это все реализовал?

Примерно так сейчас работает (на практике сессии не используются):

Каждая форма сопоставляется со своим объектом. Есть формо-генерация на Smarty (в синтаксис вдаваться не буду, но могу привести примеры позже, если интересно). Форма показывается пользователю (если объект формы был не пустым, то показаны значения). Пользователь отсылает данные. Фреймворк делает проверки доступа, нестандартных хэндлеров, предварительную обработку некоторых типичных ситуаций и проверку валидности данных (у каждого объекта есть список условий корректности данных). Если хоть одно условие не проходит, выдаётся диалог с ошибкой. Вот тут может использоваться механизм сессий. Встраивание его вижу так:

1. Опеределяем некий системный признак «была попытка отсылки формы», который по умолчанию сброшен. Взводиться может или через сессии, или прямым флагом, скажем, в автоматическом (т.е. добавляемом фреймворком, а не при описании формы) hidden-поле.

2. Для каждого стандартного элемента формы (input/textarea/select/etc.) делается проверка на этот признак. Если взведён, то в форме рисуем не данные объекта или дефолтовые данные, а значение из предыдущей отсылки данных.

3. Если при обработке объекта возникает ошибка, то не обламываем сообщением об ошибке, а повторно выводим форму.

...

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

>Этот код заполнения формы должен работать как сам по себе, например, в режиме ДОБАВЛЕНИЯ одной записи в базу, так и легко срабатывать в режиме РЕДАКТИРОВАНИЯ

Да, а это у меня итак унифицировано. Для добавления и редактирования используется один и тот же класс-редактор объекта и одна и та же форма.

Давайте аякс оставим за пределами нашего обсуждения. Все должно работать по-деревянному на любом экзотичесвом браузере.


> 2. эмм. что это значит? поподробнее плиз.

Ну, например, есть трехуровневый справочник у какого-нить орифлейма "Страна"->"Город"->"Агент". И есть в форме поле "ID Агента". Нужно дать возможность пользователю последовательно выбрать страну, город, агента, чтобы получить его ID.

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

> Для добавления и редактирования используется один и тот же класс-редактор объекта и одна и та же форма.

А можно увидеть интерфейс этого класса-редактора? Ну или полную реализацию.

Если можно, через на paste.org.ru

А можно увидеть интерфейс этого класса-редактора?

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

1. Есть собственно класс объекта. Ну, скажем, запись какого-то каталога.

2. Есть отдельный админский класс-редактор, который хранится отдельно, является наследником своего же класса объекта, но работает с другим шаблоном, в котором и реализован механизм редактирования.

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

Сейчас же пользуюсь такой моделью.

1 - всё то же самое. Ну, например:

class catalogue_object extends base_object_db
{
    function main_db() { return 'DB'; }
    function main_table() { return 'catalogue'; }
    function main_table_fields() { return array('id', 'title', 'category_id'); }
}

2. Класс-редактор теперь простая страничка:

class admin_catalogue_edit extends base_page
{
    function title() { return $this->id() ? 'редактор объекта' : 'новый объект'; }
()); }
}

И к этому делу прилагается шаблон формы такого вида:

{form class="catalogue_object" id=$this->id()}
Название товара: {input name="title"}<br/>
Категория: {dropdown name="category_id" list="..."}<br/>
{submit value="Сохранить"}
{go value="newpage_admin"}
{/form}

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

{go ...} - это куда сделать редирект после удачного сохранения. Может быть как конкретный URL, так и некоторый из предопределённых макросов.

Ну или полную реализацию.

Весь фреймворк целиком лежит на http://hg.balancer.ru под GPL.

Документации, как это часто бывает в таких проектах нет. Предполагаю понемногу писать её на http://bors.balancer.ru/ , но пока нет стимула :)

Конкретно по формам. Код некоторых Smarty-плагинов: http://hg.balancer.ru/hgwebdir/bors-core/file/b2dd4c99910b/engines/smarty/plu... http://hg.balancer.ru/hgwebdir/bors-core/file/b2dd4c99910b/engines/smarty/plu... и т.д.

Обработчик сохранения формы: http://hg.balancer.ru/hgwebdir/bors-core/file/b2dd4c99910b/inc/bors/form_save...

>Если можно, через на paste.org.ru

Ну, у меня открытый mercurial-репозиторий с фреймворком. Можно всё скачать скопом :)

...

Чёрт, в LORCODE ссылки автоматом не выделяются сейчас, ну да копипаст тогда поможет. Да и повторить можно для удобства:

http://hg.balancer.ru/
http://bors.balancer.ru/
http://hg.balancer.ru/hgwebdir/bors-core/file/b2dd4c99910b/engines/smarty/plu...
http://hg.balancer.ru/hgwebdir/bors-core/file/b2dd4c99910b/engines/smarty/plu...
http://hg.balancer.ru/hgwebdir/bors-core/file/b2dd4c99910b/inc/bors/form_save...

Завтра посморю, ничо уже не соображаю

На похапе - никак.

Это можно сделать на любом языке с поддержкой континуэйшенов. Схема, Руби, вроде бы Смоллток...

Чота я нигде не русском про континуэйшены в руби не нашел.

>Это можно сделать на любом языке с поддержкой континуэйшенов. Схема, Руби, вроде бы Смоллток...

Еще есть UCW на CL, Ocsigen на Ocaml. Когда последний раз смотрел Seaside на смоллтоке, они уже отказывались от континюэйшнов, правда не помню в пользу чего.

>Чота я нигде не русском про континуэйшены в руби не нашел.

И не надо искать. Начальные реализации были жутко медленными, в 1.9 продолжения вообще выпилили, время от времени обещают вернуть в 2.0. Но лучше считать что в руби их нет)

> в 1.9 продолжения вообще выпилили

Не знал, но не удивлён. Это не язык, а какое-то угрёбище.

>Не знал, но не удивлён.

Ах черт, таки я не прав. Они опять их добавили какое-то время назад и вынесли в отдельный модуль Continuation, и даже поработали над какими-то ошибками. Гхм, ушел смотреть.

> Они опять их добавили какое-то время назад и вынесли в отдельный модуль Continuation

Скажи лучше, кто то в этом мире использовал continuations руби в практических целях?

Я уже сказал о качестве начальных реализаций. Ави Брайант, когда писал свой фреймворк, написал прототип на руби, но работало коряво, он переписал его на няшном Squeak и теперь бегает по конференциям, рассказывая "энтот ваш руби - тоже самое что и ли^W смоллток двадцать лет назад!11".

По поводу практического использования можешь посмотреть тот же веб-фреймворк Wee.

> вроде бы Смоллток

Оттуда и пришло. Seaside, например.

А нет, наврал, первой все же схема была.

Все это велокактусные костыли, такое можно только на языке с continuations.

В очередь!