Как народ конструирует свой PHP-фреймверк, чтобы кодить "как на обычном языке прогр"?

[xintrea]

Как народ конструирует свой PHP-фреймверк, чтобы кодить "как на обычном языке прогр"?

Как народ конструирует свой PHP-фреймверк, чтобы кодить "как на обычном языке программирования"?


Здравствуйте!


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

А хотелось бы понять вот что. Как построить свой фреймверк так, чтобы можно было прогать "как на обычном языке программирвания"? Ну, то есть, чтоб не замечать, что страница открыта заново с какими-то GET-параметрами, POST-данными, данными в сессиях... Чтобы данные в сессиях не приходилось чистить вручную при их ненадобности. То есть, чтобы абстрагироваться от этих веб-особенностей.

У меня при создании веб-приложения все время получается такой порочный круг:

- Формируем HTML с возможными URL, куда может перейти пользователь
- Запишем какие надо данные в сессию
- Показываем пользователю HTML, ждем его действий
- По совокупности состояний GET/POST/Сессий выясняем, что сделал пользователь
- Реализуем реакцию на действия пользователя
- Переходим к первому пункту

Этот цикл очень неестественен, хотя бы потому, что если в действиях пользователя происходит ветвление (пользователь может нажать "Далее", а может нажать какой-нить "Выбор из списка"), то получается, что будут вызваны разные контроллеры, и эти разные контроллеры должны правильно среагировать на предыдущее состояние программы, извлекаемое из GET/POST/SESS.

Получается, что контроль логики размывается по контроллерам, и приходится следить в нескольких разных (инкапсулированных!) местах кода за одними и теми же данными GET/POST/SESS. И если что-то в программе меняется (например добавляется/удаляется/переименовывается GET/POST/SESS переменная), надо прыгать по всем контроллерам, чтобы состыковывать эти изменения и обеспечить правильную логику. Такой процесс меня очень не радует.


Посему хочу услышать мнения профи, какую структуру фреймверка вы применяете, чтобы не долбаться, как я?

 

[Духовность™]

Ничего нового нет и не услышите. Везде одно и то же взаимодействие клиент-сервер, те же механизмы - куки как часть протокола и сессии, как возможность PHP.

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

 

[xintrea]

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

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

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

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

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


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


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

 

[pilot911]

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

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

 

[xintrea]

А я как раз пишу универсальное решение.

 

[pilot911]

ну попробуй, может получится сделать красиво и легко расширяемо

 

[zerkms]

pilot911
забыл тег <irony> ;-)

 

[440hz]

А я как раз пишу универсальное решение.

господи... исче один..

 

[С.]

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

И зачем это учитывать? Сабмита формы от туда все равно не будет. А даже и если, то возврашяться туда было бы глупо.

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

 

[Alexandre]

лично я стараюсь юзать ООП, не в том смысле, что использую классы, а именно ООП, корторое помогает объектно мыслить.

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

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