Роб Ален опубликовал в своем блоге пост о аплоаде файлов. Заметка небольшая — Роб описывает самые основы. Главное, на мой взгляд, это Заключение.

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

Я хочу рассказать о настройке форм через ini-файлы. Это будет полезно программистам и верстальщикам.

Возникла сегодня в процессе работы над одним проектом такая задача. Но нигде не смог найти решение.
Можно обрамить форму с помощью Zend_Form_Decorator_HtmlTag, а вот просто вставить код нельзя.
Zend_Form_Decorator_HtmlTag при создании получает переменную tag, например td, и выдает примерно следующее:
...
А если убрать закрывающийся тэг, а из первого убрать треугольные скобки?
Мысля пошла…

И я разработал Zend_Form_Decorator_HtmlCode (cкачать можно тут).

Теперь в Zend_Form_Element мы можем добавить наш декоратор.

$code = 'Наш код';
$elementDecorators = array(
array('decorator' => array('br' => 'HtmlCode'), 'options' => array('tag' => $code, 'placement' => Zend_Form_Decorator_Abstract::APPEND)),
);
$this -> addDecorators($elementDecorators);

Теперь после элемента формы появится $code.

После прочтения статьи я решил написать декоратор который будет прикреплять jquery код для получения данных из формы и отправки их на сервер.
Своим опытом спешу поделится с хабрасообществом.

Dodo это OpenSource вариация на тему онлайнового менеджера задач с использованием Zend Framework 1.8 очень похожего на Ta-da Lists от 37Signals.

Попытки создания собственной системы начались довольно давно (думаю это всем знакомо). За последние пару лет была откатана схема на своей системе, но сама система благополучно почила в бозе. Если там были попытки как-то использовать Zend как компоненты, то в конце концов было принято решение не изобретать велосипед, а просто взять Zend за основу.
Zend — 1.8/Doctrine — 1.1 на момент написания.

Что было решено сохранить в системе из предыдущей версии
1) Мультисайтовость
2) Мультиязычность. Интернационализация производится за счет Zend и Doctrine.
3) Модульность. При этом создать модуль можно в самой системе, задав yaml схему и получив стандартные методы для работы с помощью контроллеров и автогенерированых форм (Zend_Form).
4) В создаваемых модулях по умолчанию присутствует поддержка i18n, versionable, timestampable.
Каждый сайт имеет режимы отображения — backend, frontend,etc. Модель — одна для всех. Основой для моделей выбрана Doctrine. Показалась очень удобной.

Как многим уже известно Zend_CodeGenerator появился в бете 1.8 Zend_Framework
Я хотел было потерпеть до релиза версии 1.8, но не удержался и решил всё таки попробавть «на зубок».
Мы будем генерировать класс формы на основе mysql таблицы.
Это действительно очень удобно и избавляет нас от порой рутинной работы.

    Zend Framework содержит удобное средство рендеринга форм – Zend_Form. Наиболее важными плюсами являются:

• средства валидации данных (большое количество валидаторов);
• средства фильтрации данных (например перевод дат в формат БД);
• рендеринг формы с использованием декораторов;
• экранирование выводимых данных.

    Исходя из этого создать форму, обрабатываемую только серверной стороной не вызывает проблем. Однако сейчас этим уже никого не удивить. Отмечу, что Zend активно сотрудничает с Dojo для создания динамически обрабатываемых форм, но виджеты, разрабатываемые данной компанией, оставляют желать лучшего по сравнению с ExtJS. С этой точки зрения лучшим вариантом является корректировка рендеринга форм классом Zend_Form.

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

Публикую не свою статью. Вот ссылка на оригинал — http://web-blog.org.ua/articles/uchim-zend-form-russkomu-yazuky Но эта ссылка нерабочая.
Поэтому во избежание пропадания такой ценной, на мой взгляд, информации, я решила ее перепостить еще и сюда. Надеюсь автор не будет против.

Всю статью решила не писать, а только запостить полезный код. Тем, кому нужно будет решить такую проблему — все поймут.

0. Intro.

В процессе разработки достаточно часто нужно использовать различные кастомные селекты, инпуты, загрузщики файлов и прочее. В этом случае приходится писать дополнительные обработчики на стороне клиента, так как ZF из коробки не знает ничего, кроме стандартных элементов форм (капча есть исключение). В этой статье будет рассмотрено создание элемента на базе facebook-like TextboxList плагина для jQuery, который выглядит вот так:

Здравствуйте. Без долгих вступлений, хочу показать как выглядит элемент, о создании которого я собираюсь рассказать:


Я решил назвать это RadioImage.

При проектировании приложений на Zend Framework использование компонента Zend_Form существенно облегчает работу с сущностями – единожды созданная форма, с настроенными валидаторами, фильтрами и прочим, используется как при создании, так и при редактировании данных в БД.
Очень часто сущности содержат элементы типа File – будь то картинка-превью, имя файла для скачивания или фотография в галерее. Вот только если Вы захотите изменить сущность в форме которой есть элемент File, становится ясно что стандартный декоратор Zend_Form_Element_File не подходит для формы изменения сущности – т.к. он не позволяет отобразить наличие загруженного файла, не дает возможности удалить этот файл и т.п.

Иными словами, когда вы открываете сущность для изменения, все остальные элементы формы заполняются значениями из БД – при этом Zend_Form_Element_File этого делать не имеет.
В это статье хочу поделиться своей реализацией работы с Zend_Form_Element_File в рамках создания CRUD (create-read-update-delete) на ZendFramework 1.11

Под хабракатом вас ожидает подробное описание как создать декоратор, как прицепить его к форме и инструкции по работе с контроллером.

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

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

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

Я предлагаю решить этот вопрос посредством создания отдельного элемента формы, реализующего данную функциональность.



Перейдем к практической реализации этого.