Мы добавим на форму создания ноды таблицу, где пользователь сможет вносить данные и добавлять нужное количество строк в таблице. Об этом будет первоя часть статьи. Также прикрутим отрисовку графика по этим данным в момент их ввода, то есть "на лету" - это уже вторая часть.
Основные проблемы, которые нужно решить:
Одна строка таблицы должна была стать единым элементом, чтобы можно было на этапе валидации проверить заполнение всех ячеек одной строки таблицы.
Вывод в виде таблицы как на форме, так и на странице ноды был четко указан на мокапе и в требованиях.
Возможность добавлять, обрабатывать и сохранять в базе неограниченное количество рядов данных.
С регистрацией в Drupal знакомы, пожалуй, все его пользователи - все через нее когда-то проходили. Со стороны разработчика, как правило, тоже все знакомо - есть форма с логином, паролем, и кнопка "зарегистрироваться", после нажатия которой форма обрабатывается.
Но все меняется, если у клиента возникла задача собирать дополнительные данные о пользователе на этапе регистрации. Например, может потребоваться знать, откуда родом наш посетитель, сколько ему лет или где он работает. Плюсы и минусы такого подхода к регистрации с точки User Experience можно обсуждать отдельно, мы же в данной статье рассмотрим техническую часть с точки зрения программиста.
Итак, нам нужно собирать дополнительные данные - значит, в дополнение к полям логина и пароля, в форме регистрации потребуются другие, и наша форма регистрации разрастется до неприличных размеров, и с большой долей вероятности, пользователь испугается огромного количества требуемых данных и уйдет, так и не нажав заветную кнопку. В области дизайна пользовательских интерфейсов давно придуман способ решения этой проблемы - многошаговая форма (multistep form).
В такой форме пользователь вводит данные не все сразу, а шаг за шагом: таким образом мы не только на каждом шаге показываем разумное количество полей, но и избегаем лишних вопросов, в зависимости от уже имеющихся ответов на предыдущем шаге. Кроме того, пользователь может видеть прогресс заполнения в виде индикатора шагов, что тоже важно для пользователя ("Когда же это закончится ?", "Сколько мне осталось еще заполнять ?").
Продолжим изучение модуля Features (первая статья). Теперь отойдем от Open Atrium и вернемся к обычным сайтам на Drupal.
Чем больше сайтов делает разработчик, тем чаще ему приходиться создавать один и тот же функционал на разных сайтах. Посчитайте сколько раз вы уже сделали блоги, новости, статьи, фотогалереи и каждый раз функционал похож на 90%, отличия минимальны, а часто отличия только в темизации вывода.
Модуль Features поможет создать заготовки разных функций в виде отдельного модуля в состав которого будет входить описание всего функционала и для активации блогов, необходимо только включить в админке необходимый модуль. Хорошим примером из чего может состоять сайт на таких модулях является сборка Друпала под названием Open Atrium, компоненты которого это отдельные модули-фичи и включаются в два клика.
При работе с Друпалом каждый разработчик имеет свой набор "любимых" модулей, которые часто использует. Этот набор необходимо дополнить модулем Features.
Задача модуля — зафиксировать функционал в виде отдельного законченного модуля. Такое фиксирование можно использовать для: переноса функционала с сервера разработки на рабочий сайт; сохранение созданного функционала как наработку на будущее; создание контрольной точки (когда все работает) и, соответственно, откат к рабочему состоянии когда администратор сайта «перестарался» с настройками.
Вы добавили функции на сайт, а через несколько дней заказчик позвонил и рассказал, что ничего не работает. Вы уже 20 часов подряд набиваете код и кучу раз идете и клацаете по формам проверяя чтоб все работало, но мозг уже ничего не воспринимает и в итоге на сайт добавился неработающий фрагмент. А может у Вас сложный модуль с кучей взаимосвязанного функционала, ну или небольшой, но с кучей вариантов выбора. В общем у Вас миллионы причин прийти к автоматизированному тестированию.
Использование автоматизированного тестирования позволяет избавиться от кучи рутинных операций по регулярной проверке работоспособности кода. Для тестирования доступны автозаполнение форм и проверка результата, контроль доступа пользователей к различным разделам сайта и функционалу и многое другое.
Знакомьтесь — Джон, владелец достаточно крупного сайта, маркетолог, считает себя умным, профессиональным, и к тому же уверен, что умеет четко излагать свои мысли. При всем этом, Джон не так уж много знает о веб-дизайне и разработке, поэтому ему нужна ваша помощь. Джон обращается к вам с целым набором четких маркетинговых целей и просит вас назвать цену своей работы. И тут начинается самое интересное...
Начинающий веб-девелопер на первых шагах своей карьеры стоит перед выбором CMS системы, уже состоявшийся веб-девелопер за годы своей работы наслышан о десятках CMS, но нет времени на близкое изучение этих систем. Я попробую исправить это упущение и рассказать о CMS ModX.
МодХ ориентирован на небольшие сайты, имеет: АПИ, Ajax, ЧПУ, мета теги, группы пользователей и многое другое. Наличие некоторый технологий даже удивляет, например, встроенный в ядро аналог CCK, только под названием «переменные шаблона».
Системные требования мы опустим, они не отличаются от большинства систем: PHP, MySQL, Apache/IIS, так как система рассчитана под сайты визитки то потребления ресурсов значительно ниже от Друпала/Джумлы.
Этот пост раскроет вопрос что должен знать и уметь PHP-программист, чтобы называть себя Drupal-разработчиком. Кроме того, здесь я приведу практически все, что необходимо, чтобы получить эти знания сравнительно быстро.
Итак, вы два года работали с Zend Framework, а о Друпале слышали совсем немного. По мере того, как Друпал набирал популярность, вам или вашему боссу удалось подписать полугодичный контракт на разработку интранет-портала с нуля с одной большой компанией.
Или же, вы давно работаете с Друпалом как администратор, сделали много сайтов на готовых модулях, но хотите поднять свои горизонты в разработке тем и модулей, либо чтобы получать более выгодные предложения и заказы, либо просто, чтобы иметь возможность создавать нестандартные решения для своих собственных проектов.
В любом случае, вы полны энтузиазма, так как нашли вот этот график нужды в Drupal-разработчиках:
Но затем вы нашли еще и такой вот график кривой обучения Drupal:
При создании сайта на базе системы управления контентом Drupal вы заметите, что часто необходимо задавать типы контента, к которым, помимо дефолтных Title и Body, добавлены еще и другие поля.
В Друпале, начиная с 7-ой версии, функционал полей запланирован в базовом дистрибутиве, однако в версиях 6 и ранее он реализован в пользовательском модуле CCK и других связанных модулях, которые предусматривают дополнительные типы полей для создания контента.
При создании некоторых сайтов вам придется задавать поля с несколькими значениями, например, нужно будет разместить несколько изображений (каждое из которых будет полем-изображением) в правой части страницы. Это не проблема, так как модуль CCK позволяет задать несколько значений любому полю, а во второй версии CCK можно с легкостью сортировать, удалять или добавлять элементы с помощью удобного интерфейса на AJAX.
Но что, если нужно привязать, например, подпись и термин таксономии к каждому изображению? Другими словами, что если надо добавить поля к вашему типу контента группой?
Начинающий веб-девелопер на первых шагах своей карьеры стоит перед выбором CMS системы, уже состоявшийся веб-девелопер за годы своей работы наслышан о десятках CMS, но нет времени на близкое изучение этих систем. Я попробую исправить это упущение и рассказать о CMS ModX.
