Re[10]: jQuery – Javascript нового поколения
От: Mamut Швеция http://dmitriid.com
Дата: 27.07.07 08:08
Оценка: +1
I>Вот ты приколист однако. А может те сразу сайт написать — я те сделал пример, чтобы показать что ты нихрена в рекспах не разбираешься. Добавить и хайд и все остально 5 сек — не более. Обойти данную ситуацию — это добавить всего ОДИН символ в regexp. Угадай какой? правильно — делиметр.
S>>Ну что, знаток матчасти, попробуешь свой код поправить?

Дело в том, что нет универсального регэкспа. Любое нетривиальное измиенение в структуре документа — и? Регэкспы рулят, да, но поиска по DOM документа они сильно уступают универсальному решению типа jQuery. Да, внутри jQuery тоже используются регэкспы, но они используются там намного хитрее, чем в лоб.

Например, чего стоит только вот этот комментарий в коде, да и сам код:
// Do a quick check for the existence of the actual ID attribute
// to avoid selecting by the name attribute in IE
// also check to insure id is a string to avoid selecting an element with the name of 'id' inside a form

if ( (jQuery.browser.msie||jQuery.browser.opera) && oid && typeof oid.id == "string" && oid.id != m[2] )
    oid = jQuery('[@id="'+m[2]+'"]', elem)[0];


Более того, у решения jQuery есть один гениальный момент — расширяемость. Так, jQuery предлагает стандартный набор селекторов типа :last, :first, :nth и так далее. Есть возможность расширить этот набор своими селекторами, что нельзя сделать с жестко зашитым регэкспом.

Ну и так далее

I>см, выше. Опять доказываешь что ты ламер.


На RSDN есть правило — не оскорблять собеседников. Особенно, если собеседник — модератор

S>>Я думаю, всем заинтересованным и так видно, что написать 1 (одну) строчку jQuery, которая будет еще и делать именно то что надо, гораздо быстрее, чем отладить regex-based ужос, который ты пропагандируешь.


I>По моему спор не про это был, а про возможности регспа. Письмо свеже первое погляди, умник.


В оригинале было несколько вопросов:

Не смеши мои тапочки. XPath он регекспом реализовал. Для некоторых частных примитивных случаев действительно можно применить регексп. (хотя даже аналог p[class="content"] ты уже заколебешься регекспом воспроизводить). А дальше что? Напомню, регексп работает с текстом, а не с DOM. Как ты собрался доступ к элементу получать? Ну вот покажи мне, как на регекспах спрятать (display=none) все P c классом content.


Ключевой момент выделен. Этот кусок говорит не о том, что регэкспы сакс, а о том, что все покрыть регэкспами нельзя. Вернее, можно, но код сопровождать потом будет невозможно. Причем приведенный тобой код не использует XPath вообще

S>>Кроме того, в отличие от твоего кода этот можно читать. А ты через неделю и не вспомнишь, что именно у тебя в этих TreeGo делается. Тем более этого не поймет другой программист.


I>Хехе... вот по этому ты и хреновый программер. во первых все делается но ООП, и если грамотно — то при малом числе функций в коде гораздо проще разобраться, нежели учить синтаксис фреймворка, isn't it? Другое дело — если при плохом код-дизайне функции и их количство разрастается до невообразимого — тогда да.


Рассказываю про синтаксис фреймворка jQuery.

Программист думает: Надо найти элемент с id="i", в нем найти второй div с class="t" и скрыть его
Программист пишет: $("#i").find("div.t").hide()



В этом сила jQuery — как думается, так и пишется

S>>Небольшое усложнение или изменение исходной задачи — и ты снова день потратишь на отладку. А в jQuery можно за тридцать секунд справиться.

I>Я те по секрету расскажу: если мне надо чтото скрывать или показывать часто — то 90% это контрол а не контент — контейнер. А если же это контент — контейнер — то на его собачатся id, и делается потом getElementById — и все.

I>А вот внутри контрола если надо хитро бегать — там да, может пригодится jQuery — ибо с помощью нее это сделать быстрее, но работать будет медленнее если контрол шибко большой или шибко динамический.


10ms пользователь не заметит. ВОт у нас есть и шибко большие контролы и шибко динамические — у нас shopping cart построен на jQuery + Taconite. Ничего. Все летает

I>А если ты в случае простых страничек с 2-3 контент контейнерами бужешь jQuery юзать — то это примерно тоже самое что в ларек за пивом на ракете лететь, умник.


Эээ нет. $("#elem").hide() во-первых проще, во-вторых быстрее в написании, в третьих на .01ms медленнее, чем, скажем, getElementById('elem').style.display = 'none'. Зачем мне использовать второе, если можно использовать первое?

Кстати. О простых страничках. http://dmitriid.com/jquery Очень простая страничка. Примеры там тоже тривиальные (видно из кода). Кода на plain js там будет раз в нцать больше, чем с jQuery. А "медленный" jQuery во-первых летает, как реактивный самолет и, во-вторых, позволил слабать ту страничку за полчаса (при том, что я написал свой собственный загрузчик из XML файла со своей структурой)


dmitriid.comGitHubLinkedIn
Re[11]: jQuery – Javascript нового поколения
От: ionicman  
Дата: 27.07.07 08:08
Оценка:
M>Какие такие static классы в JS?
Не правильно видимо я выразился. Короче имел ввиду на объектах без создания экземпляра ) Я их статическим называю — поскольку Сишник с детства — а там они static обзываются :D
Re[11]: jQuery – Javascript нового поколения
От: ionicman  
Дата: 27.07.07 08:21
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Дело в том, что нет универсального регэкспа. Любое нетривиальное измиенение в структуре документа — и? Регэкспы рулят, да, но поиска по DOM документа они сильно уступают универсальному решению типа jQuery.

Согласен, но большинство базовых задач они позволяет вполне реализвать безо всяких проблем )

M>Да, внутри jQuery тоже используются регэкспы, но они используются там намного хитрее, чем в лоб.

О, вот это согласен — ребята очень потрудились — я когда код смотрел — очень понравилось. факт

M>Более того, у решения jQuery есть один гениальный момент — расширяемость. Так, jQuery предлагает стандартный набор селекторов типа :last, :first, :nth и так далее. Есть возможность расширить этот набор своими селекторами, что нельзя сделать с жестко зашитым регэкспом.

