Хотелось бы ещё узнать более подробное описание отличий от $.when() и особенно от deferred.pipe(). Насколько я понял, с deferred.pipe() очень много схожего (как минимум, последовательный вызов нескольких ajax-запросов).
Если речь про опции, то
1) не трогая можно сделать метод(ы), который будет что-то делать и менять опцию, а в описании опции тогда надо писать, что напрямую её менять не рекомендуется
2) либо (правильнее на мой взгляд) переопределить метод _setOption() и внутри нового метода обработать свой специфичный ключ опции и/или вызвать метод базового виджета.
Вызывается метод виджета .option(), который в свою очередь если требуется чтение — то возвращает значение нужной опции (или всех), а если требуется запись — то вызывает метод _setOptions(), а тот в свою очередь вызывает уже _setOption().
Детали можно посмотреть самому — там всё просто: github.com/jquery/jquery-ui/blob/1-8-stable/ui/jquery.ui.widget.js#L186
Сомнительный факт для меня. Вот если метод "_setOption" — то соглашусь, что он будет вызываться, но при этом надо учитывать, что метод базового виджета тоже не просто так и его либо надо вызывать, либо умышленно и осознанно не вызывать, отвечая за последствия.
Тут дело не в вызове, а в том, что если в вашем прототипе (описании виджета) не будет метода _create — то останется метод базового виджета. Т.о. если в вашем конструкторе нет ничего, кроме вызова конструктора базового виджета, то и писать его не надо, в таком случае останется конструктор базового виджета. Хотя и конструктором-то его можно назвать с большой натяжкой — это просто метод, который вызывается при создании инстанса виджета.
2) Да, ваш метод работает как метод, он же написан, почему бы ему не работать, я про то, что базового такого метода нет. Т.е. если убрать именно ваш метод, то работать будет нечему, а в пояснительном тексте говорится о базовом методе — возможно это просто неясно изложено было.
Поправить, конечно, надо, на то и существует режим редактирования :) А уж упоминать ли мои комментарии в пост-скриптуме — это ваше право, комментарии всё равно никуда не денутся и редактировать их нельзя, но мне будет приятно.
Допилив метод $.widget напильником, можно получить виджеты, которые сами читают свои настройки из разметки, сами находят витальные для себя элементы, и автоматически организовываются в иерархическую структуру. Но это явно тема для отдельной статьи.
Виджеты и так умеют читать свои настройки из разметки при наличии и соответствующей настройке плагина $.metadata.
Если под «допилить напильником» имеется в виду «взять исходник и поправить его» — то, на мой взгляд, это плохая идея. Потому что того, что есть сейчас вполне хватает для тех задач, которые встают перед виджетами jQuery UI. А вот если автор хочет написать свою фабрику виджетов (вполне можно взять за отправную точку идеи и часть кода из существующей фабрики) — то это благородная цель, но важно помнить, что у этой фабрики будут свои цели, задачи и область применения, и они должны быть обоснованными. Т.е. я хочу сказать, что метод, который используется в 1-ом виджете из 10, не нужен в базовом классе, он просто будет загромождать код.
В целом статья хорошая как вводная, но в ней есть ряд ошибок:
1) В разделе «Магия $.widget» про options:
Если при вызове виджета передать объект, то переданный объект будет «смерджен» (с помощью метода $.merge) с дефолтными настройками еще до вызова _create.
На самом деле используется $.extend(), ну и тогда уж объект будет «расширен».
2) Далее там же:
За работу с настройками отвечает метод setOption
Если это метод именно этого «нового» виджета — то вопросов нет, но если говорится о базовом методе (судя по примеру вызова) — то это не так. В виджетах есть public метод options( key, [ value ] ) и private методы _setOption, _setOptions.
И небольшое замечание по поводу раздела «Коллбэки»:
1) Если вызывается .bind() на элементе, то тип события надо указывать с префиксом в виде имени виджета, т.е. для примера в тексте должно быть: mw.bind('mywidgetonafterrender', function(evt, data) {console.log(data.theAnswer)});
2) В методе _trigger() тип события (строковый) всегда приводится к нижнему регистру, поэтому и в .bind() тип события должен быть в нижнем регистре полностью, но при этом для обработчика в опциях регистр учитывается — поэтому лучше для единообразия всё указывать в нижнем регистре.
Использую такую же модель, только не в файловом менеджере, а в похожей схеме. И вот мне интересно, возникла ли у вас проблема зацикливания событий и, если да, какой вариант её решения вы выбрали? Опишу на примере: есть блок с деревом папок и есть блок с иконками папок и файлов. Если открывать папку в одном из блоков, то тот генерирует событие «открыть папку», которое приходит во второй блок, а тот открывает папку в себе и, если нет специального условия, может сгенерировать такое же событие от себя — это и приведёт к «зацикливанию». У вас есть «специальное условие» (разделение обработчиков действий пользователей и реакции на события) или какая-то другая обработка?
1) не трогая можно сделать метод(ы), который будет что-то делать и менять опцию, а в описании опции тогда надо писать, что напрямую её менять не рекомендуется
2) либо (правильнее на мой взгляд) переопределить метод
_setOption()и внутри нового метода обработать свой специфичный ключ опции и/или вызвать метод базового виджета.Детали можно посмотреть самому — там всё просто: github.com/jquery/jquery-ui/blob/1-8-stable/ui/jquery.ui.widget.js#L186
Поправить, конечно, надо, на то и существует режим редактирования :) А уж упоминать ли мои комментарии в пост-скриптуме — это ваше право, комментарии всё равно никуда не денутся и редактировать их нельзя, но мне будет приятно.
Ну без указания предка никуда, а вот если
_create()пустой, то и объявлять его не надо и конструктор вручную вызывать тогда не придётся.Виджеты и так умеют читать свои настройки из разметки при наличии и соответствующей настройке плагина $.metadata.
Если под «допилить напильником» имеется в виду «взять исходник и поправить его» — то, на мой взгляд, это плохая идея. Потому что того, что есть сейчас вполне хватает для тех задач, которые встают перед виджетами jQuery UI. А вот если автор хочет написать свою фабрику виджетов (вполне можно взять за отправную точку идеи и часть кода из существующей фабрики) — то это благородная цель, но важно помнить, что у этой фабрики будут свои цели, задачи и область применения, и они должны быть обоснованными. Т.е. я хочу сказать, что метод, который используется в 1-ом виджете из 10, не нужен в базовом классе, он просто будет загромождать код.
1) В разделе «Магия $.widget» про options:
На самом деле используется
$.extend(), ну и тогда уж объект будет «расширен».2) Далее там же:
Если это метод именно этого «нового» виджета — то вопросов нет, но если говорится о базовом методе (судя по примеру вызова) — то это не так. В виджетах есть public метод
options( key, [ value ] )и private методы_setOption,_setOptions.И небольшое замечание по поводу раздела «Коллбэки»:
1) Если вызывается
.bind()на элементе, то тип события надо указывать с префиксом в виде имени виджета, т.е. для примера в тексте должно быть:mw.bind('mywidgetonafterrender', function(evt, data) {console.log(data.theAnswer)});2) В методе _trigger() тип события (строковый) всегда приводится к нижнему регистру, поэтому и в
.bind()тип события должен быть в нижнем регистре полностью, но при этом для обработчика в опциях регистр учитывается — поэтому лучше для единообразия всё указывать в нижнем регистре.По сути, именно так и работает .prop()