Работа со сложными декораторами в Zend Framework

[huze]

Спасибо-спасибо. Я эту задачу решал несколько иными подходами, но Ваше решение мне тоже нравится. =)

Жаль, что в официальной документации не так много информации по сложному использованию и расширению Zend_Form.

[Yeah]

Поделитесь вашим подходом.

[huze]

Нет-нет, простите, графоманством сейчас нет никакого желания заниматься. =( Я неправильно выразился, решал я не задачу построения группового декоратора, а в прицнипе задачу построения сложных форм. Впрочем, не важно. )

Кстати, не известны ли Вам какие-нибудь общедоступные репозитории готовых «компонент»-расширений Zend Framework, созданных энтузиастами?

[Yeah]

К сожалению, репозитории мне неизвестны.

Со сложными формами там как раз все проще: есть addSubForm.

[ArtemS]

Я считаю что вы не правильно выбрали путь для решения.
А как править данную форму дизайнеру?

[Yeah]

Zend_Form может использовать Zend_Config вместо прямого создания декораторов, так что все можно вывести в XML — это уже чуть проще, особенно если максимально упростить мешанину из тэгов и использовать CSS.

[akira]

Где-то на просторах сети видел, что данный вопрос можно решить через шаблон, где описаны декораторы.
Ссылку потерял :(

[Yeah]

Такую ссылку найти не сложно — это официальное руководство. Есть такой декоратор — как ViewScript. Не всегда есть смысл использовать именно его. Тут я разъяснил, почему.

[chill84]

Спасибо. Мне действительно помогло.

[zupernintendo]

«Zend_Form упрощает создание форм и управление ими в ваших веб-приложениях»…
охохо… смотрел на ваш код и долго смиялся… ахаха…

[Yeah]

Цитата не моя — она взята из официального руководства.
А чем конкретно не нравится мой код? Обилием массивов??? Так, как я уже писал выше, эту информацию можно вынести в XML-конфиги.

[zupernintendo]

да это скорее проблема самого zend framework.
его разработчики какбы хотят показать что php ничем не хуже java и на нем можно писать в таком же стиле :)
только вот нужно ли это…

[michailenko]

ZF рекомендует в таких случаях писать декоратор конкретно под эту форму или использовать ViewScript.

[Yeah]

ViewScript имеет смысл применять, когда верстка сложная, но однотипная, а я привел пример (реальный пример!), когда верстка различных элементов отличается.

[zed_0xff]

слишком много [нечитаемого] кода для такой, в общем-то несложной задачи

[chEbba]

Я вообще свел к минимуму использование декораторов, ибо это все таки отображение (вью) и, соответсвенно, должно быть ближе к верстальщику чем к программисту.

[AirWorker]

Согласен, в больших проектах все это разруливать будет не очень приятно.

Вообще здесь очень философский вопрос: мешать модель и представление форм или нет? Какой бы ни был ответ — у обоих вариантов есть свои преимущества.

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

[MARDEN]

Аж скулу свело при взгляде на параметры setElementDecorators… Верстальщику путь закрыт, ибо даже программисту легко запутаться в таком обилии массивов.

[Ueasley]

Подобные вещи решаются с помощью CSS без изменения разметки.