Collection – фреймворк для управления данными

[kobezzza]

kobezzza

слушай а где документация по событиям ?
решил потыкать и упёрся в отсутствие инфы по событиям
Вроде как есть в исходниках, но негде не описано.

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


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

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

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

[B~Vladi]

а его можно глянуть?

Кого?

ну для сферической задачи в вакууме бывает

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

Интересно было бы взглянуть и пощупать

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

[kobezzza]

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

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

[B~Vladi]

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

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

Данные, скармливаемые в шаблон при рендеринге, могут быть либо 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, но намного мощнее.

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

Что думаешь?

[kobezzza]

Что думаешь?

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

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

[B~Vladi]

ты юзаешь Collection внутри шаблона для выборок

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

[DjDiablo]

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е СООБЩЕНИЕ )))

[kobezzza]

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

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

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

Поздравляю

[tenshi]

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

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

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

не угадал

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

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

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

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

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

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

[tenshi]

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

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

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