Ага, я еще вчера доку осилил — нормально так. тока не понравилась как с аргументами плагин — ну да можно привыкнуть.

I>>см, выше. Опять доказываешь что ты ламер.


M>На RSDN есть правило — не оскорблять собеседников. Особенно, если собеседник — модератор

Да я просто не люблю когда люди понты кидают, а модератор он или нет — мне все равно — забанит — перерегистрируюсь ))

M>В оригинале было несколько вопросов:


Я имел ввиду что на регспе можно сделать выборку элементов — не такую универсальную — но вполне приемлимую. На ней же можно сделать и XPath — я сслыку кидал выше там реализвано на Strings + Regexp — да и в jQuery также )

M>В этом сила jQuery — как думается, так и пишется

Дак не об этом спор то был ) против jQury ниче не имею )) наоброт кое что уяснил — во всяком случае область применения )

M>10ms пользователь не заметит. ВОт у нас есть и шибко большие контролы и шибко динамические — у нас shopping cart построен на jQuery + Taconite. Ничего. Все летает

а поглядеть бы? можно?

I>>А если ты в случае простых страничек с 2-3 контент контейнерами бужешь jQuery юзать — то это примерно тоже самое что в ларек за пивом на ракете лететь, умник.


M>Эээ нет. $("#elem").hide() во-первых проще, во-вторых быстрее в написании, в третьих на .01ms медленнее, чем, скажем, getElementById('elem').style.display = 'none'. Зачем мне использовать второе, если можно использовать первое?

Ну хотябы для экономии размеров загружаемых данных — 20 кб при страничке в 10кб?

M>Кстати. О простых страничках. Очень простая страничка. Примеры там тоже тривиальные (видно из кода). Кода на plain js там будет раз в нцать больше, чем с jQuery. А "медленный" jQuery во-первых летает, как реактивный самолет и, во-вторых, позволил слабать ту страничку за полчаса (при том, что я написал свой собственный загрузчик из XML файла со своей структурой)


просто обычно это начинает быть заметным при разростании проекта, при усложнении страниц на нем. хотя как знать — может быть jQuery, хотя я пытаюсь как можно больше облегчить страницу и js на ней. Да приходится за это расплачиавться необходимым временем. но всеж таки?
Re[12]: jQuery – Javascript нового поколения
От: Mamut Швеция http://dmitriid.com
Дата: 27.07.07 08:26
Оценка:
I>Не правильно видимо я выразился. Короче имел ввиду на объектах без создания экземпляра ) Я их статическим называю — поскольку Сишник с детства — а там они static обзываются :D

Хм. А что ты имеешь в виду?

Например:
$('.className') // один набор элементов
$('div > p') // другой набор элементов

$('#myelem').find('span :nth(odd)') // третий и четвертый набор


Как их можно найти без создания экземпляра? На самом деле, там создается не по одному экземпляру на каждый объект, а один объект jQuery на каждый набор, который содержит массив найденных элементов.

Что дает объект jQuery? Он дает возможность моментально применять к массиву выбранных элементов все фнкции как jQuery, так и любых плагинов.

Единственная альтернатива — это расширять DOM дополнительными функциями (как делает Prototype). Но это довольно грязно и мешает функциям, которые работают с DOM напрямую.


dmitriid.comGitHubLinkedIn
Re[13]: jQuery – Javascript нового поколения
От: ionicman  
Дата: 27.07.07 08:30
Оценка:
Здравствуйте, Mamut, Вы писали:


I>>Не правильно видимо я выразился. Короче имел ввиду на объектах без создания экземпляра ) Я их статическим называю — поскольку Сишник с детства — а там они static обзываются :D


M>Хм. А что ты имеешь в виду?


M>Например:

M>
M>$('.className') // один набор элементов
M>$('div > p') // другой набор элементов

M>$('#myelem').find('span :nth(odd)') // третий и четвертый набор
M>


M>Как их можно найти без создания экземпляра? На самом деле, там создается не по одному экземпляру на каждый объект, а один объект jQuery на каждый набор, который содержит массив найденных элементов.


Да, это и имел ввиду. Так вот попытаться реализовать передачу данных на статике. Это сложно так как возможен конфлик данных если внутри одной из фй чейна организуется тоже чейн. Но вот сдается мне что можно. :D

M>Что дает объект jQuery? Он дает возможность моментально применять к массиву выбранных элементов все фнкции как jQuery, так и любых плагинов.


Это то понятно

M>Единственная альтернатива — это расширять DOM дополнительными функциями (как делает Prototype). Но это довольно грязно и мешает функциям, которые работают с DOM напрямую.


Не, ну это уже совсем грустно.
Re[12]: jQuery – Javascript нового поколения
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.07.07 08:34
Оценка:
Здравствуйте, ionicman, Вы писали:

I>Я те так отвечу:

I>почитай webmascon.com / xpoint.ru / xhtml.ru

I>Потом перевари это все, наберись опыта — и поболтаем )
Интересно, а каким способом ты оценил мой нынешний опыт? Наверное, в профиле подглядел, да?

I>Менеджер из тебя хороший бы получился — гонора много :D

Спасибо. Я обязательно скажу об этом своему руководству на следующей аттестации.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: jQuery – Javascript нового поколения
От: Mamut Швеция http://dmitriid.com
Дата: 27.07.07 08:40
Оценка:
M>>Дело в том, что нет универсального регэкспа. Любое нетривиальное измиенение в структуре документа — и? Регэкспы рулят, да, но поиска по DOM документа они сильно уступают универсальному решению типа jQuery.
I>Согласен, но большинство базовых задач они позволяет вполне реализвать безо всяких проблем )

Задачи быстро перестают быть базовыми. Структура документа может быть изменена радикально (а что, прришел новый дизайнер и все переиграл ). Гораздо легче изначально использовать инструмент, требующий минимум усилий для изменения поведения. Сравним:
if ( /(classname *?= *?ext.*?tagname *?= *?div)|(tagname *?= *?div.*classname *?= *?ext)/i.test( getPrimitive( o ) ) )

и
$('.className')




M>>Да, внутри jQuery тоже используются регэкспы, но они используются там намного хитрее, чем в лоб.

