Дизайн jQuery против Yahoo UI API
Меня озадачивает разница в дизайне между jQuery и API-интерфейсом UI Yahoo. Отказ от ответственности: у меня сильная неприязнь к jQuery api, но я также очень неосведомлен в веб-программировании и javascript в целом, поэтому я мог быть мертв неправильно и вернуться сюда, умоляя о выкупе. так долго...
Пункт моего вопроса заключается в следующем. Эти два варианта отличаются друг от друга. jQuery помещает DOM в центр и украшает DOM, выполняя на нем метод "триггера". Пример
$("#flexigrid").flexigrid()
Требование jQuery заключается в том, что в некоторых случаях вы должны заранее придерживаться определенной конкретной структуры для своего html. Пример:
<div id="accordion">
<h3><a href="#">First header</a></h3>
<div>First content</div>
<h3><a href="#">Second header</a></h3>
<div>Second content</div>
</div>
а затем
$("#accordion").accordion();
Кроме того, возвращаемый объект вообще не предоставляет никакого механизма для скрытия DOM с помощью удобного программного метода. Чтобы манипулировать сущностью jQuery, вам нужно получить доступ к DOM с помощью селекторов, доступ к которым в некоторых случаях не гарантируется, что его легко узнать, например, в случае внутренних идентификаторов. Предположим, что вы хотите поменять аккордеон программно, что вы делаете, это
$('#accordion').accordion('option', 'active', 2);
а не более интуитивно понятный
myAccordion.setActiveTab(2);
С другой стороны, yahoo ui фокусируется на объектах javascript, вы создаете их, передавая селектор DOM node (например, myDataTable = new YAHOO.widget.DataTable("container_id")
), а затем выполняете все манипуляции с помощью методов объекта. Хотите добавить новую строку? вызовите myDataTable.addRow()
. DOM скрыт. Вас не интересует, что происходит за кулисами.
Теперь, мой опыт работы с Trolltech QT хорошо подходит для пользовательского интерфейса Yahoo. Ясный, определенный API объектов виджетов, возможная свобода для повторной реализации части их через наследование, непрозрачный рендеринг, если вы не хотите открыть коробку и замарать руки. QT - выигрышный API, хорошо работает, он прост в использовании, а пользовательский интерфейс Yahoo похож на стиль дизайна. С другой стороны, jQuery работает в противоречивой (мне), очень открытой коробке, с уменьшенным API на своих объектах.
Достаточно разглагольствовать. Дело в том, что я предполагаю, что могу ошибаться в этом, но я хотел бы знать, почему. Каковы преимущества дизайна, связанные с интерфейсом jQuery-интерфейса (где DOM явно отображается, и вам, возможно, придется искать вещи, которые плагины jQuery автоматически создаются, поэтому вы можете наконец $(выбрать) их и присоединить события или изменить их содержимое) вместо того, чтобы скрывать все за объектами и товарными методами, такими как YUI?
Я не говорю о скорости, размере кода или количестве ввода. Я говорю о концепциях дизайна, таких как инкапсуляция, фокусировка на интерфейсах и простота доступа. Какой дизайн лучше, в каких ситуациях и почему?
Ответы
Ответ 1
Я не думаю, что ваш аргумент направлен на jQuery, но больше API, предоставленный авторами плагинов.
К сожалению, ни один автор плагинов не создаст плагин с тем же API. Уровень доступа к программе не ограничивается самим jQuery, а скорее авторами/плагинами.
Кроме того, как вы сказали, jQuery - это все о DOM - я вижу это как преимущество, потому что это означает, что jQuery не смешивается в "логике" (eh, "бизнес-логике" ) приложения... Это довольно хорошо на его собственном уровне абстракции - он имеет дело с DOM, и что все!
Вы можете создать неограниченное количество структур данных и дополнительных API для вашего приложения. jQuery не мешает вам в этом отношении.
Вы добавили более подробную информацию к своему вопросу - это "редактирование" в ответ на эти детали.
Я думаю, что то, что вы испытываете, часто встречается, когда вы достигаете определенной стадии с помощью jQuery... API становится недостаточным. Вы не хотите DOM... Вам нужен хороший чистый API для вашего модуля, будь то аккордеон или сетка данных.
Лично я не считаю, что некоторые вещи должны быть объединены в "плагин jQuery" - это обычно означает жертвовать API - или прибегать к механизмам jQuery, таким как psuedo -event запускается через "триггер":
var someModule = $('#contain').someCoolModule();
someModule.trigger('initiate');
Я получаю то, что вы говорите, и я думаю, что согласен, но я также считаю важным иметь jQuery на совершенно отдельном уровне - забыть об этом - используйте его только тогда, когда вам нужно атаковать DOM.
Ответ 2
jQuery не требует какой-либо специальной разметки - вы можете написать селектор для любого объекта. Вы также можете использовать существующую ссылку DOM и превратить ее в объект jQuery следующим образом: $(domObject). На самом деле проще и более способным, чем пользовательские интерфейсы Yahoo.
Не нужно знать ваши селекторы, если у вас уже есть ссылка DOM... Это может быть источником вашего недоразумения.
Работая с обоими пользовательскими интерфейсами Yahoo и jQuery, позвольте мне сказать вам, что они обе большие библиотеки. Они предназначены для разных ролей, но оба имеют отличные подходы.
jQuery - это своего рода оболочка, упрощающая все, что связано с DOM, Ajax, выбором объектов, выполнением графики. Он имеет очень краткий и блестяще простой API, который абстрагирует всю совместимость с браузером.
jQuery использует принципиально разные дизайнерские концепции, чем большинство программистов-новичков. Это действительно ребенок-плакат о том, как использовать Javascript. Несколько лет назад было много незнания о силе Javascript. В основном, потому что большая часть javascript в Интернете была ужасной. Теперь, я думаю, большинство людей поняли, что Javascript является одним из наиболее подходящих языков. Он поддерживает несколько парадигм: функциональный, императивный, объектно-ориентированный (прототип, а не на основе классов), литералы данных....
jQuery использует Javascript в полной мере, используя каждый аспект своей конструкции, чтобы решить каждую проблему наиболее эффективным способом.
Я рассказываю всем людям, изучающим javascript, чтобы читать источник jQuery снова и снова, пока они не поймут это... Это будет сложно, но они закончатся, будучи намного лучшими программистами, с гораздо большим набором инструментов в их панели инструментов,
Это нечто вроде перпендикуляра к промыванию мозгов Java/.NET, которое должно дать каждому разработчику отвертку (OOP) и сказать им, что это идеальное решение каждой проблемы в программировании и жизни.
Что, это не так. Для каждой проблемы нужен другой инструмент. ООП хорош, но часто это плохая идея для некоторых проблем.
jQuery mixin-style plugin architecture действительно хороша. Различные, но очень эффективные, быстрые и простые в использовании.
jQuery является # 1 по какой-либо причине - он прост в использовании и невероятно мощный.
Пользовательский интерфейс Yahoo - это другой подход для другой проблемы. Это инструментарий пользовательского интерфейса, который имеет очень тяжелую абстракцию от DOM (против легкого подхода jQuery).
Вы обнаружите, что много времени изменяете, если вы намерены что-то вне нормы. (Это недостаток тяжеловесного подхода).
Это не платформа для разработки приложений. Это куча виджетов GUI.
Я использовал оба варианта. Нет никакой причины, по которой вы не можете использовать оба jQuery и пользовательский интерфейс Yahoo на одной странице, это два разных инструмента для различных проблем.
Я предлагаю включить jQuery-сайт/приложение, а затем включить jQuery UI-плагины по мере необходимости. Если вам нужен тяжеловесный материал, добавьте пользовательский интерфейс Yahoo. Но придерживайтесь jQuery для вашего сантехнического кода...
Учитесь у jQuery. Понимать мощь программирования массивов, обратных вызовов, литералов данных, обработки кода как данных и сохранения краткости. И что использование правильного инструмента для каждой проблемы означает гораздо более короткий и простой код.
Ответ 3
По моему мнению, YUI слабее в манипуляциях с DOM, но впереди в дизайне.
JQuery предназначен для тех, у кого мало или вообще отсутствует JavaScript (или общее кодирование). Его очень легко получить приложение и запустить.
YUI более читабельна, и любой программист может забрать его и очень быстро перейти из-за широкого использования методологий наилучшей практики.
Ответ 4
jQuery - отличная библиотека для манипуляций с DOM, и центрирование ее API вокруг селекторов является одной из причин, почему это так популярно сегодня. Дело в том, что jQuery не понадобится, если API DOM браузеров будет более последовательным и простым в использовании. И я согласен с Робертом Харви (см. Выше), что в качестве абстрактного слоя над DOM jQuery выполняется очень удобная работа.
Но, как я понимаю, вам не нравится система плагина jQuery и пользовательский интерфейс jQuery, а не сама основная библиотека. Лично я предпочитаю API стиля YUI для компонентов и виджетов, потому что при более высоком уровне абстракции элементы DOM становятся менее важными. Я думаю, причина, по которой авторы jQuery UI выбрали этот проект, - сделать API более совместимым с их основным продуктом, библиотекой jQuery. Но я не согласен с тем, что это было хорошее решение.
Ответ 5
-
jQuery предназначен для работы с DOM (то есть это язык, оптимизированный на веб-страницах).
-
вам потенциально нужно будет искать вещи, которые плагины jQuery автоматически создаются
Предположительно, если это уместно, плагин возвращает объект jQuery, с которым вы можете манипулировать, если только он плохо написан. В этом случае это, очевидно, ошибка плагина.
-
Если вы используете метод, который автоматически генерирует идентификаторы, тогда jQuery может быть не для вас. Однако, например, я использовал jQuery с Картами Google без особых проблем.
-
Если вы хотите добавить строку в таблицу автоматически, я уверен, что там есть плагин. Если нет, то не займет много времени, чтобы написать один.
Ответ 6
Я согласен с Computer Linguist. ООП не идеально подходит для всех возможных проблем.
В случае веб-разработки сначала нужно решить, какое решение нужно разрабатывать. Является ли решение по существу веб-страницей с интерактивными виджетами, встроенными в места, которые повышают интерактивность или являются полноценным RIA. JQuery, я считаю, подходит для первого случая, и это в основном нацелено на облегчение обработки DOM.
В случае приложений RIA предпочтительнее использовать инструментальные средства, работающие на более высоком уровне абстракции, потому что разработчик в этом случае имеет дело с виджетами и макетами, а не с HTML и css, которые находятся под ним. В этом случае использование объектно-ориентированных наборов инструментов, таких как YUI, Dojo или ExtJS, более удобно, поскольку они привносят подход к разработке настольных приложений (с его связанными преимуществами) в веб-домен.