Добрый день, коллеги, гуру, начинающие и все, кто на заднем ряду!

Вероятно эта тема покажется вам странной, но всё же: побудьте, пожалуйста, моей доской!  ;) 
Предыстория: работал с людьми и, в процессе обсуждения проблем, рождалось много нового и интересного, сейчас работаю один и мой разум завел меня в некий тупик.

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

Итак, немного об общей задаче: разработка движка системы управления контентом (CMS). Есть полуготовое ядро системы, решает вопросы со страничками сайта, админкой, настройкми, базой и пр. Функционал системы дополняется модулями - точнее, так уж сложилось, пакетами расширения, которые могут включать в себя модули (отвечают за представление данных определенной страницы или страниц - основной контент), виджеты (размещаемые в произвольных местах "куски контента" представляющие ту или иную инфу) и плагины (название конечно не очень-то подходящее, но сие подключается при запуске системы, при выполнении определенных условий и производит НЕЧТО, что пользователь не видит).
Чтобы было понятнее приведу пример, ммм... допустим пакет "Новости" - есть модуль просмотра списка новостей постранично, модуль просмотра выбранной новости, модуль добавления новости - это все отдельные страницы (с отдельными адресами), типа /news/, /news/view/654/, /news/add/
Виджетом может быть блок типа "пять последних новостей" или "случайная новость"... думаю, понятно к чему я
Плагинов в пакете "новости" нет  : 

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



Как-то так   

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

Так вот, не хочется по сто раз писать валидацию данных форм, но хочется и назначать полям "особые" валидаторы. С другой стороны не хочется, чтобы формы было запарно описывать, т.е. минимум движений (ах, мечты, мечты)

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

По-сути, самое замороченное - это механизм определения что нам пришло и что с ним делать =)
Т.е. либо прописываем в самой форме откровенный изврат типа хиденнов - class=>clsMyForm 
либо учим движок узнавать формы или по странице или по ID
дальше надо как-то получить какие поля и как их проверять
и какому обработчику отдать на съедение

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

Для чего я это всё написал и что я хочу получить?
Мне нужно живое обсуждение, надо расшевелить сознание =)
Спрашивайте, уточняйте, давайте советы, приводите свои подходы, рассказывайте как у вас получилось, а как нет, даже если вы ничего не поняли из того, что я написал 
Очень нужна помощь! В долгу не останусь, участвующим и сочувствующим в благодарность помогу словом или делом, в зависимости от степени участия =)

Ну что ж, давайте пообщаемся  . 
Я вот что предлагаю, сделать во-первых класс для формы:

Ну и собственно остается создать абстрактный класс элементов форм
И от него унаследовать разные типы элементов форм.

Проблема с валидацией ,с моей точки зрения, решена. Если мы не передаем в функцию Add значение для $validation_function, то будет использоваться функция по умолчанию для конкретного класса элемента формы. Например для класса реализующего элемент "текстовое поле", логично по-умолчанию проверять просто на пустое значение. Но например если мы его используем для e-mail, тогда просто создаем глобальную функцию проверки e-mail и передаем ее название в функцию Add класса form.

Собственно мое виденье таково и эту идею я буду использовать в своем framework)

Спасибо за участие, но немножко не то.
Остается очень много не решенных вопросов:
где и кем будут создаваться экземпляры класса form, кто и на основании чего будет производить вызовы метода "Add", как система узнает, что именно "эта" форма была получена на валидацию и пр.

В пределах простой страницы, да, такое решение прокатит, единственное, что я бы сделал более изящное описание полей - в виде массива, т.к. могут быть не только поля с name=>value, а есть и селекты, и чекбоксы и радио-кнопки, плюс могут сильно пригодиться и другие свойства формы

вот так у меня сделано на данный момент:


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

Так ну тогда давайте разбираться. У вас ведь функционал расширяется с помощью модулей, тогда почему нельзя создавать объект формы прямо в модуле, проверку выполнять там же, т.к функция проверки встроена в класс формы? Вообщем напишите поподробнее в чем ваша загвоздка и какие требования вы предъявляете к формам, чтобы мы понимали друг друга)

Все, что вам нужно, и даже более того, можно найти в готовом виде. Symfony, а точнее его форм-фреймворк. Его можно использовать отдельно, а можно в составе системы. Что даст возможность большинство работы свести к работе с объектами. Т.е. через ORM (Doctrine) работать с БД, запись в базе - это объект, с которым можно работать без всяких SQL (в большинстве случаев), например так:


А с формами тоже просто, вот как производится обработка полученной формы:


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

Это сообщение отредактировал(а) KLeonid - 22.3.2011, 02:23

На самом деле, вопрос весьма актуален. Я тоже веду разработку собственной CMS и вот как я решил это. Мне правда не особо нравится. Но все же.
У меня есть два типа модулей: модули-виджеты (блоки новостей, контента, товаров и пр.) и модули-акторы.

Было принято решение, что весь код формы рисуется в шаблоне, который отображается модулем-виджетом. Принятие формы осуществляется модулем-актором. То есть для каждой формы грубо говоря два модуля, если нужно. Иногда форму можно вставить прямо в шаблон какого-нибудь другого модуля и послать на обработку модулю-актору. Модуль-актор отрабатывает в режиме redirect или в режиме ajax, это неважно. Он посылает данные обработки формы: они выводятся в XML- или JSON-формате для ajax, либо рисуются на странице редиректа. В любом случае обработка происходит не на том же запуске кода, который собсно вырисовывает сайт.