I>О, вот это согласен — ребята очень потрудились — я когда код смотрел — очень понравилось. факт

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

M>>На RSDN есть правило — не оскорблять собеседников. Особенно, если собеседник — модератор

I>Да я просто не люблю когда люди понты кидают, а модератор он или нет — мне все равно — забанит — перерегистрируюсь ))

Он имеет право понты кидать, поверь

M>>В этом сила jQuery — как думается, так и пишется

I>Дак не об этом спор то был ) против jQury ниче не имею )) наоброт кое что уяснил — во всяком случае область применения )

Область применения — везде, где нужна работа с DOM'ом. Единственное, где его не стоит, наверное, применять — там, где суммарный вес сайта меньше, чем библиотека в зазипованном виде

M>>10ms пользователь не заметит. ВОт у нас есть и шибко большие контролы и шибко динамические — у нас shopping cart построен на jQuery + Taconite. Ничего. Все летает

I>а поглядеть бы? можно?

Ну, наш проект пока в разработке. А вообще можно посмотреть Sites Using jQuery

M>>Эээ нет. $("#elem").hide() во-первых проще, во-вторых быстрее в написании, в третьих на .01ms медленнее, чем, скажем, getElementById('elem').style.display = 'none'. Зачем мне использовать второе, если можно использовать первое?

I>Ну хотябы для экономии размеров загружаемых данных — 20 кб при страничке в 10кб?

Только тогда можно думать об экономии.

M>>Кстати. О простых страничках. Очень простая страничка. Примеры там тоже тривиальные (видно из кода). Кода на plain js там будет раз в нцать больше, чем с jQuery. А "медленный" jQuery во-первых летает, как реактивный самолет и, во-вторых, позволил слабать ту страничку за полчаса (при том, что я написал свой собственный загрузчик из XML файла со своей структурой)


I>просто обычно это начинает быть заметным при разростании проекта, при усложнении страниц на нем. хотя как знать — может быть jQuery, хотя я пытаюсь как можно больше облегчить страницу и js на ней. Да приходится за это расплачиавться необходимым временем. но всеж таки?


Да не становится это при разрастании проекта Когда страница — 200 KB, а jQuery — 20 KB или когда скорость отрисовки страницы — 1-5 секунд, а скорость отработки jQuery — 200ms, это просто незаметно. При том, что очень редко функции в js работают настолько долго. Всякие .append, .hide и прочие работают в пределах 20ms.


dmitriid.comGitHubLinkedIn
Re[13]: jQuery – Javascript нового поколения
От: ionicman  
Дата: 27.07.07 09:05
Оценка:
M>Задачи быстро перестают быть базовыми. Структура документа может быть изменена радикально (а что, прришел новый дизайнер и все переиграл ). Гораздо легче изначально использовать инструмент, требующий минимум усилий для изменения поведения. Сравним:

А я объяснял уже ) у меня например XML+XSLT ( на самом деле все равно какой движок лишь бы данные отдельно были ), ну и дизайнерам запрещено трогать id — в том смысле они могут его присвоить просто другому элементу но не изменить — и я еще ни разу не менял программинг изза дизайна. правда :D

На
M>
M>if ( /(classname *?= *?ext.*?tagname *?= *?div)|(tagname *?= *?div.*classname *?= *?ext)/i.test( getPrimitive( o ) ) )
M>


это кстати для IE & FF сделано такто она ровно в 2 раза меньше )
но на jQuery элегантней — не спорю.

M>Он имеет право понты кидать, поверь

Ну не знаю — тыже не кидаешь? :D На самом деле если человек достаточно знает — он никогда кидать понты не будет
— потому что он знает :D

Мне больше всего понравились заявления что пример написан плохо, что нет ООП и массив глобальный — ваще ржал. Пример на то и пример ) Видимо хотелось человеку шоб я ему сделал с fade эффектами, табами, и анимацией сразу :D

M>Область применения — везде, где нужна работа с DOM'ом. Единственное, где его не стоит, наверное, применять — там, где суммарный вес сайта меньше, чем библиотека в зазипованном виде


Ну не сайта — страничек уж тогда ))

M>>>Кстати. О простых страничках. Очень простая страничка. Примеры там тоже тривиальные (видно из кода). Кода на plain js там будет раз в нцать больше, чем с jQuery. А "медленный" jQuery во-первых летает, как реактивный самолет и, во-вторых, позволил слабать ту страничку за полчаса (при том, что я написал свой собственный загрузчик из XML файла со своей структурой)

Ну я бы и на plain я думаю сделал бы такое быстро. Там не никаких хитростей да и контент — контейнер всего один я так понимаю? если не считать табы.
Хотя я поглядел листинг — согласен — читается просто.

I>>просто обычно это начинает быть заметным при разростании проекта, при усложнении страниц на нем. хотя как знать — может быть jQuery, хотя я пытаюсь как можно больше облегчить страницу и js на ней. Да приходится за это расплачиавться необходимым временем. но всеж таки?


M>Да не становится это при разрастании проекта Когда страница — 200 KB, а jQuery — 20 KB или когда скорость отрисовки страницы — 1-5 секунд, а скорость отработки jQuery — 200ms, это просто незаметно. При том, что очень редко функции в js работают настолько долго. Всякие .append, .hide и прочие работают в пределах 20ms.


Просто в страничке обычно много весит графика нежели текст. Вообще на среднем сайте типа портальчика простого странички примерно по 50-70 кб идут -я имею ввиду контент + дизайн + js + css. это из того что я специально глядел — интересно было узнать средний размер.
Re[14]: jQuery – Javascript нового поколения
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.07.07 09:43
Оценка:
Здравствуйте, ionicman, Вы писали:

I>А я объяснял уже ) у меня например XML+XSLT ( на самом деле все равно какой движок лишь бы данные отдельно были ), ну и дизайнерам запрещено трогать id — в том смысле они могут его присвоить просто другому элементу но не изменить — и я еще ни разу не менял программинг изза дизайна. правда :D

а как ты борешься с множествами элементов? id же не могут повторяться.
I>Ну не знаю — тыже не кидаешь? :D На самом деле если человек достаточно знает — он никогда кидать понты не будет
I>- потому что он знает :D
Это наверное поэтому ты с понтов начал?

