Comments 37
Было бы круто увидеть демо.
Да, я тоже об этом думал. Но у меня сейчас нет хабраэффекто-устойчивых мощностей.
Ах сколько же много кода ) Привет карме.
Не поделитесь со мной, что это значит? Хм… тут должно быть, зашифрована конструктивная критика по теме поста.
Вся критика связана с архитектурой ZF 1.x и стилем написания кода для него.
На самом деле в этой статье использован один из стилей работы.
Сами Zend'овцы всё больше склоняют пользователей фреймворка уходить от создания объектов, вызова методов в сторону к фабрикам и массивам характеристик создаваемого объекта (а в конечном счете — файлам конфигурации).
Например, Form_ProductStatus по-большому счёту лишняя сущность. Её бы могла успешно заменить секция в конфигурационом-файле (ini, xml, ...) с описанием характеристик формы.
Вот промежуточный этап рефакторинга в сторону увода формы этой в конфиг: pastebin.com/wMGM6xPZ
Как видите — остался единственный вызов метода, который тоже уйдет, когда форма будет доделана из статически наполненной опциями в динамически наполняемую данными перед выводом.
Сами Zend'овцы всё больше склоняют пользователей фреймворка уходить от создания объектов, вызова методов в сторону к фабрикам и массивам характеристик создаваемого объекта (а в конечном счете — файлам конфигурации).
Например, Form_ProductStatus по-большому счёту лишняя сущность. Её бы могла успешно заменить секция в конфигурационом-файле (ini, xml, ...) с описанием характеристик формы.
Вот промежуточный этап рефакторинга в сторону увода формы этой в конфиг: pastebin.com/wMGM6xPZ
Как видите — остался единственный вызов метода, который тоже уйдет, когда форма будет доделана из статически наполненной опциями в динамически наполняемую данными перед выводом.
По идее, еще setValue нужно переопределить, например.
Спасибо, думаю пригодится.
Единственное, я бы еще валидатор добавил.
Единственное, я бы еще валидатор добавил.
// вот самый главные элемент несущий функционал, остальное интерфейс
$list[] = '<input type=«hidden» id="'.$name.'" name="'.$name.'" value="'.$value.'" />';
1. конкатенации — жесть. почва для XSS. $view->escape() спасет
2. ID и NAME — не одно и тоже. В сабформу такой элемент не засунуть
3. вы же не зря экстендили Zend_View_Helper_FormElement… а у него есть метод $this->_hidden… к томе же есть хелпер $view->formHidden
$list[] = '<input type=«hidden» id="'.$name.'" name="'.$name.'" value="'.$value.'" />';
1. конкатенации — жесть. почва для XSS. $view->escape() спасет
2. ID и NAME — не одно и тоже. В сабформу такой элемент не засунуть
3. вы же не зря экстендили Zend_View_Helper_FormElement… а у него есть метод $this->_hidden… к томе же есть хелпер $view->formHidden
Хм. Складывается ощущение, что с данной работой вполне мог бы справиться Zend_Form_Element_Radio + css стайлинг от выделенного верстальщика. С другой стороны — далеко не везде ещё поняли необходимость выделенного верстальщика + если проект только один, для аутсорса этой работы нужно чтобы работа по проекту хоть как-то планировалась — а с этим у многих «какбэПМ»ов проблемы.
Ну можно было и так, но я в середине поста показал пример с чекбоксами — мне не нравится то, что эти элементы как посредники. Во времена драг-энд-дропов и тачскринов, хочется нажать непосредственно на элемент и что бы он выбрался. Я не профи в UI, но интуитивно так хочется сделать.
А как заменить радио кнопки, изображениями и сделать их «живыми» с помощью только стилей, я не представляю даже.
А как заменить радио кнопки, изображениями и сделать их «живыми» с помощью только стилей, я не представляю даже.
сканирование директорий, наполнение опциями. Всё это положено делать ВНЕ формы. Вы жестко завязали форму на предметную область убив один из принципов — повторное использование кода.
следовало по аналогии с multioptions наполнять через параметры к форме.
URL'ы тоже должны приходить в форму снаружи.
Уж коли @uses ZendX_Jquery, то написали бы простенький juqery плагинчик, в котором бы был завернут JS код, который обрабатывает клики, да и стили бы универсально вынесли. Конкатенация CSS селекторов опять же — не хорошо.
Ещё лучше — эксендить UiWidget, но тут есть камень преткновения — надо нелегкий jqueryui.wiget.core за собой таскать.
По HTML тоже можно было бы сделать лучше: чтобы работало и без javascript, сделать label, img и radio, а при инициализации JS radio прятать. Hidden вообще бы не потребовался
следовало по аналогии с multioptions наполнять через параметры к форме.
URL'ы тоже должны приходить в форму снаружи.
Уж коли @uses ZendX_Jquery, то написали бы простенький juqery плагинчик, в котором бы был завернут JS код, который обрабатывает клики, да и стили бы универсально вынесли. Конкатенация CSS селекторов опять же — не хорошо.
Ещё лучше — эксендить UiWidget, но тут есть камень преткновения — надо нелегкий jqueryui.wiget.core за собой таскать.
По HTML тоже можно было бы сделать лучше: чтобы работало и без javascript, сделать label, img и radio, а при инициализации JS radio прятать. Hidden вообще бы не потребовался
Полностью согласен. Понимаю, что это не оправдание, но я практически выдернул это из рабочего проекта (из админки) и захотел поделится.
В связи с недостатком времени, я делаю такие штуки итерациями. То есть, когда понадобится этот элемент еще раз, я поправлю такие жизненно важные вещи как использование конкатенации и возможность использовать без JS. Потом можно будет и обверткой заняться.
Без ваших камментов я не учел бы конечно всего. Так что это, получилось продолжение поста — обязательно к прочтению. Спасибо.
В связи с недостатком времени, я делаю такие штуки итерациями. То есть, когда понадобится этот элемент еще раз, я поправлю такие жизненно важные вещи как использование конкатенации и возможность использовать без JS. Потом можно будет и обверткой заняться.
Без ваших камментов я не учел бы конечно всего. Так что это, получилось продолжение поста — обязательно к прочтению. Спасибо.
ну и такая вот мелочь: вью-хелпер должен или делать jquery->enable или проверять isEnabled
Можно просто
$img->addMultiOptions(array(
"black_new.png" => $bu.'/icons/black_new.png',
"black_sale.png" => $bu.'/icons/black_sale.png',
"blue_new.png" => $bu.'/icons/blue_new.png',
"label_sale.png" => $bu.'/icons/label_sale.png',
"new_blue.png" => $bu.'/icons/new_blue.png',
"new_red.png" => $bu.'/icons/new_red.png',
"sale_blue.png" => $bu.'/icons/sale_blue.png',
"sale_green.png" => $bu.'/icons/sale_green.png',
"sale_yellow.png" => $bu.'/icons/sale_yellow.png',
"sticker_blue_sale.png" => $bu.'/icons/sticker_blue_sale.png'
));
хм, всё смешалось — кони… люди… (ц)
почему это не список с радиокнопками, стилизованный через css, и инициализирующийся при помощи js?
и будет деградация для случая с отключенным/поломанным js у браузера и не будет зашитых путей картинок в php-код/конфиг/скрытую логику вроде вашей со сканированием папки?
да и появится возможность добавить например :hover версию картинки. в общем надо по-максимуму перетянуть всё в css, а в коде чтоб мелькали только id="..." и data-key="...." если нужно.
почему это не список с радиокнопками, стилизованный через css, и инициализирующийся при помощи js?
и будет деградация для случая с отключенным/поломанным js у браузера и не будет зашитых путей картинок в php-код/конфиг/скрытую логику вроде вашей со сканированием папки?
да и появится возможность добавить например :hover версию картинки. в общем надо по-максимуму перетянуть всё в css, а в коде чтоб мелькали только id="..." и data-key="...." если нужно.
Вторая картинка — создание нового Issue в до боли знакомой JIRA :)
Zend_Form наверное один из самых несуразных компонентов ZF, и то, как его используют — яркое подтверждение тому. И эта статья тоже.
Sign up to leave a comment.
Элемент Zend_Form для выбора изображения