Pull to refresh

Comments 37

Да, я тоже об этом думал. Но у меня сейчас нет хабраэффекто-устойчивых мощностей.
Полагаю, что под отдачу нескольких десятков килобайт статики сильно много мощности не нужно (а сами jquery и тп можно и с гуглевского CDN заинклудить для пущей экономии трафика)
Зенд на слабеньких машинах работает слабенько, особенно с формой, и внешними декораторами для элементов
Я имел ввиду не в шаблоне описывать элементы а классы использовать, это сокращает скорость
не обязательно для демо тащить за собой весь зенд, это же только Zend_Form нужен + пару зависимых классов.
Ах сколько же много кода ) Привет карме.
Не поделитесь со мной, что это значит? Хм… тут должно быть, зашифрована конструктивная критика по теме поста.
Вся критика связана с архитектурой ZF 1.x и стилем написания кода для него.
На самом деле в этой статье использован один из стилей работы.
Сами Zend'овцы всё больше склоняют пользователей фреймворка уходить от создания объектов, вызова методов в сторону к фабрикам и массивам характеристик создаваемого объекта (а в конечном счете — файлам конфигурации).

Например, Form_ProductStatus по-большому счёту лишняя сущность. Её бы могла успешно заменить секция в конфигурационом-файле (ini, xml, ...) с описанием характеристик формы.

Вот промежуточный этап рефакторинга в сторону увода формы этой в конфиг: pastebin.com/wMGM6xPZ
Как видите — остался единственный вызов метода, который тоже уйдет, когда форма будет доделана из статически наполненной опциями в динамически наполняемую данными перед выводом.
Интересно, я не уделял должного внимания такому подходу. У меня не было аргументов «За» такой способ инициализации форм. Теперь задумался.
А мне .ini формат больше, чем массивы нравится (использую для маршрутов), нужно будет попробовать и посмотреть как пойдет с формами.
Не припомню ни одного случая, чтобы приходилось переопределять setValue.
Уверен, что желание необоснованное
А если я хочу выделить какой-то элемент из списка изображений? Как в таком случае это будет работать?
также, как работает родной select, multicheckbox и radiogroup
Спасибо, думаю пригодится.

Единственное, я бы еще валидатор добавил.
какой валидатор?
валидатор, проверяющий, что присланное значение — одно из перечисленных? Он встроен в Zend_Form_Element_Multi, который в данной статье экстендится
// вот самый главные элемент несущий функционал, остальное интерфейс
$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
По первым трем пунктам согласен, спасибо. А doctype учел, но выкосил для статьи, что бы все выглядело максимально просто, передать основную суть элемента. Возможно был не прав — нельзя «учить» на неправильных примерах.
Хм. Складывается ощущение, что с данной работой вполне мог бы справиться Zend_Form_Element_Radio + css стайлинг от выделенного верстальщика. С другой стороны — далеко не везде ещё поняли необходимость выделенного верстальщика + если проект только один, для аутсорса этой работы нужно чтобы работа по проекту хоть как-то планировалась — а с этим у многих «какбэПМ»ов проблемы.
Ну можно было и так, но я в середине поста показал пример с чекбоксами — мне не нравится то, что эти элементы как посредники. Во времена драг-энд-дропов и тачскринов, хочется нажать непосредственно на элемент и что бы он выбрался. Я не профи в UI, но интуитивно так хочется сделать.
А как заменить радио кнопки, изображениями и сделать их «живыми» с помощью только стилей, я не представляю даже.
«с помощью только стилей» — почему только стилей — ещё и js есть. Но я просто о том, что работу верстальщика/client-side разработчика приходится выполнять server-side — разработчику.
сканирование директорий, наполнение опциями. Всё это положено делать ВНЕ формы. Вы жестко завязали форму на предметную область убив один из принципов — повторное использование кода.

следовало по аналогии с multioptions наполнять через параметры к форме.

URL'ы тоже должны приходить в форму снаружи.

Уж коли @uses ZendX_Jquery, то написали бы простенький juqery плагинчик, в котором бы был завернут JS код, который обрабатывает клики, да и стили бы универсально вынесли. Конкатенация CSS селекторов опять же — не хорошо.

Ещё лучше — эксендить UiWidget, но тут есть камень преткновения — надо нелегкий jqueryui.wiget.core за собой таскать.

По HTML тоже можно было бы сделать лучше: чтобы работало и без javascript, сделать label, img и radio, а при инициализации JS radio прятать. Hidden вообще бы не потребовался
Полностью согласен. Понимаю, что это не оправдание, но я практически выдернул это из рабочего проекта (из админки) и захотел поделится.
В связи с недостатком времени, я делаю такие штуки итерациями. То есть, когда понадобится этот элемент еще раз, я поправлю такие жизненно важные вещи как использование конкатенации и возможность использовать без 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'
));
Да, спасибо. Я там в камментариях прямо в коде написал:
// можно конечно добавить используя addMultiOptions() без цикла 
// но для наглядности я сделал цикл
а можно оставить только названия классов и вынести в css.
это если с учетом того, что пункты будут не динамическими
да. вы правы.Но тут — что вижу, то и пою. Тут пункты статические и kiss говорит мне не гоородить лишний огород, да и програмного кода меньше в файле.
хм, всё смешалось — кони… люди… (ц)

почему это не список с радиокнопками, стилизованный через css, и инициализирующийся при помощи js?
и будет деградация для случая с отключенным/поломанным js у браузера и не будет зашитых путей картинок в php-код/конфиг/скрытую логику вроде вашей со сканированием папки?

да и появится возможность добавить например :hover версию картинки. в общем надо по-максимуму перетянуть всё в css, а в коде чтоб мелькали только id="..." и data-key="...." если нужно.
А если картинки — аватры пользователей, например
Вторая картинка — создание нового Issue в до боли знакомой JIRA :)
Zend_Form наверное один из самых несуразных компонентов ZF, и то, как его используют — яркое подтверждение тому. И эта статья тоже.
И что же именно в нём не так?

Я лично очень люблю ZF и в частности, Zend_Form за то, что он позволяет разворачивать очень большие формы с кучей всяких проверок и т.д за короткий срок. И не занимая место на элементы формы в template
Only those users with full accounts are able to leave comments. Log in, please.