I>Мне больше всего понравились заявления что пример написан плохо, что нет ООП и массив глобальный — ваще ржал. Пример на то и пример ) Видимо хотелось человеку шоб я ему сделал с fade эффектами, табами, и анимацией сразу :D

Я сразу написал, с какими эффектами хотел пример. Ты вон языком молол-молол, а пример написать так и не сумел. Чтобы хотя бы работал, что уж там про архитектуру-то.

I>Ну не сайта — страничек уж тогда ))

Сайта, сайта. Ты, надеюсь, про 304 Not modified в курсе? т.е. jQuery.js загружается ровно 1 (один) раз для сайта. Все остальные использования берут готовую из кэша. Это в отличие от кода, сгенеренного серверным XSLT, где обработчики привязаны напрямую к каждому тегу. Поэтому и экономия.

I>Ну я бы и на plain я думаю сделал бы такое быстро.

Давай не будем проверять, да? А то опять смешно получится
I>Там не никаких хитростей да и контент — контейнер всего один я так понимаю? если не считать табы.
I>Хотя я поглядел листинг — согласен — читается просто.

I>Просто в страничке обычно много весит графика нежели текст. Вообще на среднем сайте типа портальчика простого странички примерно по 50-70 кб идут -я имею ввиду контент + дизайн + js + css. это из того что я специально глядел — интересно было узнать средний размер.

Вопрос, сколько из этого приезжает из кэша, а сколько — с сервера.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: jQuery – Javascript нового поколения
От: ionicman  
Дата: 27.07.07 10:06
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, ionicman, Вы писали:


I>>А я объяснял уже ) у меня например XML+XSLT ( на самом деле все равно какой движок лишь бы данные отдельно были ), ну и дизайнерам запрещено трогать id — в том смысле они могут его присвоить просто другому элементу но не изменить — и я еще ни разу не менял программинг изза дизайна. правда :D

S>а как ты борешься с множествами элементов? id же не могут повторяться.
А зачем мне с ними бороться? там где надо множество элементов в- ариантов много как их получить.
Если элементов не много — вполне можно обойтись навешиванием чего надо прямо в xslt — это увеличивает размер страницы, по этому надо обходиться экономно, но очень простО.
Во вторых есть функция мною написанная getElementByProp( collection, property, value ) — возвращает коллекцию объектов — collection либо array с коллекцией — тогда ведется поиск в ней, либо DOM элемент — тогда он является "контейнером", property — нужное свойство, value — его значение.

I>>Ну не знаю — тыже не кидаешь? :D На самом деле если человек достаточно знает — он никогда кидать понты не будет

I>>- потому что он знает :D
S>Это наверное поэтому ты с понтов начал?

I>>Мне больше всего понравились заявления что пример написан плохо, что нет ООП и массив глобальный — ваще ржал. Пример на то и пример ) Видимо хотелось человеку шоб я ему сделал с fade эффектами, табами, и анимацией сразу :D

S>Я сразу написал, с какими эффектами хотел пример. Ты вон языком молол-молол, а пример написать так и не сумел. Чтобы хотя бы работал, что уж там про архитектуру-то.
Пример работает. Любое решение не универсально — в данном примере работало все. Его достаточно несложно переделать в то чтобы обходить тот конфликт. Коль о тебе гн Mamut как оп рограммере хорошо отзывался — я думаю тебе не сложно понять как? :D

I>>Ну не сайта — страничек уж тогда ))

S>Сайта, сайта. Ты, надеюсь, про 304 Not modified в курсе? т.е. jQuery.js загружается ровно 1 (один) раз для сайта. Все остальные использования берут готовую из кэша. Это в отличие от кода, сгенеренного серверным XSLT, где обработчики привязаны напрямую к каждому тегу. Поэтому и экономия.

насчет 304 — большинство сайтов на данный момент динамические — и обычно чтобы нормально кэшировался контент — требуется нехилые напряги со стороны программинга ( выделение динамических частей и отдачи на кэш статики ). Так что обычно странички не кэшируются — факт. js скэшируется, согласен — но он требует накладных расходов при запуске — тут есть выбор — либо сделать на сервере — и увеличить таким образом трафик либо же сделать это на клиенте, повысив таким образом тормаза. Выбор всегда :D

I>>Ну я бы и на plain я думаю сделал бы такое быстро.

S>Давай не будем проверять, да? А то опять смешно получится
См выше, бодаться надоело.

I>>Просто в страничке обычно много весит графика нежели текст. Вообще на среднем сайте типа портальчика простого странички примерно по 50-70 кб идут -я имею ввиду контент + дизайн + js + css. это из того что я специально глядел — интересно было узнать средний размер.

S>Вопрос, сколько из этого приезжает из кэша, а сколько — с сервера.
и это тамже ) просто в БОЛЬШИНСТВЕ случаев достаточно стандартного js + шаблонизатор, нежели использовать fw и навешивать ( пусть удобно ) функционал на стороне клиента.

В БОЛЬШИНСТВЕ — это не значит всегда — если проект из себя представляет динамику — например прообраз экселя написан типа google spreadsheet, то там и так все тормозит — пользователь к этому готов, там для удобности, читаемости вполне закономерен fw, jQuery например. Уж больно понравилась мне гладкость кода у ребят :D
Re[16]: jQuery – Javascript нового поколения
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.07.07 10:51
Оценка: +2
Здравствуйте, ionicman, Вы писали:

I>Здравствуйте, Sinclair, Вы писали:

I>А зачем мне с ними бороться? там где надо множество элементов в- ариантов много как их получить.
Вот то-то и оно, что их много. А jQuery инкапсулирует 99% этих вариантов в один простой и компактный синтаксис.
I>Если элементов не много — вполне можно обойтись навешиванием чего надо прямо в xslt — это увеличивает размер страницы, по этому надо обходиться экономно, но очень простО.
Вот именно! Ты же только что тут боролся за производительность? Сильнее всего на производительность влияет вес HTTP Response. Поэтому jQuery реально офигенно ускоряет сайты.

I>Во вторых есть функция мною написанная getElementByProp( collection, property, value ) — возвращает коллекцию объектов — collection либо array с коллекцией — тогда ведется поиск в ней, либо DOM элемент — тогда он является "контейнером", property — нужное свойство, value — его значение.

