кстати, я так понимаю все выборки осуществляются перебором?
тогда вот ещё одна ссылка в тему: http://javascript.ru/blog/tenshi/yavascriptovoe-dao реализация ужасная, но идеи стоит взять на заметку |
Цитата:
UPD: почитал по ссылке, у меня всё также, кроме отсутствия ключей объектов (я такие объекты называю "гибридными" за то, что они содержат сильные стороны массивов и хешей), но их реализацию я уже давно задумал добавить в версию 4 своей либы, вместе с поддержкой воркеров. Ты бы почитал мануал на моем сайте, чтобы лучше понять, что же я сделал :) И я совсем не против объективных и трезвых советов. |
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
|
> у меня всё также
как же создаются ключи? > Речь не о трансформации, а о фильтрации и группировке. одним словом это - выборка данных > Я знаю инструмент, который позволяет эффективно выполнить оба процесса в условиях большого высоконагруженного проекта. что же это за волшебное средство? > Модель всё равно вернёт data-ориентированные данные модель представления вернёт вью ориентированные данные. это яваскрипт, используй > "У меня" будет один шаблон, один запрос и две фильтрации. Болтовня ничего не стоит. Покажите мне код. — Linus Torvalds. |
Цитата:
И не забывай, что мой фреймворк можно юзать, как простой фреймворк данных (новые методы работы с массивами и объектами) или абстрактно представлять как некоторую БД, как удобнее и лучше должен решать сам разработчик. // Все чётные элементы увеличить на 1 (вместо строковых сокращений функций моно юзать простые функции) $C([1,2,3,4,5,6,7]).forEach(':data[i]++', ':el % 2 == 0'); Сейчас есть проблемы при тупом переборе более 10к элементов за раз, но после внедрения воркеров я думаю проблема исчезнет (в рамках клиентских задача вряд ли будут коллекции по 10кк элементов). |
Цитата:
Цитата:
Цитата:
<?xml version="1.0" encoding="UTF-8"?> <ten:root xmlns:ten="TEN" xmlns="http://www.w3.org/1999/xhtml"> <!-- Один шаблон для списка пользователей, может лежать в отдельном файле --> <ten:block name="user-list"> <ul> <ten:each array="this" item="user"> <li><ten:echo data="user.name" /></li> </ten:each> </ul> </ten:block> <!-- Одна выборка всех пользователей. Если бы нам потребовались только совершеннолетние, в методе getUsers можно реализовать параметры fromAge и toAge. Пример приводить не буду --> <ten:async method="getUsers" arguments="userList"> <ten:context object="new Collection(userList)"> <!-- Первый список, первая фильтрация --> <ten:render block="user-list" context="this.get(':el.age < 18')" /> <!-- Второй список, вторая фильтрация --> <ten:render block="user-list" context="this.get(':el.age >= 18')" /> </ten:context> </ten:async> </ten:root> Ну и сама разметка списка может быть кастомизирована для каждого конкретного случая. В итоге: Цитата:
Такой подход используется и в XSL. |
> АПИ для этого есть
где про него почитать? > $C([1,2,3,4,5,6,7]).forEach(':data[i]++', ':el % 2 == 0'); не убедительно [1,2,3,4,5,6,7].map(fucntion( val ){ return ( el % 2 ) ? el : el + 1 }) > после внедрения воркеров я думаю проблема исчезнет и куда же она денется? вместо использования ключей для быстрой выборки, ты выносишь перебор в асинхронную задачу, превращая клиентский код в лапшу из колбэков. |
Цитата:
Цитата:
Цитата:
Я не навязываю стратегию решения задачи, разработчик сам решает что и как ему сделать. Тебе не нравится моя либа, т.к. ты писал свой велосипед, который никому кроме тебя не нужен, более того судя по кол-ву комментов люди даже не поняли, что ты хотел написать, у тебя нет ни доки ни мана, даже ссылка битая, о чём тут ещё говорить? |
> Ты не поверишь, XSLT.
ты прав, не поверю. открой для себя хотябы двухпроходной xslt - это классно. на первом проходе делаем reduce данных от серверов, формируя модель представления. на втором - накладываем вёрстку. в качестве бонуса - возможность в любой момент посмотреть какая формируется модель - для дебага куда полезней, чем копаться в мешанине html-тегов. > Привет, копипаста моделей. она в любом случае будет. вопрос лишь в том, вносить ли в эту копипасту ещё и шаблоны или нет. к тому же не забывай про агрегацию и наследование, которые в js-моделях использовать куда проще, чем в шаблонах. |
> Один шаблон для списка пользователей, может лежать в отдельном файле
замечательно, тут ты рендеришь модель отображения > Одна выборка всех пользователей. Если бы нам потребовались только совершеннолетние, в методе getUsers можно реализовать параметры fromAge и toAge. Пример приводить не буду а тут формируешь две модели и рендеришь их. то же самое на js могло бы выглядеть проще: var AllUsersModel= Model( function ( userList ){ var model= { mature: [], amature= [] } userList.forEach( function( user ){ model[ ( user.age >= 18 ) ? 'mature' : 'amature' ].push( user ) } return model } ) AllUsersModel( userList ).renderTo( place ) |
> Одна выборка всех пользователей.
а потом из выберки всех пользователей ты делаешь 2 выборки - тех кто старше и тех кто младше, вместо группировки как у меня. в зависимости от условий фильтрации и числа элементов это может дать лишние накладные расходы. и вообще ты тут изобрёл хмл-велосипед - на яваскрипте этот код выглядит куда лаконичней: this.renderUsers= function( userlist ){ var users= new Collection(userList) this.renderUserList( user.get(':el.age >= 18') ) this.renderUserList( user.get(':el.age < 18') ) } |
Цитата:
Цитата:
Ты, случайно, не из команды лего? Они как раз любят так делать. |
> На сайте в учебнике
конкретной ссылки я так и не дождусь? скажи ещё "всё есть в интернете" > например, начиная с конца массива, отбросив первые 10 успешных итераций и если итерация меньше 20-ти применить сортировку по фильтру и возвести в n степень как это будет выглядеть с использованием сабжа? > Проблема больших данных - это проблема архитектуры приложения, а не моей библиотеки ок, так бы и написал, что для больших данных она не предназначена. вопросов больше нет. |
Цитата:
И если оно проще выглядит - это не значит, что проще разрабатывается и поддерживается. Цитата:
Цитата:
|
Цитата:
http://www.collection-js.com/manual/part-5.html Цитата:
Цитата:
|
> Где в моем примере копипаста?
там где ты делаешь запросы и рендеришь шаблоны. за показа "всех пользователей сообщества такого-то" тебе и мне придётся этот блок копипастить и допиливать > А с чего ты взял, что я с этим не знаком? потому что говоришь, что > Это отстой. > Ты, случайно, не из команды лего? Они как раз любят так делать. нет, но я рад, что они таки решились отделить мух от котлет. вот поговори с ними, почему они решили воспользоваться двумя проходами. к слову, я сейчас не использую 2 прохода, ибо браузеры не поддерживают exslt, и очень от этого страдаю. приходится извращаться с mode( |
Цитата:
|
> У тебя получается 2 цикла (внутри renderUserList) + forEach, а у меня всего 2 цикла.
выборка в Collection как мы выяснили происходит без ключей, а значит будет перебор всего массива в цикле > И если оно проще выглядит - это не значит, что проще разрабатывается и поддерживается. полноценный язык программирования всяко проще разрабатывается и поддерживается, чем сильно ограниченный xml велосипед. > Т.е. ты собираешься описывать структуру страницы в программном коде, а не в шаблоне? Тебе не кажется, что это тупиковый путь? а это не важно где, хоть в xml конфиге, хоть в json, главное - не мешать её с шаблонами. |
> Если Collection позволяет так группировать - будет "как у тебя".
пример кода? |
Цитата:
// Сгруппировать по отношению старше/младше // и выбрать по ключу group(':el.age > 18').get('true') Цитата:
|
> http://www.collection-js.com/manual/part-3.html
> http://www.collection-js.com/manual/part-5.html я не увидел там ничего про ключи. можешь привести пример, как выбрать всех юзеров старше 18 лет за O(log n)? >> как это будет выглядеть с использованием сабжа? > http://www.collection-js.com/manual/part-2.html приведи код, а не ссылку |
Цитата:
|
> // Сгруппировать по отношению старше/младше
> // и выбрать по ключу > group(':el.age > 18').get('true') я просил код шаблона. пофиг как делать группировку. |
> get(название ключа)
как создать ключ? |
Цитата:
|
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
|
> Как хочешь, статически (например ручками указав хеш) или динамически (например через группировку).
зайдём с другого конца.. var c= new Collection([ /* over 9000 */ ]) ... c.add({ name: 'bob', age: 18 }) ... var mature= c.get( ':el.age >= 18' ) что нужно приписать сюда, чтобы выборка в конце происходила за O( log n ) |
> Видимо, ты не в курсе про layout-ы.
рассказывай > Действительно, зачем нужны шаблонизаторы, давайте генерировать разметку программным кодом. чтобы подставлять значения в шаблоны, очевидно. программно это делать не удобно в ввиду отсутствия нативной поддержки целевого языка, и как следствие необходимости собирать из строк и правильно экранировать подставляемые значения. точно также на xslt не удобно формировать json. > Это голословно. рискнёшь доказать полноту по тьюрингу? > а вот программный код - это уже попахивает диагнозом "говнокодер" с каких пор програмный код не годится для описания моделей данных? ты так и не ответил на вопрос: >> Если Collection позволяет так группировать - будет "как у тебя". > пример кода? |
Цитата:
Из мана на сайте либы: // Создадим коллекцию, каталог музыкальных иснтрументов: // первичный уровень таблицы будет хеш-таблицей, где ключ — тип инструмента var db = new Collection({ guitar: { fender: [ {model: 'JAGUAR BLACKTOP HH RW BLK', price: 27921}, {model: 'STRATOCASTER BLACKTOP HH MN BLK', price: 28390}, {model: 'STANDARD TELECASTER ', price: 18518} ], gibson: [ {model: 'CUSTOM SHOP LES PAUL CUSTOM EB/GH', price: 159505}, {model: 'LES PAUL STUDIO FIREBURST CHROME HARDWARE', price: 50525} ] }, bassGuitar: { fender: [ {model: 'STANDARD JAZZ BASS RW Sunburst', price: 32205}, {model: 'STANDARD PRECISION BASS', price: 30640} ] } }); // Теперь выберем все гитары фирмы fender // для этого сделаем прямой запрос через get db.get('guitar > fender'); // Выберем модели, дешевле 20-ти тысяч db.get(':el.price < 20000'); // Ошибка, свойство price не найдено, // Т.к. отсчёт идёт с самого первого объекта, а не с guitar > fender // Чтобы установить нужную точку отсчёта, установим активный контекст db.newContext('guitar > fender'); // Теперь снова сделаем get запрос db.get(':el.price < 20000'); // Всё ок, т.к. теперь задан нужный контекст обхода // В случае задания в get прямой ссылки, она также будет теперь отталкиваться от активного контекста db.get('guitar > fender > 0'); // Ошибка db.get('0'); // Вернёт запрашиваемый элемент А теперь скажи, раз у тебя такая упер-пупер либа, как ты сделаешь выбор типа LIKE по произвольному полю без переборов? PS: А вообще я устал с тобой спорить, я знаю такой тип людей, вроде тебя, и знаю что это глупое занятие. Общайся сам с собой, а я буду общаться с адекватными людьми. |
> Укажи в конструктор не массив, а хеш, где ключи являются возрастом и будет тебе счастье.
не будет. в качестве домашнего задания предлагаю разобраться почему. а вот задание на две пятёрки: var c= new Collection([ /* over 9000 */ ]) ... c.add({ name: 'bob', age: 18 }) ... var mature= c.get( ':el.age >= 18' ) var rich= c.get( ':el.salary >= 9000' ) условия те же - O( log n ) > как ты сделаешь выбор типа LIKE по произвольному полю без переборов? поисковые системы же это как-то делают |
Цитата:
2) вопрос не про поисковые системы, а про твою мистическую супер-упер либу, поэтому опять ты слился. |
Цитата:
Цитата:
Цитата:
|
Цитата:
// Вызываем метод group, и параметром указываем условие, в итоге создастся новая коллекция с ключами true и false, которые будут содержать результат группировки .group(':el.age > 18') // Старше 18 .get('true') // Младше .get('false') // Можно делать ключи по более сложным условиям, // т.к. ключи создаются по возвращаемому параметру условия, // то можно создать множество ключей, например, с помощью тернарного оператора // (разумеется можно писать простые функции или юзать разбиение на атомарные через стек) .group(':el.age > 18 ? more18 : el.age < 12 ? less12 : less18') |
Проводил замеры создания инстанса, 1 миллион итераций.
Вышло примерно так: 1) ИЕ 10 ~ 15 сек 2) FF 16 ~ 20 сек 3) Chrome 22 ~ 24 сек 4) Opera 12 ~ 50 сек Начал оптимизировать логику конструктора: 1) Разложил if-ы по логической вложенности; 2) Заменил первичное копирование свойств с extend (рекурсивная реализация) на Object.create (с указанием прототипа, там где нет, написал свою реализацию). Итого: 1) Opera 12 ~ 0.4 сек 2) Chrome 22 ~ 0.8 сек 3) IE 10 ~ 1 сек 4) FF 16 ~ 1.4 сек Для теста на сафари 6 лень было мак брать (тем более его юзала мама:) ). Основные тормоза разумеется вызывала рекурсия. PS: после оптимизации логика конструктора осталась идентичной. |
Цитата:
Цитата:
|
Цитата:
Цитата:
|
Цитата:
Вывод: объекты, созданные в конструкторах, всегда должны иметь одинаковый набор свойств и не менять этот набор в течении жизни программы. Производительность увеличивается на порядки. А если сделать вывод более общим - писать код нужно так, как если вы бы писали его на C++ или Java, касаемо объектов и их конструкторов. |
Цитата:
|
Цитата:
Мое имхо такое: библиотеки должны в первую очередь обеспечивать высокую производительность в ущерб читабельности. Яркий тому пример - jQuery. |
> .groupLinks(параметр, сохраняем индексы).get(делаем запрос по вторичным индексам).
это псевдокод. что конкретно туда писать? в любом случае, похоже выборка будет O(n) > у тебя же это судя по всему делается сразу в конструкторе вызывая дополнительную не нужную нагрузку (и тормоза) зато при выборке не надо будет создавать индекс с нуля после каждого изменения состава коллекции, вызывая тем самым ещё большие тормоза. > вопрос не про поисковые системы, а про твою мистическую супер-упер либу она не супер и уж тем более не мистическая. она создаёт и поддерживает индексы, а также с их помощью поддерживается консистентность данных. > Гугли. что именно? > Тебе нет. почему? |
Часовой пояс GMT +3, время: 06:46. |