Комментарии 16
Относительно старая статья Скотта Гонсалеза.
И, хотя, он не особо рекомендует брать её в расчет, на мой взгляд она довольно хорошо объясняет основные преимущества и принципы, заложенные в фабрику фиджетов jquery UI. Начинало это всё переводится долгими вечерами дома, когда ещё не было выложено официальной документации по виджету, после недавнего обновления сайта jQuery UI, так что не обессудьте.
На мой взгляд, каждому кто работает с jQuery, и, особенно использующим UI компоненты просто необходимо быть в курсе о фабрике.
И, хотя, он не особо рекомендует брать её в расчет, на мой взгляд она довольно хорошо объясняет основные преимущества и принципы, заложенные в фабрику фиджетов jquery UI. Начинало это всё переводится долгими вечерами дома, когда ещё не было выложено официальной документации по виджету, после недавнего обновления сайта jQuery UI, так что не обессудьте.
На мой взгляд, каждому кто работает с jQuery, и, особенно использующим UI компоненты просто необходимо быть в курсе о фабрике.
Большое спасибо за перевод!
Недавно изобретал «свой велосипед», но хотелось бы больше изучить принципы построения архитектуры на базе виджитов.
Такое понятие, как бизнес-логика навряд ли хорошо будет смотреться в виджите, верно?
Можете определить сферы применения виджета: чисто UI, либо все таки можно смотреть в сторону создания архитектуры на базе виджетов?
Недавно изобретал «свой велосипед», но хотелось бы больше изучить принципы построения архитектуры на базе виджитов.
Такое понятие, как бизнес-логика навряд ли хорошо будет смотреться в виджите, верно?
Можете определить сферы применения виджета: чисто UI, либо все таки можно смотреть в сторону создания архитектуры на базе виджетов?
Что мне не нравится в фабрике виджетов jQueryUI так это то что я не могу обратиться быстро и удобно к родительскому методу, если таковой не определен в конкретном виджете…
Т.е. если я отнаследовался от какого либо другого виджета, и если я хочу вызвать его метод, я не могу написать this.someParentMerhod(), приложение ругнется что его не существует, вместо этого мне придется прописать всю цепочку вложенности от jQuery до прототипа родительского виджета…
Т.е. если я отнаследовался от какого либо другого виджета, и если я хочу вызвать его метод, я не могу написать this.someParentMerhod(), приложение ругнется что его не существует, вместо этого мне придется прописать всю цепочку вложенности от jQuery до прототипа родительского виджета…
_super разве не то?
Да, этот метод снимает часть проблемы связанной с длинной строкой вызова метода, но не решает главной проблемы — отсутсвия полиморфизма.
Т.е. Один раз написав код который использует методы родительского объекта я не смогу потом подменить их реализацию в дочерних объектах не изменив по всему коду ссылки.
Т.е. Один раз написав код который использует методы родительского объекта я не смогу потом подменить их реализацию в дочерних объектах не изменив по всему коду ссылки.
Так же по этой теме была статья jQuery UI как инфраструктура для плагинов
На самом деле очень удобная штука для создания более-менее серьезных плагинов.
На самом деле очень удобная штука для создания более-менее серьезных плагинов.
Честно говоря, геморроя с этими виджетами больше, чем проку.
Все эти методы быстрее и легче реализовать самому, чем подключать внешнюю зависимость в виде jQueryUI.Core с jQueryUI.Widget.
Create, options, trigger, запись в data-аттрибут элемента — всё это рутинные вещи для любого адекватного jQuery-плагина на основе класса. Более того, самому в разы проще расширять функционал: к примеру, сделать AMD-модуль, подключить модели бэкбон, сделать биндинги методов, событий и прочее. Независимый код гораздо проще переносить, в нём нет зависимостей и лишнего, а накладные расходы минимальны.
Как показывает практика, писать код в архитектуре лайк MVC/jQueryUI очень и очень муторно, простой функционал отнимает сил более надобного. Проекты типа meteor выглядят очень вкусной альтернативой.
Все эти методы быстрее и легче реализовать самому, чем подключать внешнюю зависимость в виде jQueryUI.Core с jQueryUI.Widget.
Create, options, trigger, запись в data-аттрибут элемента — всё это рутинные вещи для любого адекватного jQuery-плагина на основе класса. Более того, самому в разы проще расширять функционал: к примеру, сделать AMD-модуль, подключить модели бэкбон, сделать биндинги методов, событий и прочее. Независимый код гораздо проще переносить, в нём нет зависимостей и лишнего, а накладные расходы минимальны.
Как показывает практика, писать код в архитектуре лайк MVC/jQueryUI очень и очень муторно, простой функционал отнимает сил более надобного. Проекты типа meteor выглядят очень вкусной альтернативой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Фабрика виджетов jQuery UI