Это я понял. Ну то есть ты воспроизвел маахонький кусочек jQuery у себя. Мы у себя тоже такие штуки делаем. Мне нравится jQuery именно тем, что он позволяет не изобретать велосипед каждый раз, когда что-то чуть-чуть поменялось. Я уже упоминал про взрыв сложности императивного кода при развитии требований. Mamut пишет о том же.
S>>Я сразу написал, с какими эффектами хотел пример. Ты вон языком молол-молол, а пример написать так и не сумел. Чтобы хотя бы работал, что уж там про архитектуру-то.
I>Пример работает. Любое решение не универсально — в данном примере работало все.
Ну давай не будем упираться? Я тебе привел тест пример, который ломает твой код. Если он был заточен на конкретный набор дивов, то можно было и списком id обойтись.
Вопрос в стоимости поддержки.
I>Его достаточно несложно переделать в то чтобы обходить тот конфликт. Коль о тебе гн Mamut как оп рограммере хорошо отзывался — я думаю тебе не сложно понять как? :D
Да знаю я, как его обойти. В этом как раз и проблема: я вижу, что регекспы получаются нечитаемыми, громоздкими, трудно отлаживаемыми и трудно поддерживаемыми.


I>>>Ну не сайта — страничек уж тогда ))

S>>Сайта, сайта. Ты, надеюсь, про 304 Not modified в курсе? т.е. jQuery.js загружается ровно 1 (один) раз для сайта. Все остальные использования берут готовую из кэша. Это в отличие от кода, сгенеренного серверным XSLT, где обработчики привязаны напрямую к каждому тегу. Поэтому и экономия.

I>насчет 304 — большинство сайтов на данный момент динамические — и обычно чтобы нормально кэшировался контент — требуется нехилые напряги со стороны программинга ( выделение динамических частей и отдачи на кэш статики ).

Гм. jsQuery.js — это статика. Для ее кэщирования делать обычно ничего не надо — любой вменяемый HTTP сервер отдаст 304 сам. Именно потому, что большинство сайтов сейчас динамические, и нельзя пользоваться раздувающими клиентский код методами.
Типичные "фреймворки", которые я вижу, совершенно необоснованно раздувают страницы до мегабайтов.
I>Так что обычно странички не кэшируются — факт. js скэшируется, согласен — но он требует накладных расходов при запуске — тут есть выбор — либо сделать на сервере — и увеличить таким образом трафик либо же сделать это на клиенте, повысив таким образом тормаза.
Несерьезно. Скачать раз в жизни 20kb куда как эффективнее, чем отдавать по 5к лишних на каждый реквест.


I>В БОЛЬШИНСТВЕ — это не значит всегда — если проект из себя представляет динамику — например прообраз экселя написан типа google spreadsheet, то там и так все тормозит — пользователь к этому готов, там для удобности, читаемости вполне закономерен fw, jQuery например. Уж больно понравилась мне гладкость кода у ребят :D

Ну почему обязательно ексель? Я тебе говорю — jQuery реально ускоряет работу, а) потому что позволяет писать меньше jScript кода и б) потому, что позволяет писать меньше разметки для биндинга событий.
Современные сайты чудовищно перегружены всякими onmouseover/onmouseleave, даже в простых случаях, где не нужна мегадинамика в стиле google spreadsheets или google maps.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: jQuery – Javascript нового поколения
От: Mamut Швеция http://dmitriid.com
Дата: 27.07.07 10:58
Оценка:
M>>Задачи быстро перестают быть базовыми. Структура документа может быть изменена радикально (а что, прришел новый дизайнер и все переиграл ). Гораздо легче изначально использовать инструмент, требующий минимум усилий для изменения поведения. Сравним:

I>А я объяснял уже ) у меня например XML+XSLT ( на самом деле все равно какой движок лишь бы данные отдельно были ), ну и дизайнерам запрещено трогать id — в том смысле они могут его присвоить просто другому элементу но не изменить — и я еще ни разу не менял программинг изза дизайна. правда :D


Поверь мне, придется Особенно интересно это выглядит, когда таблица вдруг заменяется табличной версткой. Тогда никакими id не отмашешься

I>На

M>>
M>>if ( /(classname *?= *?ext.*?tagname *?= *?div)|(tagname *?= *?div.*classname *?= *?ext)/i.test( getPrimitive( o ) ) )
M>>


I>это кстати для IE & FF сделано такто она ровно в 2 раза меньше )


Ключевое выделено. В том же jQuery очень много кода по борьбе с браузерами. Мое любимое место в коде вот:
// This may seem like some crazy code, but trust me when I say that this
// is the only cross-browser way to do this. --John
isFunction: function( fn ) {
    return !!fn && typeof fn != "string" && !fn.nodeName && 
        fn.constructor != Array && /function/i.test( fn + "" );
},




Плюс есть много мелких браузерных глюков по типу:
// IE elem.getAttribute passes even for style (getAttribute работает даже для стилей)

// IE actually uses filters for opacity

// IE has trouble with opacity if it does not have layout
// Force it by setting the zoom level

// Note that you can't set the name property of input elements in IE.
// Use $(html) or .append(html) or .html(html) to create elements
// on the fly including the name property.


и так далее. Там такого кода просто тонны. Предположу, что до одной пятой всего кода борется с браузерами. И эта борьба очень нетривиальна

M>>Он имеет право понты кидать, поверь

I>Ну не знаю — тыже не кидаешь? :D На самом деле если человек достаточно знает — он никогда кидать понты не будет
I>- потому что он знает :D

Разные люди по-рузному реагируют

M>>Область применения — везде, где нужна работа с DOM'ом. Единственное, где его не стоит, наверное, применять — там, где суммарный вес сайта меньше, чем библиотека в зазипованном виде


I>Ну не сайта — страничек уж тогда ))


Именно сайта. Вот, пожалуйста: http://www.osxcode.com/feedsearch/
Сраница полностью весит 98КБ, из них 62КБ — это яваскрипт. На plain js это делать? Не, увольте

M>>>>Кстати. О простых страничках. Очень простая страничка. Примеры там тоже тривиальные (видно из кода). Кода на plain js там будет раз в нцать больше, чем с jQuery. А "медленный" jQuery во-первых летает, как реактивный самолет и, во-вторых, позволил слабать ту страничку за полчаса (при том, что я написал свой собственный загрузчик из XML файла со своей структурой)

