Комментарии 19
Спасибо-спасибо. Я эту задачу решал несколько иными подходами, но Ваше решение мне тоже нравится. =)
Жаль, что в официальной документации не так много информации по сложному использованию и расширению Zend_Form.
Жаль, что в официальной документации не так много информации по сложному использованию и расширению Zend_Form.
0
Поделитесь вашим подходом.
-1
Нет-нет, простите, графоманством сейчас нет никакого желания заниматься. =( Я неправильно выразился, решал я не задачу построения группового декоратора, а в прицнипе задачу построения сложных форм. Впрочем, не важно. )
Кстати, не известны ли Вам какие-нибудь общедоступные репозитории готовых «компонент»-расширений Zend Framework, созданных энтузиастами?
Кстати, не известны ли Вам какие-нибудь общедоступные репозитории готовых «компонент»-расширений Zend Framework, созданных энтузиастами?
0
Я считаю что вы не правильно выбрали путь для решения.
А как править данную форму дизайнеру?
А как править данную форму дизайнеру?
0
Где-то на просторах сети видел, что данный вопрос можно решить через шаблон, где описаны декораторы.
Ссылку потерял :(
Ссылку потерял :(
0
Спасибо. Мне действительно помогло.
0
«Zend_Form упрощает создание форм и управление ими в ваших веб-приложениях»…
охохо… смотрел на ваш код и долго смиялся… ахаха…
охохо… смотрел на ваш код и долго смиялся… ахаха…
0
Цитата не моя — она взята из официального руководства.
А чем конкретно не нравится мой код? Обилием массивов??? Так, как я уже писал выше, эту информацию можно вынести в XML-конфиги.
А чем конкретно не нравится мой код? Обилием массивов??? Так, как я уже писал выше, эту информацию можно вынести в XML-конфиги.
-1
ZF рекомендует в таких случаях писать декоратор конкретно под эту форму или использовать ViewScript.
+1
слишком много [нечитаемого] кода для такой, в общем-то несложной задачи
+1
Я вообще свел к минимуму использование декораторов, ибо это все таки отображение (вью) и, соответсвенно, должно быть ближе к верстальщику чем к программисту.
0
Согласен, в больших проектах все это разруливать будет не очень приятно.
Вообще здесь очень философский вопрос: мешать модель и представление форм или нет? Какой бы ни был ответ — у обоих вариантов есть свои преимущества.
Я склоняюсь к тому, чтобы разделять модель и вид форм, при этом первоначальное построение модели формы (класс с фильтрами и валидаторами), класса представления и HTML-шаблона формы выполнять автоматически спец. утилитами. Этот подход дает гибкость, обособление HTML-кода и достаточную скорость разработки.
Вообще здесь очень философский вопрос: мешать модель и представление форм или нет? Какой бы ни был ответ — у обоих вариантов есть свои преимущества.
Я склоняюсь к тому, чтобы разделять модель и вид форм, при этом первоначальное построение модели формы (класс с фильтрами и валидаторами), класса представления и HTML-шаблона формы выполнять автоматически спец. утилитами. Этот подход дает гибкость, обособление HTML-кода и достаточную скорость разработки.
0
Аж скулу свело при взгляде на параметры setElementDecorators… Верстальщику путь закрыт, ибо даже программисту легко запутаться в таком обилии массивов.
0
Подобные вещи решаются с помощью CSS без изменения разметки.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работа со сложными декораторами в Zend Framework