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

[kobezzza]

хм ... ну, только сам автор кода знает, как его коду лучше жаться

Я могу ужать ещё дето 0.5-1 килобайт, но код поддерживать будет геморней, да и мараться не охота

я его тоже использую. Если можно, расскажете поподробнее о личных допилах ?

Поддержка инклудов в CSS через @import, поддержка инклудов для HTML шаблонов на JS в HTML (шаблон включается в разметку и врапится тегами script), @pref в CSS заменяет свойство, на свойство с вендорными префиксами, @base64-url в CSS идёт по указанному адресу и подставляет DATA:URI, вроде всё

[tenshi]

Опа, ещё один велосипед, но какой-то совсем уж уродский)

информация к размышлению: http://hyoo.ru/?article=%D0%9C%D0%BE...author=Nin+Jin

[tenshi]

господи, и тут sql, сделайте меня развидеть это >_< пожалейте тех, кому придётся с вашим кодом работать...

[kobezzza]

Опа, ещё один велосипед, но какой-то совсем уж уродский)

информация к размышлению: http://gist.vrozetke.com/?article=%D...author=Nin+Jin

Спасибо за ссылку, но не понятно к чему она? Данный тред не про систему сборки, а про фреймворк для работы с данными. А если говорить про сборку файлов в Collection, то там на мой взгляд как раз всё прозрачно: зависимости модулей прописаны в модулях, общая схема сборки прописана в core.js, а чтобы редактировать сборку не нужно даже ничего менять, достаточно лишь запустить сборку build.js и указать нужные флаги сборки.

господи, и тут sql, сделайте меня развидеть это >_< пожалейте тех, кому придётся с вашим кодом работать...

Не нравится - не юзай. SQL нужен чтобы повысить уровень абстракции и человеку было проще войти в контекст, к тому же сложный запрос выглядит гораздо более читабельней в SQL, нежели в кучи колбеков или объектов, однако разумеется в первую очередь у меня сделано простое АПИ на колбеках, а SQL я добавил только сейчас, как сахар.

ЗЫ: не пиши плз в этой теме ничего не по делу, уже одну тему засрали в оффтопе.

[B~Vladi]

kobezzza,
судя по этой строке кода и реализации Collection.extend, конструктор Collection в разных ситуациях может возвращать экземпляры с разными наборами свойств. Если это так, то это не круто - GCC будет использовать разные скрытые классы для созданных экземпляров. Может стоит причесать? Особенно актуально для Node.js.

ЗЫ: после статьи на хабре и доклада на конференции стал больше обращать внимание на такие вещи...

[kobezzza]

kobezzza,
судя по этой строке кода и реализации Collection.extend, конструктор Collection в разных ситуациях может возвращать экземпляры с разными наборами свойств. Если это так, то это не круто - GCC будет использовать разные скрытые классы для созданных экземпляров. Может стоит причесать? Особенно актуально для Node.js.

Ну да, вторым параметром конструктора может быть объект, который миксится со свойствами по умолчанию, с замечанием согласен, но в данном случае это скорее нормально, чем нет, т.к. свойства микса являются публичными и специально помечены мною, как не сжимаемые.
Данная фича нужна, т.к. момент инициализации скрипта Collection (т.е. выполняется один раз при инициализации <script>) сам генерит себе множество стандартных методов по формуле (что даёт реальный профит при сжатии, но к слову, я сравнивал с GCC при статичном сжатии и мой вариант оказался лучше). Хотя на самом деле, я давно подумаю о выпиливании второго параметра, т.к. на практике оказывается не нужным, т.к. удобнее юзать специальное стековое АПИ, может теперь, после твоего замечания, выпилю

https://github.com/kobezzza/Collecti...lds/sys.js#L44
https://github.com/kobezzza/Collecti...ack/aliases.js

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

[B~Vladi]

код должен быть понятным человеку, а потом уже машине

Согласен, но это как раз тот случай, когда обоим хорошо

Попробуй протестировать потребление памяти при создании большого количества экземпляров.

[kobezzza]

Попробуй протестировать потребление памяти при создании большого количества экземпляров.

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

Хотя если юзать Collection как простой врапер для коллекций, то мб в этом и есть смысл, аля:

$C([1,2,3,4]).get(function (el) { return el % 2; });

[tenshi]

> Спасибо за ссылку, но не понятно к чему она?

пригодится

> зависимости модулей прописаны в модулях, общая схема сборки прописана в core.js,
> достаточно лишь запустить сборку build.js и указать нужные флаги сборки.

сколько лишних телодвижений..

> Не нравится - не юзай.

я и не юзаю) но ты тратишь своё время впустую

> а SQL я добавил только сейчас, как сахар.

вот именно что, фича для галочки. тонны кода, а как сделать банальное - выбрать записи со значением поля "';DROP TABLE users" я так и не нашёл.

> ЗЫ: не пиши плз в этой теме ничего не по делу, уже одну тему засрали в оффтопе.

засрём и эту

[tenshi]

да, и я смотрю ты активно используешь eval - это крайне медленно. ибо jit приходится каждый раз напрягаться. использование замыканий даёт лучший результат.
вот, смотри, например, низкоуровневый шаблонизатор без единого эвала http://habrahabr.ru/post/99005/