I>Ну я бы и на plain я думаю сделал бы такое быстро. Там не никаких хитростей да и контент — контейнер всего один я так понимаю? если не считать табы.
I>Хотя я поглядел листинг — согласен — читается просто.

Я имел в виду — сама страничка + примеры. Например, "excel руками" я очень смутно представляю, как делать на plain js

I>Просто в страничке обычно много весит графика нежели текст. Вообще на среднем сайте типа портальчика простого странички примерно по 50-70 кб идут -я имею ввиду контент + дизайн + js + css. это из того что я специально глядел — интересно было узнать средний размер.


Ну вот. 50-70 KB. 1 секунду он отображается, 20-200 миллисекунд отрабатывает, допустим $(document).ready (хотя я в нее стараюсь много функционала не пихать). И все. Ведь дальше jQuery не работает постоянно.


dmitriid.comGitHubLinkedIn
Re[15]: Поправка
От: Mamut Швеция http://dmitriid.com
Дата: 27.07.07 11:04
Оценка:
I>>А я объяснял уже ) у меня например XML+XSLT ( на самом деле все равно какой движок лишь бы данные отдельно были ), ну и дизайнерам запрещено трогать id — в том смысле они могут его присвоить просто другому элементу но не изменить — и я еще ни разу не менял программинг изза дизайна. правда :D

M>Поверь мне, придется Особенно интересно это выглядит, когда таблица вдруг заменяется табличной версткой. Тогда никакими id не отмашешься


Выделенное читать как: когда таблица вдруг заменяется версткой на div'ах


dmitriid.comGitHubLinkedIn
Re[17]: jQuery – Javascript нового поколения
От: ionicman  
Дата: 27.07.07 11:08
Оценка:
Насчет большинства fw согласен полностью. Один Zend чего стоит только чтобы в нем разобраться :D

насчет jQuery, че хочу сделать — писал, что очень не нравится порождение объекта на каждую коллекцию — лики будут изза этого даже в ff.

Во вторых по сути требуется лишь функция обеспечивающая беганье по DOM дереву — ВСЕ ОСТАЛЬНОЕ НАДО ПОДКЛЮЧАТЬ когда надо. Смысл мне в анимации если я ее не юзаю на странице. Идеально было бы некое подобие вот такого
$("здесь посиковый запрос").search("тожесамое применимо к коллекции").parent.next.prev.prevSearch.do(функция)
do — просто применение данной функции к одному элементу коллекции последовательно

Все! все остальное в отдельных js, и если надо — прикомпиливай, если не надо — не прикомпиливай.

собсвтенно у меня на данный момент к каждой странице приделывается js со следующим функционалом:

найтиDOMэлемент
создатьDOMэлемент
следующийDOMэлемент
предыдущийDOMэлемент
очиститьВнутриDOMэлемент
удалитьПереместитьDOMэлемент

это зависит от проекта но в моих часто попадается — поэтому сюдаже вынесено
получитьТекущуюДату
сформатироватьЧисловуюСтроку

Остальное Ajax / Sjax / Анимация / Контролы и др — отдельно. Они расширяют просто при подключении базовый функционал.
Причем могут и перегрыжать существующие функции

Т.е. на самом деле вся мощь jQuery это всего лишь ее поиск — этим она и удобна. Почему все остальное не вынесли на правах плагинов я не знаю. Может быть оттого что мало с ней работал :D Но то, что ОЧЕНЬ часто встречается я нарисовал. остальное должны быть опции.

Что на это думаете?
Re[15]: jQuery – Javascript нового поколения
От: ionicman  
Дата: 27.07.07 11:18
Оценка:
M>Поверь мне, придется Особенно интересно это выглядит, когда таблица вдруг заменяется табличной версткой. Тогда никакими id не отмашешься
Ну я смутно вижу, чтобы чтото должно сильно поменяться при изменении типа верстки — если мы не берем в расчет контролы, то обычно что есть верстка для сайта — это некая разметка на области, в которые выплевывается контент, так?
Если данной области присвоен id="c1" например, то нет никакой разницы <td id="c1">...</td> либо же <div id="c1">...</div> я имею ввиду с программной точки зрения. По этому и не понимаю какие трудности. Конечно, если учавствуют в программе tagName тогда да, но зачем? таким образом ты привязываешь работу программы к каркасу дизайна. не есть хорошо. Тут мне кажется лучше уж везде числовые id повтыкать, чем так. По этому я и говорил что jQ хороша для контролов, нежели для просто страничек.

M>Ключевое выделено. В том же jQuery очень много кода по борьбе с браузерами. Мое любимое место в коде вот:

Так я этим имел ввиду сравнить этот кусочек с синтаксисом jQ — мы же про него а не про его листинг )
M>
M>// This may seem like some crazy code, but trust me when I say that this
M>// is the only cross-browser way to do this. --John
M>isFunction: function( fn ) {
M>    return !!fn && typeof fn != "string" && !fn.nodeName && 
M>        fn.constructor != Array && /function/i.test( fn + "" );
M>},
M>

Ага — весело :D

M>Разные люди по-рузному реагируют

Согласен.

Кстати а почему на RSDN нельзя сообщение отредактировать? или я плохо искал?
Re[18]: jQuery – Javascript нового поколения
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.07.07 11:26
Оценка:
Здравствуйте, ionicman, Вы писали:

I>Насчет большинства fw согласен полностью. Один Zend чего стоит только чтобы в нем разобраться :D


I>насчет jQuery, че хочу сделать — писал, что очень не нравится порождение объекта на каждую коллекцию — лики будут изза этого даже в ff.

Черт его знает насчет ликов. Стоит, наверное, тест написать.
Собственно самих утечек там точно не будет. А вот потребление памяти может быть...

I>Во вторых по сути требуется лишь функция обеспечивающая беганье по DOM дереву — ВСЕ ОСТАЛЬНОЕ НАДО ПОДКЛЮЧАТЬ когда надо. Смысл мне в анимации если я ее не юзаю на странице. Идеально было бы некое подобие вот такого

