кстати, я так понимаю все выборки осуществляются перебором?
тогда вот ещё одна ссылка в тему: http://javascript.ru/blog/tenshi/yavascriptovoe-dao
реализация ужасная, но идеи стоит взять на заметку

О, ты начал говорить по существу. Стратегия поиска данных может быть разной, я специально не делал этого автоматически, чтобы сохранить гибкость: можно делать полные переборы, а можно делать выборки по множеству ссылок, можно переборы в интервалах, можно разводить поиск данных по потокам, можно делать индексы и управлять ими с помощью контекстного API. Для каждого случая нужно самому выбирать стратегию или написать специальный драйвер надстройку, как это делают, например, для монги. Сами циклы я стараюсь максимально оптимизировать, вот сейчас серьёзно думаю о неблокирующих режимах "из коробки", т.е. поддержка воркеров и таймаутов (первые, я думаю дадут серьёзный прирост производительности). Реализация неплохая (но до хорошо, мне пока ещё работать и работать), я сам понимаю, где есть узкие места, думаю над их решениями. Я почитаю твою статью и возможно подчеркну из неё что нить полезное, спасибо за ссылку.

UPD: почитал по ссылке, у меня всё также, кроме отсутствия ключей объектов (я такие объекты называю "гибридными" за то, что они содержат сильные стороны массивов и хешей), но их реализацию я уже давно задумал добавить в версию 4 своей либы, вместе с поддержкой воркеров. Ты бы почитал мануал на моем сайте, чтобы лучше понять, что же я сделал :) И я совсем не против объективных и трезвых советов.

Речь не о трансформации, а о фильтрации и группировке.

Конкретные аргументы/примеры есть? Я знаю инструмент, который позволяет эффективно выполнить оба процесса в условиях большого высоконагруженного проекта. И я каждый день им пользуюсь. Так что твои слова для меня пока только слова.

Модель всё равно вернёт data-ориентированные данные, так что это не выход. А если модель будет ещё и превращать их во view-ориентированные, то:


"У меня" будет один шаблон, один запрос и две фильтрации.

> у меня всё также

как же создаются ключи?

> Речь не о трансформации, а о фильтрации и группировке.

одним словом это - выборка данных

> Я знаю инструмент, который позволяет эффективно выполнить оба процесса в условиях большого высоконагруженного проекта.

что же это за волшебное средство?

> Модель всё равно вернёт data-ориентированные данные

модель представления вернёт вью ориентированные данные. это яваскрипт, используй силу функции, люк, чтобы не было копипасты)

> "У меня" будет один шаблон, один запрос и две фильтрации.

Болтовня ничего не стоит. Покажите мне код. — Linus Torvalds.

Формат данных у меня - произвольный JSON, т.е. сам пользователь выбирает, что ему удобней юзать: массив или хеш, но все методы работают как с тем, и с другим, но ввиду их особенностей в разных ситуациях кто-то работает значительно быстрее (перебор быстрее во много-много раз для массивов, но хеши позволяют делать прямые ссылки). Для ключей у меня реализовано контекстное АПИ, если коротко, то это конкретизация поиска, если с умом юзать этот механизм, то проблем со скоростью в рамках клиентской БД не будет вообще никогда (т.е. автоматически у меня не создаются зависимости и ключи, но АПИ для этого есть, чтобы разработчик сам решил, что и как ему сделать).

И не забывай, что мой фреймворк можно юзать, как простой фреймворк данных (новые методы работы с массивами и объектами) или абстрактно представлять как некоторую БД, как удобнее и лучше должен решать сам разработчик.

// Все чётные элементы увеличить на 1 (вместо строковых сокращений функций моно юзать простые функции)
$C([1,2,3,4,5,6,7]).forEach(':data[i]++', ':el % 2 == 0');

Сейчас есть проблемы при тупом переборе более 10к элементов за раз, но после внедрения воркеров я думаю проблема исчезнет (в рамках клиентских задача вряд ли будут коллекции по 10кк элементов).

Ты не поверишь, XSLT.

Привет, копипаста моделей.

Охх... Ну смотри:

<?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 })

> после внедрения воркеров я думаю проблема исчезнет

и куда же она денется? вместо использования ключей для быстрой выборки, ты выносишь перебор в асинхронную задачу, превращая клиентский код в лапшу из колбэков.

На сайте в учебнике

Я привёл элементарный пример, он где угодно элементарно решается, а вот сложный делать стандартными методами ты запаришься, а у меня всё та же одна строчка (например, начиная с конца массива, отбросив первые 10 успешных итераций и если итерация меньше 20-ти применить сортировку по фильтру и возвести в n степень). Ты придираешься к словам, вместо того, чтобы прочитать учебника и не задавать мне глупых вопросов.

Проблема больших данных - это проблема архитектуры приложения, а не моей библиотеки, я лишь дам возможность её решить.

Я не навязываю стратегию решения задачи, разработчик сам решает что и как ему сделать. Тебе не нравится моя либа, т.к. ты писал свой велосипед, который никому кроме тебя не нужен, более того судя по кол-ву комментов люди даже не поняли, что ты хотел написать, у тебя нет ни доки ни мана, даже ссылка битая, о чём тут ещё говорить?

> Ты не поверишь, 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 )