Включение в модель правил генерации элементов интерфейса

[QQQ]

Включение в модель правил генерации элементов интерфейса

Поясню на примере типовой задачи. Допустим в БД есть таблица (Table) с некоторым набором полей и данных. На сайте имеем следующие интерфейсы для доступа к этой таблице:

1) html форма добавления строки в Table
2) html форма редактирования строки Table
3) html таблица выводящая все строки Table


Формы храняться в виде массива/объекта, включающего название формы, набор полей формы, с их названиями, правилами валидации, и т.д.

Для html таблицы храняться названия столбцов, правила отображения ячеек, и т.д.


По сути имеем три набора данных:
1) Таблица БД (Table)
2) Массив с правилами построения и проверки формы
3) Массив с правилами построения html таблицы


Собственно вопрос: насколько корректным, с точки зрения MVC, будет включать правила отображения форм (по сути одной формы, они идентичны) и html-таблицы в модель Table? То-есть чтобы модель, помимо данных, возвращала бы ещё и правила построения/валидации элементов интерфейса? Или всё-таки лучше не мешать одно с другим?


Сорри, если многа букаф, попытался объяснить как мог.

 

[FB3]

Я бы не стал совмещать.
ИМХО, как только функциональность начнет усложняться, у класса будет слишком много обязанностей.

 

[dimagolov]

QQQ, у тебя нет таблицы, которую нужно редактировать. У тебя есть сущность, которая храниться в таблице и которую нужно редактировать.

если ты, конечно, не пишешь еще один phpMyAdmin

 

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

Модель НИЧЕГО не должна знать о каких-то там html-формах.

насколько корректным, с точки зрения MVC, будет включать правила отображения форм (по сути одной формы, они идентичны) и html-таблицы в модель Table? То-есть чтобы модель, помимо данных, возвращала бы ещё и правила построения/валидации элементов интерфейса?

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

 

[QQQ]

dimagolov просто не так выразился

triumvirat тут дело в том, что это не совсем представление. Это объект, в котором прописаны правила, в соответствии с которыми должны быть представлены входные данные. Да, используя его можно сгенерировать html форму, но в первую очередь это правила валидации данных. Даже если они придут не из формы, а из парсера например какого-нибудь (я для примера)

 

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

Да, используя его можно сгенерировать html форму, но в первую очередь это правила валидации данных

это уже другая тема,в соседней ветке как раз это обсуждается.

 

[MiksIr]

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

 

[QQQ]

MiksIr

"это число нужно выводить в ячейке красного фона"

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

 

[MiksIr]

Автор оригинала: QQQ
MiksIr
А факт выделенности? Например флаг важной колонки? А что фон должен быть красный для важных колонок - это уже дело представления.

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

 

[QQQ]

MiksIr
Вот тут я полностью соглашусь.


А по сабжу - прихожу к выводу, что скорее можно, чем нет