I>$("здесь посиковый запрос").search("тожесамое применимо к коллекции").parent.next.prev.prevSearch.do(функция)
Хм. А разве там не так работает???
I>Все! все остальное в отдельных js, и если надо — прикомпиливай, если не надо — не прикомпиливай.
Знаешь, при 20k .js это, наверное, не очень актуально. Грубо говоря, файл приезжает в одном IP пакете
Вот если jQuery вырастет раз в десяток, тогда будет иметь смысл ее попилить.
А так — подход к распиливанию приведет только к удорожанию рендера страницы, потому что за каждым из N кусков jQuery придется бегать на сервер за 304.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: jQuery – Javascript нового поколения
От: Mamut Швеция http://dmitriid.com
Дата: 27.07.07 12:16
Оценка:
M>>Поверь мне, придется Особенно интересно это выглядит, когда таблица вдруг заменяется табличной версткой. Тогда никакими id не отмашешься
I>Ну я смутно вижу, чтобы чтото должно сильно поменяться при изменении типа верстки — если мы не берем в расчет контролы, то обычно что есть верстка для сайта — это некая разметка на области, в которые выплевывается контент, так?
I>Если данной области присвоен id="c1" например, то нет никакой разницы <td id="c1">...</td> либо же <div id="c1">...</div> я имею ввиду с программной точки зрения. По этому и не понимаю какие трудности. Конечно, если учавствуют в программе tagName тогда да, но зачем? таким образом ты привязываешь работу программы к каркасу дизайна. не есть хорошо. Тут мне кажется лучше уж везде числовые id повтыкать, чем так. По этому я и говорил что jQ хороша для контролов, нежели для просто страничек.

Пример. Из нашего шоппинг карта:
<table id="checkout_grid">
    <tr>
        <td>
            <input type="checkbox" id="#ID#" value="#ID#" />
        </td>
        <td> ... описание и еще много td - с ценой и т.п.</td>
    </tr>
    <!--- еще много таких tr - по одному на каждый предмет --->
</table>
<input type="button" id="step2" value="Step 2 >>" style="display: none" />


// все равно, что body.onload, но круче.
// срабатывает, когда DOM уже готов, но прорисовка
// не обязательно завершилась
$document.ready(
    function() {
        // находим все checkbox'ы в checkout_grid
        // и присваиваем им onclick

        $("#checkout_grid input:checkbox").click(
        function() {
            // инициализируем счетчик
            var c = 0;

            // смотрим, сколько у нас отмеченных чекбоксов
            $("#checkout_grid input:checkbox").each(
                function(){
                    if(this.checked) c++;
                }
            )

            // если отмеченных чекбоксов нет, прячем кнопку "Step 2 >>"
            if(c > 0)
                $("#step2").show();
            else
                $("#step2").hide();
        }
    );
    }
);


Если вдруг таблицу заменят на div или на div без id, изменить код не составит труда. Сможет ли с этим справиться предложенный getProp или регэксп — не знаю. Я даже не представляю, как на них написать аналог $("#checkout_grid input:checkbox")




I>Кстати а почему на RSDN нельзя сообщение отредактировать? или я плохо искал?


Особенности движка. Много раз обсуждалось в "обсуждении сайта", но общее решение было, что такая фича скорее не нужна, чем нужна


dmitriid.comGitHubLinkedIn
Re[17]: jQuery – Javascript нового поколения
От: ionicman  
Дата: 30.07.07 03:00
Оценка:
M>Пример. Из нашего шоппинг карта:
M>
M><table id="checkout_grid">
M>    <tr>
M>        <td>
M>            <input type="checkbox" id="#ID#" value="#ID#" />
M>        </td>
M>        <td> ... описание и еще много td - с ценой и т.п.</td>
M>    </tr>
M>    <!--- еще много таких tr - по одному на каждый предмет --->
M></table>
M><input type="button" id="step2" value="Step 2 >>" style="display: none" />
M>


M>Если вдруг таблицу заменят на div или на div без id, изменить код не составит труда.

Я выделил ключевой момент выше, если его заменят на div, но оставят ID ( а не оставить его нельзя — ибо это уже не разметка а часть логики ) — то на самом деле ничего не поменятся, так ведь? Ведь нет ни какой разницы что за элементь если его находят по ID, а потом внутри его ищут определенные элементы.

M>Сможет ли с этим справиться предложенный getProp или регэксп — не знаю. Я даже не представляю, как на них написать аналог $("#checkout_grid input:checkbox")


Ну на самом деле не сложно:
GetProp( document.getElementByID("checkout_grid"),["tagName", "type"],["input", "checkbox"] );

M>Особенности движка. Много раз обсуждалось в "обсуждении сайта", но общее решение было, что такая фича скорее не нужна, чем нужна


:D Ну как сказать, мне очень не хватает — бывает гдето чуть ошибешься, или забудешь чтонидь добавить. Да, я конечно знаю, что можно добьавить все это новыми сообщениями, но как то не удобно, хотя не смертельно есессно :D
Re[19]: jQuery – Javascript нового поколения
От: ionicman  
Дата: 30.07.07 03:16
Оценка:
I>>насчет jQuery, че хочу сделать — писал, что очень не нравится порождение объекта на каждую коллекцию — лики будут изза этого даже в ff.
S>Черт его знает насчет ликов. Стоит, наверное, тест написать.
S>Собственно самих утечек там точно не будет. А вот потребление памяти может быть...
Так в том то и дело, что я не встречал грамотной реализайии trash garbager ни в IE ни в FF ( оперу и сафари не мучал ),
растет к сожелению память и очень сильно, причем по тому что я тестил получается так — очень мало увеличивается память при создании например обычных массивов — ну типа var a=[], самое что интересное {"abc":"1", "abcd":"2"} гораздо существеннее влияет на память нежели a=[]; a["abc"]=1; a["abcd"]=2. Не знаю почему :/ В принципе и то, и то — есть объект... Я на динамических контролах проверял. Тест очень простой был — там дерево было — при раскрытии ветки контрол динамически достраивался — как его DOM часть, так и объектная структура. Ну вот так побегав и пораскрывав ветки ( до 400-500 айтемов в одной ветке было сделано специально ) IE разарастался метров до 25-37! Потом в какойто момент он переставал отображать картинки, а затем переставал ворочатся JS. FF по другому ведет себя — разрастается до примерно 60 метров, но работает

