Мне кажется, что
— ваш декоратор дублирует родной код, в частности рисование label, errors и т.п. можно оставить родным дектораторам. Обычно декоратор декорирует, а не «рисует всё»
— так pastebin.com/yMAK8tct лучше, чем так pastebin.com/w5ycEDM6, а можно ещё и неймспейс ваших фильтров добавить и подключать аналогично иным (родным) фильтрам [вкусовщина, да]
— рисовать декоратором чекбокс, а потом принимать его значение в обход form->getValues() напрямую из реквеста — некрасиво. Идеологически вернее было бы этому чаекбоксу появится не в связи с новым декторатором, а в связи с новым элементом «checkbox» в форме.
— создавать внутри формы модели и использовать их — некрасиво. Правильно — передавать данные форме при создании, тем более что в этом конкретном случае — это опции выпадающего списка
какой валидатор?
валидатор, проверяющий, что присланное значение — одно из перечисленных? Он встроен в Zend_Form_Element_Multi, который в данной статье экстендится
На самом деле в этой статье использован один из стилей работы.
Сами Zend'овцы всё больше склоняют пользователей фреймворка уходить от создания объектов, вызова методов в сторону к фабрикам и массивам характеристик создаваемого объекта (а в конечном счете — файлам конфигурации).
Например, Form_ProductStatus по-большому счёту лишняя сущность. Её бы могла успешно заменить секция в конфигурационом-файле (ini, xml, ...) с описанием характеристик формы.
Вот промежуточный этап рефакторинга в сторону увода формы этой в конфиг: pastebin.com/wMGM6xPZ
Как видите — остался единственный вызов метода, который тоже уйдет, когда форма будет доделана из статически наполненной опциями в динамически наполняемую данными перед выводом.
сканирование директорий, наполнение опциями. Всё это положено делать ВНЕ формы. Вы жестко завязали форму на предметную область убив один из принципов — повторное использование кода.
следовало по аналогии с multioptions наполнять через параметры к форме.
URL'ы тоже должны приходить в форму снаружи.
Уж коли @uses ZendX_Jquery, то написали бы простенький juqery плагинчик, в котором бы был завернут JS код, который обрабатывает клики, да и стили бы универсально вынесли. Конкатенация CSS селекторов опять же — не хорошо.
Ещё лучше — эксендить UiWidget, но тут есть камень преткновения — надо нелегкий jqueryui.wiget.core за собой таскать.
По HTML тоже можно было бы сделать лучше: чтобы работало и без javascript, сделать label, img и radio, а при инициализации JS radio прятать. Hidden вообще бы не потребовался
// вот самый главные элемент несущий функционал, остальное интерфейс
$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
Вообще, автомобиль изначально Nubira (там), потом, пережив рестайлинг, приехал к нам как Lacetti. На одном и тоже автомобиле никогда не было написано одновременно Lacetti и Nubira.
Тоже самое касается и 2007 Chevrolet Lacetti Optra (Lacetti).
Nubira — Корея
Optra — Канада
Lacetti — Россия
Excelle — Китай
Viva — Австралия
Forenza — не помню
Комплектации тоже не включаем в модификации. Модификации должны минимум отличаться одним из: габариты, двигатель и его составляющие, ходовая часть, форма кузова, спецоснащение (броня, скорая, милиция), в отдельных случаях, как выше — цвет или салон.
Ну и сабжевый сайт — не мой. Про их Хаммеры мне сказать нечего. У нас Hummer H3 выглядит так: www.autowp.ru/hummer/h3/
Например, на autowp.ru сейчас более 42000 модификаций. При этом ТТХ не заполнены у 99% автомобилей, сами модификации полноценно заведены лишь у 8%, у остальных модификаций по 1 штуке.
Оценочно, при нашей структуре каталога (когда даже левый и правый руль — отдельная модификация) при теоретически полностью наполненном каталоге будет точно более 150тыс модификаций.
Зачем эта вкусность? чтобы вместо
$translatedDescription = $translator->translate($result->description);
писать
$translatedDescription = $result->getTranslate(«en», «description»);
?? да ещё и язык за собой таскать
— ваш декоратор дублирует родной код, в частности рисование label, errors и т.п. можно оставить родным дектораторам. Обычно декоратор декорирует, а не «рисует всё»
— так pastebin.com/yMAK8tct лучше, чем так pastebin.com/w5ycEDM6, а можно ещё и неймспейс ваших фильтров добавить и подключать аналогично иным (родным) фильтрам [вкусовщина, да]
— рисовать декоратором чекбокс, а потом принимать его значение в обход form->getValues() напрямую из реквеста — некрасиво. Идеологически вернее было бы этому чаекбоксу появится не в связи с новым декторатором, а в связи с новым элементом «checkbox» в форме.
— создавать внутри формы модели и использовать их — некрасиво. Правильно — передавать данные форме при создании, тем более что в этом конкретном случае — это опции выпадающего списка
Уверен, что желание необоснованное
валидатор, проверяющий, что присланное значение — одно из перечисленных? Он встроен в Zend_Form_Element_Multi, который в данной статье экстендится
Сами Zend'овцы всё больше склоняют пользователей фреймворка уходить от создания объектов, вызова методов в сторону к фабрикам и массивам характеристик создаваемого объекта (а в конечном счете — файлам конфигурации).
Например, Form_ProductStatus по-большому счёту лишняя сущность. Её бы могла успешно заменить секция в конфигурационом-файле (ini, xml, ...) с описанием характеристик формы.
Вот промежуточный этап рефакторинга в сторону увода формы этой в конфиг: pastebin.com/wMGM6xPZ
Как видите — остался единственный вызов метода, который тоже уйдет, когда форма будет доделана из статически наполненной опциями в динамически наполняемую данными перед выводом.
следовало по аналогии с multioptions наполнять через параметры к форме.
URL'ы тоже должны приходить в форму снаружи.
Уж коли @uses ZendX_Jquery, то написали бы простенький juqery плагинчик, в котором бы был завернут JS код, который обрабатывает клики, да и стили бы универсально вынесли. Конкатенация CSS селекторов опять же — не хорошо.
Ещё лучше — эксендить UiWidget, но тут есть камень преткновения — надо нелегкий jqueryui.wiget.core за собой таскать.
По HTML тоже можно было бы сделать лучше: чтобы работало и без javascript, сделать label, img и radio, а при инициализации JS radio прятать. Hidden вообще бы не потребовался
$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
Вообще, автомобиль изначально Nubira (там), потом, пережив рестайлинг, приехал к нам как Lacetti. На одном и тоже автомобиле никогда не было написано одновременно Lacetti и Nubira.
Тоже самое касается и 2007 Chevrolet Lacetti Optra (Lacetti).
Nubira — Корея
Optra — Канада
Lacetti — Россия
Excelle — Китай
Viva — Австралия
Forenza — не помню
www.autowp.ru/twins/group9/
нету китайского рынка
8% — это наполненность перечня модификаций.
Ориентироваться следует по 8%. Я зря вообще упомянул ТТХ.
Нет, цвета за модификацию мы не считаем, за исключением случаев особой (часто — связанной с эвентом) раскраски автомобилей, как например: www.autowp.ru/pictures/volkswagen/polo/autowp.ru_volkswagen_polo__harlekin__7.jpg
Комплектации тоже не включаем в модификации. Модификации должны минимум отличаться одним из: габариты, двигатель и его составляющие, ходовая часть, форма кузова, спецоснащение (броня, скорая, милиция), в отдельных случаях, как выше — цвет или салон.
Ну и сабжевый сайт — не мой. Про их Хаммеры мне сказать нечего. У нас Hummer H3 выглядит так: www.autowp.ru/hummer/h3/
Оценочно, при нашей структуре каталога (когда даже левый и правый руль — отдельная модификация) при теоретически полностью наполненном каталоге будет точно более 150тыс модификаций.