Комментарии 26
Заранее извиняюсь за то, что не привожу полную статью прямо здесь, тому есть объективные причины. Надеюсь вам не составит особого труда кликнуть по ссылке.
в очередной раз бьюсь головой о земь, дабы высказать свое восхищение трудами Вашими, гуру!
Очень полезно!
Спасибо за статью. Полезно, да и вообще давно drupaldance читаю — отличный сайт
Я вот тоже очень хочу всем порекомендовать сайт drupaldance, отличный ресурс для начинающих
Неплохо… Но информации по этой теме по-моему и так полно, вот написать бы как создавать чисто отдельные элементы формы (без генерации всей формы), использовать все это дело вместе с ajax и т.п. :) Было бы еще круче. :)
легко. кто вам мешает простые формы добавлять и обрабатывать их тем же jQuery?
Ну, вообще, я имел ввиду не целые формы, а отдельные элементы формы и создание их при помощи forms api + яваскрипт для всяких штук. :)
никак не уловлю проблему.
в статье описано создание элементов форм, а js обработчик на них повесить дело 5 минут.
в статье описано создание элементов форм, а js обработчик на них повесить дело 5 минут.
Вы наверно не понимаете durik имеет в виду, мне тоже хочется «чисто» сгенерировать одно поле при помощи forms-api, конечно можно пойти таким путем, который предлагаете вы (повесить событие на элемент и от этого уже плясать), но это имхо dirty-style, хочется остаться в идеологии drupal (параметр ahah в forms-api и т.д).
Поправьте меня, если ошибусь. Написав 200 строк кода, мы получили форму строк на 50 + элементарную валидацию (строк 10) + добавление полей (еще 5 на js). Это 4 поля и три кнопки.
В чем фишка? Принципиальный отказ от написания html и js?
В чем фишка? Принципиальный отказ от написания html и js?
Это шаг к гибкости (попробуйте потом перетемизировать свою форму написанную на html), к возможности изменения формы другими разработчиками, а также стронними модулями.
Ну она как бы «перетемизируется». Через CSS. Найти человека, знающего CSS, таки проще, чем знающего drupal, а следовательно «перетимизация» обойдется дешевле.
Вы считаете, что возможность «потом» измененить форму с помощью сторонних модулей, оправдывает повышение цены создания?
ИМХО, гибкость нужна там, где понижает стоимость создания, сопровождения и модификации продукта.
Если сравнивать drupal и html, мы имеем гораздо более высокую цену создания формы на drupal. А меньшую цену модификации мы получим только в случае, если CSS и JS не хватит, что бывает не очень часто.
Поддержка же в обоих случаях стоит ровно ноль, но это до поры, пока мы не решаем сменить версию drupal'а, или подружить два конфликтующих модуля.
Вы считаете, что возможность «потом» измененить форму с помощью сторонних модулей, оправдывает повышение цены создания?
ИМХО, гибкость нужна там, где понижает стоимость создания, сопровождения и модификации продукта.
Если сравнивать drupal и html, мы имеем гораздо более высокую цену создания формы на drupal. А меньшую цену модификации мы получим только в случае, если CSS и JS не хватит, что бывает не очень часто.
Поддержка же в обоих случаях стоит ровно ноль, но это до поры, пока мы не решаем сменить версию drupal'а, или подружить два конфликтующих модуля.
Судя по вашим словам, высокая цена заключается в количестве строк кода? :)
На самом деле, в умных книжках по программированию то, что делается с формами в друпале называется «переход на новый уровень абстракции».
Поставьте задачу десяти индусам сделать форму на HTML. Да, они все справятся, 8 из них сделает невалидную верстку, 6 человек забудут о кликабельности лейблов, у одного будет неверная табуляция, еще пять не проставит CSS классы и айдишки.
Описав же формы «друпалским» способом, вы получите один результат. С возможностью расширения. С возможностью использования разных движков рендеринга. Без упора на текущий стандарт HTML, XHTML и т.д.
Надеюсь вы уловите то, к чему я клоню.
На самом деле, в умных книжках по программированию то, что делается с формами в друпале называется «переход на новый уровень абстракции».
Поставьте задачу десяти индусам сделать форму на HTML. Да, они все справятся, 8 из них сделает невалидную верстку, 6 человек забудут о кликабельности лейблов, у одного будет неверная табуляция, еще пять не проставит CSS классы и айдишки.
Описав же формы «друпалским» способом, вы получите один результат. С возможностью расширения. С возможностью использования разных движков рендеринга. Без упора на текущий стандарт HTML, XHTML и т.д.
Надеюсь вы уловите то, к чему я клоню.
Я с вами согласен :)
Для своего проекта, я тоже вначале «повелся» делать plug-ins Form, но потом все же понял (на основе анализа, попросов простых юзеров системы), что им гораздо проще сделать форму в css и html, чем разбираться с модулями.
Обычно «системы» делают программисты, но пользуются то, в основном обычные юзеры.
Для своего проекта, я тоже вначале «повелся» делать plug-ins Form, но потом все же понял (на основе анализа, попросов простых юзеров системы), что им гораздо проще сделать форму в css и html, чем разбираться с модулями.
Обычно «системы» делают программисты, но пользуются то, в основном обычные юзеры.
Судя по вашим словам, высокая цена заключается в количестве строк кода? :)
Примерно. Только надо еще умножить на стоимость каждой строчки ;)
Поставьте задачу десяти индусам сделать форму на HTML...Т.е. каждый индус знает, как сделать форму на друпале, но нормально сверстать не может? Или как?
С возможностью расширения. С возможностью использования разных движков рендеринга. Без упора на текущий стандарт HTML, XHTML и т.д.Вот скажите честно, сколько раз у вас была необходимость сменить html на xhtml? И сколько раз проблемой становились именно формы?
Все просто — любой индус, или даже чукча, может заполнить массив. Если он заполнит массив неправильно, он получит PHP ошибку или явную кривизну формы. Вероятно для верстальщика заполнить массив будет труднее, чем наваять валидную форму. А вот среднестатистического программера заполнять массивы учили еще в школе на уроках информатики, а _валидный_ HTML для него не всегда так очевиден.
Не знаю, стоит ли продолжать наши рассуждения, так как с вероятностью 90% мы останемся при своих мнениях. Скажу о себе. HTML-подход я проходил. Ничего хорошего из этого не получается, если у вас проект по размерам средний и выше, а программистов более пяти, (плюс, в наших реалиях, трое из них — студенты второго курса).
Однако, трезво оценивая друпаловские формы, могу сказать, что минус лишь в одном — довольно рутинный процесс начального составления массива. Данный минус скоро будет побежден, ибо готовится такой себе визуальный редактор, где форму можно наваять за две минуты drag'n'dropом, а дальше работать с ней как обычно.
Не знаю, стоит ли продолжать наши рассуждения, так как с вероятностью 90% мы останемся при своих мнениях. Скажу о себе. HTML-подход я проходил. Ничего хорошего из этого не получается, если у вас проект по размерам средний и выше, а программистов более пяти, (плюс, в наших реалиях, трое из них — студенты второго курса).
Однако, трезво оценивая друпаловские формы, могу сказать, что минус лишь в одном — довольно рутинный процесс начального составления массива. Данный минус скоро будет побежден, ибо готовится такой себе визуальный редактор, где форму можно наваять за две минуты drag'n'dropом, а дальше работать с ней как обычно.
Явную кривизну формы получит и верстальщик, когда работает с html, а в жестком xhtml даже с кавычками напутать тяжело. С другой стороны у html-ля, конечно есть несколько мест, которые всегда хочется автоматизировать. Например, банальные повторения id и name у элементов форм.
Я тоже проходил и html, и абстракцию от рендеринга, похожую на друпаловскую, и полноценные компоненты. Но вот вернулся почему-то :) Ваше применение, наверное, вполне оправданно, хотя бы низким уровнем кадров, и отсутствием разделения труда.
Насчет применимости html'я в средних и больших проектах, я, конечно, не соглашусь (несколько раз был очевидцем обратного). Это как раз те 90% :)
Я тоже проходил и html, и абстракцию от рендеринга, похожую на друпаловскую, и полноценные компоненты. Но вот вернулся почему-то :) Ваше применение, наверное, вполне оправданно, хотя бы низким уровнем кадров, и отсутствием разделения труда.
Насчет применимости html'я в средних и больших проектах, я, конечно, не соглашусь (несколько раз был очевидцем обратного). Это как раз те 90% :)
Минусов там все таки больше. Как минимум сюда же непрозрачность. Плюс какой-никакой оверхэд. А уж средств для визуального проектирования html-форм, как грязи.
test
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 шагов к постижению форм в Друпале