1) http://www.collection-js.com/manual/part-9.html - предпоследний параграф. Свойство принимает те же параметры, что и вызвавший его метод, return false отменяет действие. Да можно повесить только одно событие, но это легко исправить добавив реализацию обсёрвера, могу добавить из коробки если нужно.

2) Список транзакций? Я просто не успел это добавить, будет в версии 3.8.5 на этой недели уже наверно)

Кого?

Я имел ввиду конкретные, а не вакуумные.

Ну пощупать пока не удастся, но код накидать могу, что бы было более понятно.

Было бы здорово.

Вообще, идея намного шире. Речь об области применения этой либы. Конкретно - в шаблонизаторах.

Данные, скармливаемые в шаблон при рендеринге, могут быть либо view-ориентированными, либо data-ориентированными.

View-ориентированные сложно подготавливать. На каждый конкретный случай приходится писать много view-логики, которую хочется перенести в шаблон. С такими данными работает dust и ему подобные.

С data-ориентированными данными справится не каждый шаблонизатор, либо придется писать кучу проверок в виде конструкций шаблона. Но такие данные проще подготовить программисту, а уже всякие сортировки/группировки делать в шаблоне. Вот как раз в этом случае Collection.js может сделать эту работу лучше, чем "куча проверок в виде конструкций шаблона".

Есть несколько шаблонизаторов, которые позволяют писать JavaScript-выражения для доступа к данным. Например, для получения массива, что бы затем его скормить циклу. Приведу пример для своего шаблонизатора.

var TEN = require('TEN');
var Collection = require('Collection');

var data = [
	{name: 'Andrey', sex: 'male', age: 22},
	{name: 'Sergey', sex: 'male', age: 24},
	{name: 'Ann', sex: 'female', age: 18},
	{name: 'Kate', sex: 'female', age: 21},
	{name: 'Vera', sex: 'female', age: 15},
	{name: 'John', sex: 'male', age: 28},
	{name: 'Paul', sex: 'male', age: 32}
]; // Тут мы сформировали какие-то данные для шаблона, взял из документации

TEN.render('index.xml', new Collection(data));

Ну а в самом шаблоне используем API Collection:

<?xml version="1.0" encoding="UTF-8"?>
<ten:root xmlns:ten="TEN" xmlns="http://www.w3.org/1999/xhtml">
  <!-- Делаем необходимую выборку, так же взято из доки -->
  <ten:each array="this.sort('age').remove(':el.sex == &quot;female&quot; && el.age < 18')" item="user">
    <!-- Выведутся имена совершеннолетних пользователей, отсортированные по возрасту. -->
    <ten:echo data="user.name" />
  </ten:each>
</ten:root>

По-моему выглядит неплохо, не пришлось писать if-ы внутри цикла. Конечно, фильтрация может быть намного сложнее (как показывает практика работы с XSL), и профита будет больше.

Здесь, по-сути, Collection играет роль фильтра, как в Smarty, но намного мощнее.

Надеюсь, теперь понятно насколько тут важна производительность. Так же не менее важны возможности фильтрации, надеюсь в этом плане всё ок.

Что думаешь?

Идея интересная, ты юзаешь Collection внутри шаблона для выборок, тем самым шаблон получается простым и мощным, но да, нужно очень оптимизировать работу (я углублюсь в этом вопросе).

Я как то от таком подходе даже не думал, и когда реализовал поддержку шаблонов в самом Collection исходил из логики: сначала данные готовятся, потом показываются (т.е. 2 прохода), а тут можно сделать в один.

Тот же принцип реализован в Yate, но со своим блекджеком. Такой инструмент очень полезен в шаблонах.

koobezzzza - нет не транзакциии :)

Я говорю о взаимодействии с сервером.
допустим хотим написать грид с возможностью удаления, редактирывания, и создания записей, все изменения сохраняются по кнопки save.

возьмём 4 типовых операций для взаимодействия, СRUD
create - создание новых записей
read - чтение записей
update- обновление записей
delete - удаление записей.

допустим пользователь понасоздавал, редактирывал и удалял записи
а теперь нажал save

я должен вызвать 3 серверных комманды.
1) выбрать из твоей базы все вновь созданные пользователем записи, эту инфу отправим допусти на www.myapp.ru/test/create.php
2) выбрать из твоей базы все записи которые пользователь редактирывал хоть однажды, и бередать их команде www.myapp.ru/test/update.php. Надеюсь ясно что те которые пользователь нередактирывал передавать нет необходимости
3) выбрать все те записи которые пользователь удалил и передать их на сеbрвер допустим в www.myapp.ru/test/delete.php.

впрочем можно упростить взаимодействие с сервом и свести всё к двум командам load и save
для save придётся отправить файл вида

{
   create:[],//список записей подлежащих созданию
   update:[],//список записей подлежащих обновлению
   delete:[]//список полей подлежащих удалению
}

тоесть в твоей либе должно быть что-то вроде метода getCRUD который вернёт {create:[], update:[], delete:[] }
для простоты примера будем считать что в бд будет что то вроде

[
    {id:1,name:"lala"},
    {id:2,name:"lala"}
]

ЭТО МОЁ 666е СООБЩЕНИЕ )))

DjDiablo ну как вариант можно на каждое действия пользователя слать запрос, но ето не тру:)

Твою идею я понял, действительно нужная штука, так что добавлю.

Поздравляю :)

> твои посты я буду тупо игнорить

слив засчитан

> сразу видно джукверист, ибо только джукверисты пихают в проект десяток и более всяких говноплагинов для джуквери

не угадал

> В зависимости от проектов приходиться делать не только приятные глазу вещи.

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

> если я правильно понял то только один метод можно повесить на onSort, если да то печально

вешаем на onSort какой-нибудь EventRouter и проблема решена)

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

сложный проект + сжатые сроки = максимальное использование готового кода. и так уж получается, что каждая библиотека пытается быть швейцарским ножом. хорошо хоть поиск элементов по css селектору выносят на попечение фреймворков.

B~Vladi, смешивать трансформацию модели (из дата ориентированной во вью ориентированную) и шаблонизацию - плохая идея.
фактически не данные нужно преобразовывать в хтмл, а нужно создать модель представления, которая:
1) выберет из базы то, что ей нужно (это может быть выборка как из Collection, json, xml так и запрос к серверу, если данных дофига)
2) отрендерит себя в json/html/dom или куда там ещё надо

смешивать эти два процесса - это классно лишь на простеньких демо-примерах.

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