DMD>>В статье описана библиотека jQuery. Разобраны ключевые моменты работы с библиотекой — нахождение элементов на странице, манипуляция объектной моделью документа, базовая анимация, работа с технологией AJAX. В статье приведено большое количество примеров работающего кода.
C>Сайт http://interface.eyecon.ro/ коряво отображается и потом вешает IE7. Хотя в мозилле все работает.
Здравствуйте, Tomahawk, Вы писали:
T>Подскажите пожалуйста, как используя jQuery динамически создать несколько элементов (скажем текстбоксов) и затем к ним обращаться как к массиву?
Во-первых,
$("#textBox")[1].val("two");
есть бессмыслица, т.к. "#" подразумевает вызов getElementById, который всегда возвращает один элемент.
Вообще, наличие нескольких элементов с одинаковым ID на одном уровне иерархии никакого смысла не имеет. Здесь нужно использовать css:
Здравствуйте, Mamut, Вы писали:
DMD>>>В статье описана библиотека jQuery. Разобраны ключевые моменты работы с библиотекой — нахождение элементов на странице, манипуляция объектной моделью документа, базовая анимация, работа с технологией AJAX. В статье приведено большое количество примеров работающего кода.
C>>Сайт http://interface.eyecon.ro/ коряво отображается и потом вешает IE7. Хотя в мозилле все работает.
M>Хм. У меня такого не наблюдается
Замечательный сайтик. Блокирует весь UI на XP.
Что ж там эти умельцы наваяли то...
M>Хотя в случае с ИЕ все может быть
C>>>Сайт http://interface.eyecon.ro/ коряво отображается и потом вешает IE7. Хотя в мозилле все работает. M>>Хм. У меня такого не наблюдается CS>Замечательный сайтик. Блокирует весь UI на XP.
Аааа. Я просто с Windows Server'а смотрел. На нем все нормально
CS>Что ж там эти умельцы наваяли то...
Просто доманстрации различных возможностей... Надо будет им отписать по жтому поводу.
эээ ребяты.... а зачем это все? расскажите? ну мне просто интересно нахрена уменьшать скорость и так медленного js? или вы хотите сказать что синтаксис этой библиотеки проще чем стандартный? не, действительно реально ктото это использует и оно ему удобно?
обычно у программистов уже есть свой оверлей со всеми стандартными функциями, а переделывать синтаксис орбражений в DOM зачем? XPath? реализуется если надо простым регспом, причем на стандартном сайте имхо такие извраты абсолютно не зачем.
Деревья, табы, ajax? обычно это стандартные контролы на стандартной обвязке там где оно надо — проинклюдили скрипт вызвали функцию и все.
Я не критикую мне просто интересно — реально удобно чтоли? вот не понимаю я зачем изобретать все вермя велосипед. использовать различные СВОИ шаблонизаторы вместо xslt+xml, использовать фреймворки для JS. зачем?
I>эээ ребяты.... а зачем это все? расскажите? ну мне просто интересно нахрена уменьшать скорость и так медленного js? или вы хотите сказать что синтаксис этой библиотеки проще чем стандартный? не, действительно реально ктото это использует и оно ему удобно?
Я это реально пользую и это мне реально удобно.
I>обычно у программистов уже есть свой оверлей со всеми стандартными функциями, а переделывать синтаксис орбражений в DOM зачем? XPath? реализуется если надо простым регспом, причем на стандартном сайте имхо такие извраты абсолютно не зачем.
Там не только XPath, там и CSS селекторы. Которые во много раз удобнее, чем getElementById + getElmentsByTagName
I>Деревья, табы, ajax? обычно это стандартные контролы на стандартной обвязке там где оно надо — проинклюдили скрипт вызвали функцию и все.
Что такое стандартные контролы в стандартной обвязке?
Некоторые плагины приведены, как примеры того, что может являться плагином в jQuery
I>Я не критикую мне просто интересно — реально удобно чтоли? вот не понимаю я зачем изобретать все вермя велосипед. использовать различные СВОИ шаблонизаторы вместо xslt+xml, использовать фреймворки для JS. зачем?
Что за свои шаблонизаторы? В статье об этом ни слова
Теперь развернутый ответ.
Что такое фреймворк? Это набор функций, облегчающий выполнение каких-то действий. Каждый раз, когда программист говорит "обычно у программистов уже есть свой оверлей со всеми стандартными функциями", это надо читать так: "а у нас уже свой фреймворк используется".
Что такое jQuery? Это невероятно маленький (последняя версия — 20KB в сжатом виде) и один из самых быстрых доступных JS-фреймворков. То есть jQuery предлагает набор функций, облегчающих жизнь программисту.
) на jQuery решаются легко и весело. Потому что набор функций в jQuery гениален до неприличия.
Пример. Код используется у меня в примерах по jQuery (надо бы их обновить...):
// находим все элементы с class="ex" (это ссылки)
// и присваиваем им в onclick функцию
$(".ex").click(
function() // при клике по ссылке с class=".ex" будет вызвана эта функция
{
var a = $(this);
// показываем элемент с id="loader"
$("#loader").show("fast");
// находим элемент с id="example"
$("#example")
.animate({height: "hide"}, "fast") // прячем его
.find("#anchors").empty() // в нем находим элемент с id="anchors" и очищаем его контент
.end() // возвращаемся к элементу с id="anchors"
.find("div").remove() // находим все div'ы (внутри элемента с id="example") и удаляем их
.end() // возвращаемся к элементу с id="anchors"
.animate( // прячем (опять? видать баг в коде :) )
{height: "hide"}, // схлопываем по высоте"fast", // быстроfunction() // по завершении вызываем функцию, в которой
{
// берем значение из аттрибута href кликнутой ссылки
// и подгружаем с этой ссылке контент с помощью ajax'а
$.get(a.attr("href") + "?" + Math.random(), handleResponse);
}
);
return false;
}
);
Этот пример показывает некоторые проблемы, которые на голом JS решаются неудобно:
// находим все элементы с классом ex и присваиваем им onclick
$(".ex").click(...
// аналогvar a = getElementsByTagName("a");
for(i = 0; i < a.length; i++)
{
if(a.className == "ex")
{
a.onclick = ...
}
}
Или:
// находим все элементы div внутри элемента с id="example"
$("#example").find("div")
// аналог
?????????
Причем такие проблемы возникают на самом деле чаще, чем кажется. Просто работа с чистым JS или слабым фреймворком заставляет заранее избегать таких постановок задач. С jQuery становится нестрашен практически по-любому сформированный документ.
Например, один мой товарищ получает списки цен в виде HTML. Ему надо выводить сумму. Решение? Простейше на jQuery. См. http://dmitriid.com/jquery — "Excel руками". Решение занимает четыре строчки. Для того, чтобы его написать, мне понадобилось меньше пяти минут. И так — во всем
Здравствуйте, chardex, Вы писали: C>Сайт http://interface.eyecon.ro/ коряво отображается и потом вешает IE7. Хотя в мозилле все работает.
XP Prof SP2; IE 7.0 — всё ок.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, ionicman, Вы писали:
I>эээ ребяты.... а зачем это все? расскажите? ну мне просто интересно нахрена уменьшать скорость и так медленного js?
Не уменьшает. I> или вы хотите сказать что синтаксис этой библиотеки проще чем стандартный?
Проще. I>не, действительно реально ктото это использует и оно ему удобно?
Конечно.
I>обычно у программистов уже есть свой оверлей со всеми стандартными функциями, а переделывать синтаксис орбражений в DOM зачем? XPath? реализуется если надо простым регспом,
Не смеши мои тапочки. XPath он регекспом реализовал. Для некоторых частных примитивных случаев действительно можно применить регексп. (хотя даже аналог p[class="content"] ты уже заколебешься регекспом воспроизводить). А дальше что? Напомню, регексп работает с текстом, а не с DOM. Как ты собрался доступ к элементу получать? Ну вот покажи мне, как на регекспах спрятать (display=none) все P c классом content. I> причем на стандартном сайте имхо такие извраты абсолютно не зачем.
Что есть "стандартный сайт"? Вот это что ли?
Современные сайты далеко ушли от "хранилищ гипертекстовых документов". Кроме того, jQuery — скорее не для сайтов, а для веб-приложений. Для них специфичны повышенные требования к интерактивности. I>Деревья, табы, ajax? обычно это стандартные контролы на стандартной обвязке там где оно надо — проинклюдили скрипт вызвали функцию и все.
Во-первых, "обычно" стандартные контролы представляют собой малопригодный отстой, нуждающийся в существенном обтачивании напильником.
Во-вторых, что ты будешь делать, когда не найдешь готового контрола?
В-третьих, на основе чего пишутся эти контролы? Ты же не думаешь, что их в капусте находят? I>Я не критикую мне просто интересно — реально удобно чтоли?
Реально. I>вот не понимаю я зачем изобретать все вермя велосипед. использовать различные СВОИ шаблонизаторы вместо xslt+xml, использовать фреймворки для JS. зачем?
А что, уже все фреймворки написаны?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
А>Есть одно довольно таки неприятное "НО" в IE происходит утечка памяти при анонимных функция которые очень часто используются в подобного типа библиотеках
дело вовсе не в анонимных функциях, а в том что в контекст замыканий кладется ссылка на DOM объект.
решается очень просто везде где пользуются ссылки на ДОМ заменить на строки с id, а где надо к объектам обратится делать
getElementByID(), давно так делаю нигде ничего ни капельки не течет
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, ionicman, Вы писали:
I>>эээ ребяты.... а зачем это все? расскажите? ну мне просто интересно нахрена уменьшать скорость и так медленного js? S>Не уменьшает.
Дорогой мой, я те расскужо кой что — тока ты не обижайся :D
Есть у меня контрол самописный, небольшой — строчек 50-60. в нем динамически создаются элементы очень простецкой функцией на JS, типа createElement — примеров полно — если надо сорец кину. так вот на страничке таких контролов 10-12 штук, и если заменить вызов этой простецкой функции на более гемороидальное и большое document.createElement & тупое присваивание attributeNode скорость вырастает % на 35-40. Ты в jQuery.js заходил? зайди погляди. подумай, действительно ли не уменьшает. ну или можь мелкий бенчмарк забацать и проверить разницу getById.getById несколько раз и запросм jQuery.
I>> или вы хотите сказать что синтаксис этой библиотеки проще чем стандартный? S>Проще.
Сугубо ИМХО — ну да ладно :D
I>>обычно у программистов уже есть свой оверлей со всеми стандартными функциями, а переделывать синтаксис орбражений в DOM зачем? XPath? реализуется если надо простым регспом, S>Не смеши мои тапочки. XPath он регекспом реализовал.
Для простых случаев достаточно легко, для более сложных делается цепочка регспов, и при работе они в нужной последовательности перещелкиваются.
НЕ, я просто в шоке, человек использующий jQuery видимо даже ни разу в листинг ее не лазил — не ужто не интересно было?
Там кстати так и сделано. для быстроты правда коечто выкинуто из рекспов и реализовано через методы string, но суть таже.
S>собрался доступ к элементу получать? Ну вот покажи мне, как на регекспах спрятать (display=none) все P c классом content.
Кстати очень тупой вариант могу предложить — бежать тупо вперед по DOM, брать каждый объект-примитив — когда все в строчку засовывается и пробегать тупо аля /.*tagName='P'.*className='content'.*/ для примера вполне сгодится. тока надо глянуть что впереди в примитиве идет tagName или className
I>> причем на стандартном сайте имхо такие извраты абсолютно не зачем. S>Что есть "стандартный сайт"? Вот это что ли?
За ответом что это есть походи по сайтам любых контор сайто девелопперских. Там разжовано 300 раз.
S>Во-первых, "обычно" стандартные контролы представляют собой малопригодный отстой, нуждающийся в существенном обтачивании напильником. S>Во-вторых, что ты будешь делать, когда не найдешь готового контрола?
напишу сам достаточно быстро либо же воспользуюсь готовым паттерном, скаченным из библиотеки
S>В-третьих, на основе чего пишутся эти контролы? Ты же не думаешь, что их в капусте находят?
ээээ.....
"обычно у программистов уже есть свой оверлей со всеми стандартными функциями" типо выше написано было
S>А что, уже все фреймворки написаны?
Ну их достаточно на самом деле. Если уж ты так офигенно любишь fw — юзай Ruby-on-rails. Че, неужели плохой? :D
Здравствуйте, Mamut, Вы писали:
I>>эээ ребяты.... а зачем это все? расскажите? ну мне просто интересно нахрена уменьшать скорость и так медленного js? или вы хотите сказать что синтаксис этой библиотеки проще чем стандартный? не, действительно реально ктото это использует и оно ему удобно?
M>Я это реально пользую и это мне реально удобно.
очень может быть. я по этому и написал чтобы выяснить кто и зачем пользуется.
I>>обычно у программистов уже есть свой оверлей со всеми стандартными функциями, а переделывать синтаксис орбражений в DOM зачем? XPath? реализуется если надо простым регспом, причем на стандартном сайте имхо такие извраты абсолютно не зачем.
M>Там не только XPath, там и CSS селекторы. Которые во много раз удобнее, чем getElementById + getElmentsByTagName
Кстати говори XPath не полный к сожелению. мне бы гораздо удобнее был XPath, хотя селекторы тоже интересно.
I>>Деревья, табы, ajax? обычно это стандартные контролы на стандартной обвязке там где оно надо — проинклюдили скрипт вызвали функцию и все.
M>Что такое стандартные контролы в стандартной обвязке?
Имеется ввиду что есть куча контролов уже написанных "самих в себе" требующих лишь их проинклюдить и вызвать
M>Что за свои шаблонизаторы? В статье об этом ни слова
Просто такаяже распространенная тема как и фреймворки. Шаблонизаторы модель "данные отдельно от дизайна" например :D
M>Теперь развернутый ответ.
M>Что такое фреймворк? Это набор функций, облегчающий выполнение каких-то действий. Каждый раз, когда программист говорит "обычно у программистов уже есть свой оверлей со всеми стандартными функциями", это надо читать так: "а у нас уже свой фреймворк используется".
Так оно и есть, мне просто интересно почему именно такой способ используете, чем он лучше чем набор DOMа + несколько небольших функций. быстродействие то ведь страдает.
M>Что такое jQuery? Это невероятно маленький (последняя версия — 20KB в сжатом виде) и один из самых быстрых доступных JS-фреймворков. То есть jQuery предлагает набор функций, облегчающих жизнь программисту.
M>Этот пример показывает некоторые проблемы, которые на голом JS решаются неудобно: M>
M>// находим все элементы с классом ex и присваиваем им onclick
M>$(".ex").click(...
M>// аналог
M>var a = getElementsByTagName("a");
M>for(i = 0; i < a.length; i++)
M>{
M> if(a.className == "ex")
M> {
M> a.onclick = ...
M> }
M>}
M>
Ну почемуж:
вот кусок очень старой фии:
function GetElementByProp( o, prop, propval ) {
GetElementByProp.GEBarr = [];
GetElementByProp.GEBprop = prop;
GetElementByProp.GEBpropval = null;
return GetElementByProp.internal( o )
}
function GetElementByProp.internal( o ) {
if ( o.getAttribute && o.getAttribute( GEBprop ) == GEBpropval ) GetElementByProp.GEBarr.push( o );
o = o.firstChild;
while ( o != null ) {
GetElementByProp.internal( o );
o = o.nextSibling;
}
}
За код не ручаюсь — по памяти писал — ну чтото типа этого и производные от него.
С помощью нее достаточно просто путешествовать и достаточно быстро. Но опережая Ваши возражения — конечно не так удобно, как с jQuery, однако гораздо быстрей.
Это знаете, был такой холивар в фидо давано давно — что тербуется бизнес продукут — удобство клиентам, либо же простота
и скорость разработки. Это я в том смысле что выигрывая в удобности для программиста обычно приложение проигрывает в скорости выполнения для клиента.
M>// находим все элементы div внутри элемента с id="example"
GetElementByProp( document.body, "id", "example" )[0].getElementsByTagName("div")
ну илиже GetElementByProp( document.body, "id", "example" )[0].GetElementByProp( document.body, "tagName", "div" ),
но второй медленнее
M>Причем такие проблемы возникают на самом деле чаще, чем кажется. Просто работа с чистым JS или слабым фреймворком заставляет заранее избегать таких постановок задач. С jQuery становится нестрашен практически по-любому сформированный документ.
ну если честно, у меня и при plain js таких проблем не возникало. Они обычно возникают изза плохо продумывания и алгоритмизации, а также изза недостаточной универсальностти подходов при программировании. Если серъезно обдумать проект и набросать вехи на бумаге — обычно не встречается таких проблем. Это так называемый "дизайн программы"
M>Например, один мой товарищ получает списки цен в виде HTML. Ему надо выводить сумму. Решение? Простейше на jQuery.
ну список цен в виде HTML — это по моему самый простой пример неправильного "дизайна" — не считаете? :D
Хотя если с таким столкнуться, я бы не стал загружать спсиок в DOM — зачем? проще пропарсить регспами будет в данном случае — и быстрей гораздо? я не прав?
M>Решение занимает четыре строчки. Для того, чтобы его написать, мне понадобилось меньше пяти минут. И так — во всем
Спс, хоть один человек толково объяснить смог. а не затруднит ответить на вопрос?
всежтаки в серъезных проэктах очень критично две вещи — быстродействие и долгое незакрыти браузера ( у ff кстати есть офигенная привычка разрастаться от этого в памяти при использовании объектов, у IE + к этому — начинаются тормоза и он в конце концов умирает — в 6-ке было так 7 не мучал еще ), что можно сказать в отчношении jQuery?
I>>>обычно у программистов уже есть свой оверлей со всеми стандартными функциями, а переделывать синтаксис орбражений в DOM зачем? XPath? реализуется если надо простым регспом, причем на стандартном сайте имхо такие извраты абсолютно не зачем.
M>>Там не только XPath, там и CSS селекторы. Которые во много раз удобнее, чем getElementById + getElmentsByTagName I>Кстати говори XPath не полный к сожелению. мне бы гораздо удобнее был XPath, хотя селекторы тоже интересно.
XPath я, например, вообще не использую (разве что $("elem[@attr='']")). Необходимость получать элементы по интересным комбинациям CSS-селекторов встречается чаще. И обычно в таких комбинациях:
$("#myid > div")
$(".articles div:nth(odd)")
и т.п.
Полный XPath поддерживать сложно, потому что все это — эмуляция, так как браузеры не обеспечивают нативную поддержку ни XPath ни CSS selectors
I>>>Деревья, табы, ajax? обычно это стандартные контролы на стандартной обвязке там где оно надо — проинклюдили скрипт вызвали функцию и все.
M>>Что такое стандартные контролы в стандартной обвязке? I>Имеется ввиду что есть куча контролов уже написанных "самих в себе" требующих лишь их проинклюдить и вызвать
Не такие уж эти контролы и стандартные
Мы, например, используем такие же "стандартные" контролы и для jQuery: Tabs и календарь
M>>Что за свои шаблонизаторы? В статье об этом ни слова I>Просто такаяже распространенная тема как и фреймворки. Шаблонизаторы модель "данные отдельно от дизайна" например :D
Ааа. MVC. Это лучше всего разруливается на стороне сервера, чем клиента.
M>>Теперь развернутый ответ.
M>>Что такое фреймворк? Это набор функций, облегчающий выполнение каких-то действий. Каждый раз, когда программист говорит "обычно у программистов уже есть свой оверлей со всеми стандартными функциями", это надо читать так: "а у нас уже свой фреймворк используется". I>Так оно и есть, мне просто интересно почему именно такой способ используете, чем он лучше чем набор DOMа + несколько небольших функций. быстродействие то ведь страдает.
Почему же страдает? Вот сейчас сделал замер: Общая стоимость загрузки всей страницы — 1.7 секунд (без яваскрипта). Профайлер дал (264.365ms, 3915 calls) для JS. Это — на одной из самых тяжелых страниц. На нее навешано 200 KB (!) только яваскрипта. Путем сжатия всех библиотек и оптимизации это можно снизить килобайтов до 50
I>Ну почемуж: I>вот кусок очень старой фии: I>
I> function GetElementByProp.internal( o ) {
скип...
I> }
I>
I>За код не ручаюсь — по памяти писал — ну чтото типа этого и производные от него. I>С помощью нее достаточно просто путешествовать и достаточно быстро. Но опережая Ваши возражения — конечно не так удобно, как с jQuery, однако гораздо быстрей.
Зачем мне быстрей, если мне надо удобно Да и разницу в 10-20 миллисекунд вряд ли кто заметит: http://dev.jquery.com/~john/slick/
I>Это знаете, был такой холивар в фидо давано давно — что тербуется бизнес продукут — удобство клиентам, либо же простота I>и скорость разработки. Это я в том смысле что выигрывая в удобности для программиста обычно приложение проигрывает в скорости выполнения для клиента.
Не в случае с jQuery. Нет, конечно, можно наворотить тааакооого!
M>>// находим все элементы div внутри элемента с id="example" I>GetElementByProp( document.body, "id", "example" )[0].getElementsByTagName("div") I>ну илиже GetElementByProp( document.body, "id", "example" )[0].GetElementByProp( document.body, "tagName", "div" ), I>но второй медленнее
Это всяко будет медленнее, чем getElementById
M>>Причем такие проблемы возникают на самом деле чаще, чем кажется. Просто работа с чистым JS или слабым фреймворком заставляет заранее избегать таких постановок задач. С jQuery становится нестрашен практически по-любому сформированный документ.
I>ну если честно, у меня и при plain js таких проблем не возникало. Они обычно возникают изза плохо продумывания и алгоритмизации, а также изза недостаточной универсальностти подходов при программировании. Если серъезно обдумать проект и набросать вехи на бумаге — обычно не встречается таких проблем. Это так называемый "дизайн программы"
У нас был такой случай. Выводится на экран довольно большая таблица с данными. В какой-то момент мы поняли, что надо визуально показывать юзеру, надж какой строчкой в таблице он находится. Вписывать в каждый tr onmouseover не хотелось. Плюс хотелось, чтобы при клике выбранная строка меняла свой цвет... В общем:
$(document).ready(
function() {
$("#blocks tr") // находим все tr внутри элемента с id="blocks"
.hover(
function() { // onmouseovervar t = $(this);
if(t.attr('class') != 'selected')
t.css("background-color", "#efefef");
else
t.css("background-color", "#FFFF66");
},
function() { // onmouseoutvar t = $(this);
if(t.attr('class') != 'selected')
t.css("background-color", "#fff");
else
t.css("background-color", "#FFFF99");
}
)
.click( // onclickfunction() {
var t = $(this);
t.toggleClass('selected');
if(t.attr('class') == 'selected')
t.css("background-color", "#FFFF66");
}
);
}
)
M>>Например, один мой товарищ получает списки цен в виде HTML. Ему надо выводить сумму. Решение? Простейше на jQuery. I>ну список цен в виде HTML — это по моему самый простой пример неправильного "дизайна" — не считаете? :D
в том случае не было вариантов — файл он получал сос тороны и изменить ситуацию было нельзя.
I>Хотя если с таким столкнуться, я бы не стал загружать спсиок в DOM — зачем? проще пропарсить регспами будет в данном случае — и быстрей гораздо? я не прав?
сложно сказать. в той его ситуации было легче использовать jQuery. Потому что парсинг HTML — все же нетривиальная вещь.
M>>Решение занимает четыре строчки. Для того, чтобы его написать, мне понадобилось меньше пяти минут. И так — во всем I>Спс, хоть один человек толково объяснить смог. а не затруднит ответить на вопрос? I>всежтаки в серъезных проэктах очень критично две вещи — быстродействие и долгое незакрыти браузера ( у ff кстати есть офигенная привычка разрастаться от этого в памяти при использовании объектов, у IE + к этому — начинаются тормоза и он в конце концов умирает — в 6-ке было так 7 не мучал еще ), что можно сказать в отчношении jQuery?
Не знаю. У меня ни проблем с быстродействием ни проблем с закрытием браузера не было
Тем более, что jQuery — это не библиотека типа script.aculo.us. Она не содержит виджетов, контролов и прочая и прочая. Она является очень простым фундаментом, на основе которого можно сделать очень многое — в том числе и виджеты и контролы и проч. Но при этом уже "голый" jQuery — это гигантское ускорение разработки, когда нужно довольно много манипулировать DOM'ом или работать с AJAX'ом
Согласен, частенько бывает. M>и т.п.
M>Полный XPath поддерживать сложно, потому что все это — эмуляция, так как браузеры не обеспечивают нативную поддержку ни XPath ни CSS selectors
есть полная реализация на js XPath 1.0 100k
M>>>Что за свои шаблонизаторы? В статье об этом ни слова I>>Просто такаяже распространенная тема как и фреймворки. Шаблонизаторы модель "данные отдельно от дизайна" например :D
M>Ааа. MVC. Это лучше всего разруливается на стороне сервера, чем клиента.
ага, оно самое
M>Не в случае с jQuery. Нет, конечно, можно наворотить тааакооого!
)))
M>>>// находим все элементы div внутри элемента с id="example" I>>GetElementByProp( document.body, "id", "example" )[0].getElementsByTagName("div") I>>ну илиже GetElementByProp( document.body, "id", "example" )[0].GetElementByProp( document.body, "tagName", "div" ), I>>но второй медленнее
M>Это всяко будет медленнее, чем getElementById
но быстрее jQuery :D
M>У нас был такой случай. Выводится на экран довольно большая таблица с данными. В какой-то момент мы поняли, что надо визуально показывать юзеру, надж какой строчкой в таблице он находится. Вписывать в каждый tr onmouseover не хотелось. Плюс хотелось, чтобы при клике выбранная строка меняла свой цвет... В общем:
Вот здесь кстати интересно очень. Щас объясню почему — у моего движка в качестве шаблонов используется XSLT+XML.
Т.е. мне не надо в кажлдом tr чтото дпроисывать — я в шаблоне в ставлю в один tr, остальное все сделает XSLT — и при этом никакой работы на стороне клиента — по моему гораздо более проще и быстрей. Правда конечнр, если такое ДЕЙСТВИТЕЛЬНО требуется на стороне клиента — тогда jQuery конечно выручает, согласен.
M>в том случае не было вариантов — файл он получал сос тороны и изменить ситуацию было нельзя. I>>Хотя если с таким столкнуться, я бы не стал загружать спсиок в DOM — зачем? проще пропарсить регспами будет в данном случае — и быстрей гораздо? я не прав? M>сложно сказать. в той его ситуации было легче использовать jQuery. Потому что парсинг HTML — все же нетривиальная вещь.
ну я так понимаю там были ячейки с цифрами — можно было бы чтото типа <td>([0-9]*)</td> — врядли чтото еще надо было.
M>Не знаю. У меня ни проблем с быстродействием ни проблем с закрытием браузера не было M>Тем более, что jQuery — это не библиотека типа script.aculo.us. Она не содержит виджетов, контролов и прочая и прочая. Она является очень простым фундаментом, на основе которого можно сделать очень многое — в том числе и виджеты и контролы и проч. Но при этом уже "голый" jQuery — это гигантское ускорение разработки, когда нужно довольно много манипулировать DOM'ом или работать с AJAX'ом
Согласен, но всеж таки если не затруднит — я так понимаю что Вы плотно рабоатет на jQ, засечь начальный объем памяти браузера а затем в конце дня. Просто очень интересно. Я так понимаю стоит FF?
M>>Полный XPath поддерживать сложно, потому что все это — эмуляция, так как браузеры не обеспечивают нативную поддержку ни XPath ни CSS selectors
I>есть полная реализация на js XPath 1.0 100k
Ого
M>>>>// находим все элементы div внутри элемента с id="example" I>>>GetElementByProp( document.body, "id", "example" )[0].getElementsByTagName("div") I>>>ну илиже GetElementByProp( document.body, "id", "example" )[0].GetElementByProp( document.body, "tagName", "div" ), I>>>но второй медленнее
M>>Это всяко будет медленнее, чем getElementById I>но быстрее jQuery :D
Не думаю, чтобы настолько, чтобы это было заметно пользователю А выигрыш в скорости разработки налицо:
$('#example > div')
// vs.
GetElementByProp( document.body, "id", "example" )[0].getElementsByTagName("div")
I>Вот здесь кстати интересно очень. Щас объясню почему — у моего движка в качестве шаблонов используется XSLT+XML. I>Т.е. мне не надо в кажлдом tr чтото дпроисывать — я в шаблоне в ставлю в один tr, остальное все сделает XSLT — и при этом никакой работы на стороне клиента — по моему гораздо более проще и быстрей. Правда конечнр, если такое ДЕЙСТВИТЕЛЬНО требуется на стороне клиента — тогда jQuery конечно выручает, согласен.
Это не всегда выгодно. Все же сотня записей onmouseover='что-то там' против одного вызова $('tr').hover опять же проиграет просто ценой размера страницы (и, как следствие, скоростью загрузки)
M>>в том случае не было вариантов — файл он получал сос тороны и изменить ситуацию было нельзя. I>>>Хотя если с таким столкнуться, я бы не стал загружать спсиок в DOM — зачем? проще пропарсить регспами будет в данном случае — и быстрей гораздо? я не прав? M>>сложно сказать. в той его ситуации было легче использовать jQuery. Потому что парсинг HTML — все же нетривиальная вещь. I>ну я так понимаю там были ячейки с цифрами — можно было бы чтото типа <td>([0-9]*)</td> — врядли чтото еще надо было.
Ему надо было выводить сумму по колонкам. Или в какой-то определенной колонке. Там простыми регэкспами не отмахаешься.
I>Согласен, но всеж таки если не затруднит — я так понимаю что Вы плотно рабоатет на jQ, засечь начальный объем памяти браузера а затем в конце дня. Просто очень интересно. Я так понимаю стоит FF?
Это сложно сделать Это надо выделить машину, на которой надо запустить ФФ и ничего не делать Просто у меня и ФФ и Опера активно используются, они постепенно растут в памяти и сами Поэтому доля jQuery там будет незаметна (если она есть)
На самом деле сама задача поставлена не совсем корректно. Потому что есть, грубо говоря, пассивное использование яваскрипта и активное (применительно к документу).
Это когда, например, по таймауту раз в десять секунд с сервера приодят данные и имзеняют, например, количесвто элементов на странице и их положение. Здесь уже Это зависит как от браузеров, так и от библиотеки. С этим активно борятся
Кстати. Эта активная борьба — одна из причин использовать подобный фреймворк, чем самописную библиотеку. Один человек не в состоянии охватить все проблемы, который могут возникунуть