mariner Aug 11 2011 at 19:20

Zend_Form_Element: создание своего элемента

4 min

1.8K

Zend Framework*

+17

Comments 20

Radik_Wind Aug 11 2011 at 22:18

На мой взгляд в Symfony библиотека классов элементов форм (вджетов) реализована на порядок лучше. C этой точки зрения Zend уступает Symfony.

sHinE Aug 11 2011 at 22:59

Хотелось бы почитать статью о создании аналогичного элемента на симфони. Кстати, речь про первую или вторую?

Radik_Wind Aug 12 2011 at 05:39

На второй я еще пока ничего не писал, я про 1.4 версию, мог бы написать статью про создание виджетов формы для симфонии но увы кармы у меня не хватает что бы что то опубликовать (спасибо добрым людям).

Yeah Aug 12 2011 at 13:22

Вперед! Ждем статью, в ней и подискутируем.

zizop Aug 11 2011 at 22:56

А симпатично получилось!

dmitry_dvp Aug 11 2011 at 23:12

>> Здесь стоит заметить, что код нуждается в дополнение, т.к. в случае, если на странице будет
>> больше одного такого элемента, то нет необходимости в повторном подключении скриптов и css.

так ежели бы родными headScript, headLink или ZendX_JQuery_Container пользовались, даж думать об этом не пришлось, да и писать поменьше

>> $xhtml .= '/>'. PHP_EOL;
а вот тут следовало бы воспользоваться $this->view->doctype()->isXhtml() для определения необходимости слэша

>> if (!empty($value))
получается '0' в такое поле не записать. Хотя, может для вашей задачи это не имеет значения

>> url: '". $options['autocomplete_script']. "',
ну и это не кошерно. Есть же Zend_Json, который корректно заэнкодил бы

Да и вообще я бы в данном случае экстендил хелпер formText, там половина вашего кода хэлпера уже написана

dmitry_dvp Aug 11 2011 at 23:16

ну и по Jquery

>> .ajax({
>> url: '". $options['autocomplete_script']. "',
>> dataType: 'json',
>> success: function() {
>> tl_$elemId.getContainer().removeClass('textboxlist-loading');
>> }
>> })

ни к чему писать так многосложно

>> .getJSON('". $options['autocomplete_script']. "', function() {
>> tl_$elemId.getContainer().removeClass('textboxlist-loading');
>> })

mariner Aug 11 2011 at 23:18

Этот код из мануала по плагину. доработкой не заморачивался.

dmitry_dvp Aug 11 2011 at 23:23

А ещё в Zend есть понятие SubForm. Ваш элемент не сможет работать в составе SubForm, потому что

>> $id = $name;

а name у вложенных в SubForm элементов такого вида: subformname[elementname]

dmitry_dvp Aug 11 2011 at 23:31

И последнее.

В Zend вообще и в Zend_Form в частности метод setOptions имеет fallback на неизвестные ключи в поиска метода setOptionKeyName().

Если следовать стандартам, то вы должны бы были не объявлять сомнительный public $options (сбивающий с толку, так как не имеет прямого и логичного отношения к методу setOptions()), а объявить отдельные члены класса и сеттеры для них с соответствующими именами. И, тогда, setOptions вообще не надо было бы перекрывать.
И, кстати, в стандарте Zend ключи options следует писать camelCase. Что как раз и позволяет имя ключа превратить в setter = 'set'. ucfirst($key) (см. Zend_Form_Element, строка 353)

перечисление options получилось немного более многосложным, но в тоже время и более гибким и соответствующим принципам Zend

dmitry_dvp Aug 11 2011 at 23:42

Хотя нет. Есть ещё что сказать. Не сочтите за троллинг, наоборот — я рад появлению вашего материала, но конституция заставляет меня указывать на изъяны в материале, цель которого — просвящение.

Ваш элемент немного не самостоятелен. Он способен жить только в контексте. Ему необходимо чтобы файлы лежали на своих местах (те, что в defaultOptions), ему нужен jquery.

Можно чуточку отвязать его от необходимости в контексте.
Если используете $this->jquery (ZendX_JQuery_Container), то очень к месту была бы строчка в рендере

$this->query->enable();

элемент сам бы включал jquery на страницу.

dmitry_dvp Aug 11 2011 at 23:46

+ использование $this->jquery->addOnload() убрало бы запуск ajax'а в $(documet).ready и вообще сделало бы на 1 тег script меньше (наверняка же на onload уже что-то есть)

mariner Aug 11 2011 at 23:54

Да, спасибо. про многое из вами сказанного впервые слышу. полезно ;)

dVaffection Aug 12 2011 at 04:03

Подскажите, как быть, если элемент вызывается ajax'ом (например, в каком-нить попапе грузится форма)? Как в этом случае на него навесить js код, чтобы элемент заработал, если код прописан в $this->jquery->addOnload()?

Понятное дело, что речь идет о самостоятельном элементе.

dmitry_dvp Aug 12 2011 at 11:44

Увы, я не знаю качественного решения

dVaffection Aug 12 2011 at 12:25

Вот я и задаюсь делемой: вроде бы элемент самотоятельный — круто, но с другой строны как только этот элемени нужно вызвать ajax'ом приходится js-часть его опсания выонсить в js файлы. А если это часть большая и одинакова для элементо в вызываемых ajax'ом и нет — получается дублирование кода.

dVaffection Aug 12 2011 at 04:16

Если элемент использует jQuery, то его следует насделовать от ZendX_JQuery_Form_Element_UiWidget. Обект этого класса конфигурируется параметрами через методы setJQueryParam и setJQueryParams.

Соотв. эти параметры находятся в хелпере, кот отрисовывает элемент, и инкодятся с помощью ZendX_JQuery::encodeJson() — его фишка в enableJsonExprFinder => true

dmitry_dvp Aug 12 2011 at 11:43

Да, так было бы многократно круче, однако следует понимать, что

ZendX/JQuery/View/Helper/UiWidget.php
62: ->uiEnable();

т.е. JQueryUI придётся таскать с собой в пустую

dVaffection Aug 12 2011 at 12:31

Полностью с вами согласен. Однако на больших проектах я обычно юзаю jQueryUI (всегда понадобится dialog, calendar и прочие повседневные виджеты), поэтому для меня это неактуальная проблема!

P.S. К тому же на jQueryUI можно писать кастомные виджеты, вот хорошая статья на эту тему.

tvolf Aug 12 2011 at 12:54

Возможно, я ошибаюсь, но вот тут:

$.getJSON('" . $options['autocomplete_script'] . "', null, function (data) {
      tl.plugins['autocomplete'].setValues(data);
      tl.getContainer().removeClass('textboxlist-loading');
});";

не должно быть нечто типа:
$xhtml .= <фрагмент кода выше>?
Просто это, как я понимаю, сгенеренный javascript, который не добавляется
в $xhtml.