кстати, я так понимаю все выборки осуществляются перебором?
тогда вот ещё одна ссылка в тему: 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, время: 11:15. |