I>>Во вторых по сути требуется лишь функция обеспечивающая беганье по DOM дереву — ВСЕ ОСТАЛЬНОЕ НАДО ПОДКЛЮЧАТЬ когда надо. Смысл мне в анимации если я ее не юзаю на странице. Идеально было бы некое подобие вот такого

I>>$("здесь посиковый запрос").search("тожесамое применимо к коллекции").parent.next.prev.prevSearch.do(функция)
S>Хм. А разве там не так работает???
I>>Все! все остальное в отдельных js, и если надо — прикомпиливай, если не надо — не прикомпиливай.
S>Знаешь, при 20k .js это, наверное, не очень актуально. Грубо говоря, файл приезжает в одном IP пакете
S>Вот если jQuery вырастет раз в десяток, тогда будет иметь смысл ее попилить.
S>А так — подход к распиливанию приведет только к удорожанию рендера страницы, потому что за каждым из N кусков jQuery придется бегать на сервер за 304.
Ну теоритичекси можно побить на функцилональные куски — их будет 2-3 штуки. Я обычно бью так: сервисные фии ( определение размеров элементов, их создание, некие манипуляции со стандартными типами ) — это мой оверлей — т.е. примитивы которые потом используют все остальные функции — грузится он почти всегда на странички, украшательства ( анимация, фильтры и т.д. ) и доп. функционал ( обычно различные контролы — например календарь, если страница того требует ).

Да, согласен, бегать будет чуть чаще, но по моему модульность добавляет удобства? Хотя конечно согласен, 20к не сильно напрчгает, но может есть смысл реализовать лучшую поддержку XPath в теже 20 кб, а остальное выкинуть?
Я погляждел листинг — достаточно сложно там завязаны внутренние функции и не так просто выдернуть будет поиск — там просто сложно читать — т.к. оптимизированно очень сильно — ну зато можно поучится интересным приемам

Хотя даже не знаю, может эти ребята сделают потом отдельно реализацию XPath? Было бы классно, потому как единственную полную реализацию XPath 1.0 я уже приводил 100k

Почему охота XPath — ну она более функциональна нежели CSS селекторы, хотя вот г-н Mamut говорит, что в основном пользуется именно CSS селекторами. Мне, может быть, XPath ближе так как большинство страниц на XSLT написано просто. В принципе очень функциональная штука.
Re[20]: jQuery – Javascript нового поколения
От: Sinclair Россия https://github.com/evilguest/
Дата: 30.07.07 03:34
Оценка:
Здравствуйте, ionicman, Вы писали:
I>Так в том то и дело, что я не встречал грамотной реализайии trash garbager ни в IE ни в FF ( оперу и сафари не мучал ),
I>растет к сожелению память и очень сильно, причем по тому что я тестил получается так — очень мало увеличивается память при создании например обычных массивов — ну типа var a=[], самое что интересное {"abc":"1", "abcd":"2"} гораздо существеннее влияет на память нежели a=[]; a["abc"]=1; a["abcd"]=2. Не знаю почему :/ В принципе и то, и то — есть объект... Я на динамических контролах проверял. Тест очень простой был — там дерево было — при раскрытии ветки контрол динамически достраивался — как его DOM часть, так и объектная структура. Ну вот так побегав и пораскрывав ветки ( до 400-500 айтемов в одной ветке было сделано специально ) IE разарастался метров до 25-37! Потом в какойто момент он переставал отображать картинки, а затем переставал ворочатся JS. FF по другому ведет себя — разрастается до примерно 60 метров, но работает
А у тебя случайно не было ссылок на DOM изнутри JS объектов?

I>Да, согласен, бегать будет чуть чаще, но по моему модульность добавляет удобства?

Удобство должно быть измеримым. Сама по себе модульность ничего не значит. Слепое следование абстрактным ценностям прививают низкооплачиваемым кодерам, поскольку считается, что они не в состоянии самостоятельно ориентироваться в окружающем мире. Так и здесь — какой бенефит даст тебе возможность не включать, к примеру, анимацию? Кроме download size?
Тем более, что сам download size — тоже упрощенное правило. На самом деле пользователя интересует скорость подгрузки страницы, а на нее влияет далеко не только download size.

В других случаях модульность может действительно добавить удобства — там, к примеру, где модули могут быть взаимозаменяемыми. Но что-то я не вижу никакой взаимозаменяемости в jQuery.

I>Хотя конечно согласен, 20к не сильно напрчгает, но может есть смысл реализовать лучшую поддержку XPath в теже 20 кб, а остальное выкинуть?

А, собственно, зачем? У тебя есть какие-то реальные задачи, требующие неподдерживаемого в jQuery XPath? Или ты просто заранее боишься, что однажды такая задача возникнет, а отказаться от jQuery будет уже поздно?

I>Я погляждел листинг — достаточно сложно там завязаны внутренние функции и не так просто выдернуть будет поиск — там просто сложно читать — т.к. оптимизированно очень сильно — ну зато можно поучится интересным приемам


I>Хотя даже не знаю, может эти ребята сделают потом отдельно реализацию XPath? Было бы классно, потому как единственную полную реализацию XPath 1.0 я уже приводил 100k

Ну, я так думаю, что пусть цветут все цветы. Вот у тебя есть полная реализация XPath. Если она тебе часто нужна, то никакой проблемы один раз ее отдать пользователю нету. Достаточно озаботиться грамотным кэшированием, и никто ничего не заметит.

I>Почему охота XPath — ну она более функциональна нежели CSS селекторы, хотя вот г-н Mamut говорит, что в основном пользуется именно CSS селекторами. Мне, может быть, XPath ближе так как большинство страниц на XSLT написано просто.

Я считаю CSS селекторы очень важными, и вот почему: сейчас CSS по факту используется гораздо чаще, чем XSLT. Поэтому как правило HTML уже верстается так, чтобы можно было применять CSS правила. Так что шанс на то, что нужные тебе элементы уже проидентифицированы каким-то CSS правилом, достаточно велик. И тебе не нужно переводить "#cart-content > td.amount" в XPath, можно просто его скопировать.

I>В принципе очень функциональная штука.

Угу. Я вообще всё больше начинаю верить в декларативные языки запросов.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.