Класс для рисования форм - нужен ли?

[Phristen]

jonjonson
Ну так в чём проблема?
Если админ, то рисуем форму, если гость, то рисуем обычный текст. На один if всяко уйдёт меньше места чем на две страницы кода для валидации.

P.S. К тому-же, это не аргумент против универсального форм-класса. Если получается, что с универсальным классом нельзя что-то осуществить, значит он недостаточно универсален В данном случае можно добавить классу field аттрибут "editable". Потом делаем нечто вроде

$form->setEditableAttributes($account == "admin")

, и все довольны Код конечно утрирован, но смысл такой.

 

[jonjonson]

Phristen, я пытаюсь поставить акцент на том, что форма - это набор тэгов. Параметры POST и GET запросов - к этим тэгам никакого отношения не имеют. И все униферсальные два в одном валидаторы+рисователи форм - это нечто притянутое за уши.

Отдельно рисовалку и отдельно валидатор воспринимаю нормально. Хотя в большинстве случаев рисовалка избыточна.

И последний ваш пример вообще ужас. Рисовалка ничего не должна знать о правах пользователя. Она должна просто рисовать.
Валидатор ничего не должен знать о том, как будут данные отображены.
Мало того, модель может не принять изменение данных и вернуть имя пользователя указанное до исполнения.

 

[Phristen]

Мой последний пример здесь чисто для примера. (извиняюсь за каламбур)
На самом деле, перед тем как писать какую-то функцию надо всё как следует обдумать (7 раз отмерь, один отрежь). Я вообще к тому, что в случае надобности, такие фичи как разделение админского и гостевого вида воплотить несложно. И разумеется, функция setEditableAttributes, если в ней возникнет такая нужда, будет вызываться не из рисовального модуля, а из валидационного. Уже потом рисовалка нарисует что надо, полагаясь на полученные оттуда (из валидационного модуля) данные.

Отдельно рисовалку и отдельно валидатор воспринимаю нормально

А я о чём!
Как раз сейчас я пишу отдельный класс, который будет рисовать формы. Однако не считаю, что он избыточен.

P.S.

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

А вот для этого и существуют шаблоны

 

[jonjonson]

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

-~{}~ 16.01.07 16:10:

А вот для этого и существуют шаблоны

Следовательно вы отказываетесь от рисовалки форм?

 

[boombick]

Автор оригинала: Observer
Странное мнение... С теми сайтами (или их пользовательскими частями) где форм немного и они могут быть оформлены по-разному, все ясно, но если форм >50 (багтрекер, CMS), полей может быть много и при этом их оформление должен быть одинаковым, то это по-вашему чисто проблемы верстальщика?

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

 

[Invizz]

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

 

[Bermuda]

Invizz
Правильных выхлоп не нуждается в контроле. Правильность зависит от реализации.

А давайте вспомним сколько строк кода стоит вывести простой select или radiobutton. Я уже молчу про AJAX. Почему молчу? Потому, что в некоторых рисовальщиках форм поддержка AJAX включается/выключается одной строкой, а не килобайтными извращениями.

А скудость элементов форм тоже мало кого волнует? Вот например такая стандартная для пользовательского интерфейса фича как драг-н-дроп. Ну или сортировка списков. Календарь? Модальный диалог (кроме конфирм)? Дерево? Постраничный вывод? Реализовывать все это с нуля и для всех браузеров это конечно героический труд. Только боюсь никто не оценит.
Эх... любители блокнота...

-~{}~ 16.01.07 09:26:

А вот для этого и существуют шаблоны

Автор оригинала: jonjonson
Следовательно вы отказываетесь от рисовалки форм?

А на основании какого факта, вы полагаете, что использование шаблонов и рисовалки форм вещи несовместимые?

 

[Invizz]

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

"поддержка AJAX включается/выключается одной строкой" это, извини меня, не аргумент, а херня. Если даже сделать скидку на употребление это избитого термина в его избитом, неправильном значении, можно напомнить, что этот самый аякс - всего лишь яваскрипт. И все зависит от методов, которые ты сам выбрал. Можно форму просто сериалайзить яваскриптом и слать, как обычную, нахера спрашивается тут одна строчка?

Какой, блин, драг н дроп? при чем тут драг н дроп? о чем речь, о формах или о чем?

Да и никоим образом он не относится к теме, драг н дропу не нужны твои рисовалщики форм вообще.

Какие сортировки списков? Списки можно и вручную нарисовать и нацепить скрипт сверху.

ПОСТРАНИЧНЫЙ ВЫВОД..?

Это первое сообщение за две недели которое меня возмутило своей дилетантиской узколобостью

 

[Bermuda]

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

Кстати, а зачем вы поете песни яваскрипт?
Мне не нужен яваскрипт. Я не пишу программы на явыскрипте. Я лишь хочу сортировать списки, а также хочу чтобы комуникация между пользователем происходила быстро и удобно. Для этого мне не нужно использовать яваскрипт. Мне вообще по барабану как это будет работать, на яваскрипте или на керосине. Признаюсь, я до сих пор не знаю как работает AJAX, но тем не менее его успешно применяю.

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

 

[Solid]

Использование классов для отрисовки форм -- усложнение, торможение кода без веской на то причины. Хотя, qCodo интересная идея... но я всёравно против такой практики. Язык гипер-текста и так достаточно прост...

 

[Bermuda]

Solid
Возможно и торможение, но могу точно сказать, что не усложнение, а в большинстве случаев упрощение. За увеличение скорости разработки приходится платить производительностью, с этим никто не спорит.

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

 

[Solid]

Кстати, BXML хорошая идея... можно с лёгкостью использовать widget'ы, о которых говорит, Bermuda... но тем не менее это не совершенная идея... есть куда стремиться.

PS. Не только торможение кода, но и усложнение (покрайней мере это касается QuickForm)

 

[Bermuda]

Автор оригинала: Solid
Кстати, BXML хорошая идея...

Где посмотреть реализацию?

но и усложнение (покрайней мере это касается QuickForm)

В QForm (не путать с QuickForm) такой проблемы нет. Взгляните на пример с калькулятором приведенный выше. На мой взгляд несложно.

 

[Invizz]

Bermuda
именно потому что "не знаю о чем говорю", говорите много и не по делу

 

[Solid]

Bermuda
http://backbase.com/
QForm мне тоже не очень нравится (ограничения)... хотя идея, как я уже написал выше, интересная, особенно в плане переключения Server/Client.

 

[Bermuda]

Invizz
Не тебе меня учить.

 

[Фанат]

давайте завязывать с обсуждением, кто по какому делу говорит =)

-~{}~ 16.01.07 12:31:

Взгляните на пример с калькулятором приведенный выше.

какой из примеров имеется в виду? Исходный код класса View идеологии MVC - этот?

 

[Bermuda]

Автор оригинала: Solid
QForm мне тоже не очень нравится (ограничения)

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

Solid, а какие еще ограничения мешают? Интересно мнение.

-~{}~ 16.01.07 10:38:

Автор оригинала: Фанат
давайте завязывать с обсуждением, кто по какому делу говорит =)

А он первый начал

какой из примеров имеется в виду? Исходный код класса View идеологии MVC - этот?

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

 

[Solid]

Bermuda
Ограничения: многое не известно, скрыто. Например, есть ли прямой доступ ко всем данным, которые будут применены в шаблоне?

-~{}~ 16.01.07 11:43:

Больше ничего не буду говорить, т.к. Фанат прав; тема уже пошла не в ту сторону.

 

[Фанат]

А он первый начал

смешная шутка. но меня она раздражает.

Также взгляните на используемый в примере шаблон.

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