Почти всего этого нет, не было необходимости в реальных проектах, а добавлял только то что нужно или что используется чаще чем в 10% случаев (как правило 90% функционала фреймворков работает для 10% юз кейсов, ну и 10% для 90%, этого хотелось избежать)
1) derived — это как раз функции с реализацией, типа
2) кэша на них нет, ситуация где значение такого поля используется больше 1-2 раз мне так с ходу не придумывается и не попадалась, но наверное бывает
3) таким образом как в ampersand-model передача на сервер не сделала, я думал над этим, но пока не ощутил необходимости в таких функциях именно в модели. Собственно отправка модели на сервер выполняется так:
app.ajax.doSearch(app.models.searchParams, callback);
// или
app.ajax.save(app.models.listing.all(), callback);
// или
app.ajax.save(app.models.listing.listByTp("some type"), callback);
вместо ссылки на синглтон модель из примера можно подставить конкретный элемент коллекции, либо можно послать всю коллекцию
4) отправляются все геттеры модели кроме объявленных как jiant.transient — эти на сервер не посылаются (и кроме derived)
5) задача валидации не входит в модель, для этого есть jquery плагин validate
6) проверки типов тоже нет, в разрабатываемых проектах ни разу не возникло ситуации чтобы я подумал что она нужна
7) значения по умолчанию — вот это изредка возникает, и этого сейчас нет, чтобы установить какие-то начальные значения, нужно их ставить через сеттеры или через update()
А вообще именно ampersand-model мне не попадался, искренне благодарю за наводку. Он действительно хорошо расширяет бэкбон и надо будет поизучать. Единственно — синглтон приложение (если я верно понял) — это несерьезно. У нас повсюду минимум два приложения крутится на страницах — одно это чат, другое основное, а кое-где и по 3-4, с разных доменов, и они прекрасно друг с другом уживаются, включая совместную работу. Ну и хэш навигация у них как почти везде сделана явно в лоб. В этом jiant сильно обогнал их.
Увы, я тоже встречал таких «хороших» (в кавычках) программистов — трудолюбивых (без кавычек) и готовых 8 часов писать 100 строк кода вместо того чтобы подумать 1 час и потом за 10 минут написать 3 строки. К счастью поувольняли(сь), но до сих пор мы за ними разгребаем их «творения». А многие могли бы делать хорошо, но не хотят думать.
Я попытаюсь ) Продолжу писать о других компонентах фреймворка.
Лучше попытаться и обломаться чем не попытаться.
По-крайней мере ниша нормального фреймворка на javascript сейчас пуста, то что доминирует — такое убожество, что просто приглашает попытаться.
Если мне удастся найти несколько человек, заинтересованных в новом фреймворке, это уже комьюнити для начала.
Присоединяйтесь, хотя бы попробуйте )
изящество в том что автор и ревьюер инкапсулированы внутри модели, и для внешнего использования вызывается всего-лишь
env.author()
или
env.reviewer()
это действительно удобно и изящно
Тогда мне можно код аналогичный бэкбона, для сравнения? Со всеми декларациями переменных.
Насчет одинакового ида — как раз здесь это плевое дело — при обновлении переменной передаются старое и новое значения. Допустим, мне прилетело по вебсокетам обновление на запись, тогда у меня сработает вот такой код:
Где oldText — текущее значение, newText — новое. Подавляющее большинство задач в jiant решается на порядок меньшим объемом кода, это кстати из отзывов реальных людей (что-нибудь типа «почему тут так мало кода»), попробовавших на нем писать, а не реклама.
Сразу хочу сказать «спасибо за комментарии», все написанное очень ценно и интересно.
По делу — Например, в бэкбон вот так:
book.set("title", "A Scandal in Bohemia");
а здесь вот так:
book.title("A Scandal in Bohemia");
Выглядит похоже. Но во втором случае есть автозавершение от IDE и это гарантирует что я не описался в строчной переменной и сэкономило мне от секунды до нескольких написания. Казалось бы — мелочь, но сколько времени экономится и потенциальных ошибок обходится. Аналогично get.
Вообще когда я начинал jiant — я не смог найти ни одного дружащего с автозавершением js фреймворка, поэтому начал свой )
По объявлению интерфейса — В джаве тоже очень похожая запись будет интерфейса. А в С# еще больше.
И вот за этими "..." внутри бэкбон функции скрывается тоже ведь строчка кода, которую надо написать или скопировать. Это объявление не пустое.
Насчет изобретения велосипеда — Форду или кому-то еще когда-то не понравились все имевшиеся на тот момент автомобили и он сделал свой. И неплохо получилось.
Взорвать мозг, забыв что там, довольно сложно, так как всегда можно взглянуть на объявление. Плюс по смыслу обычно всегда понятно, не знаю почему, может проектировать удачно выходит. Уже название модели подсказывает что это такое и как используется.
Великая благодать Jiant'а в том что вместо программирования мы проектируем, и в конце получаем работающий код.
Попробую этот подход и здесь.
Два пользователя — допустим, такой сценарий — пользователь, пишущий комментарий, и пользователь, опубликовавший запись )
Они идентичны по параметрам, поэтому да, один репозиторий, допустим такой:
Мы уже видим что у нас в приложении есть объект пользователя с именем и идентификатором, далее есть варианты на выбор, какой больше соответствует религии данного программиста:
1) Объявим модель env с полями author, reviewer и выставим туда нужных пользователей
env: {
author: function(val) {},
reviewer: function(val) {}
}
jiant.onUiBound(app, function($, app) {
var m = app.models;
// откуда-то получили, скажем с сервера данные об этих пользователях
m.env.author(m.user.add(authorData)[0]);
m.env.reviewer(m.user.add(reviewerData)[0]);
});
2) Аналогично 1му, но методы доступа помещаем прямо в user:
Не совсем понимаю в чем схожесть с бэкбоном, так как там приходится писать много избыточного кода на реализацию всех функций модели, а здесь это делается автоматически. То что декларируется модель с ее полями — это только внешнее и на мой взгляд позитивное проявление, служащее документированию. Так можно и интерфейсы какого-нибудь C# или джавы обвинить в плагиате с бэкбона )
При чем тут золушкина туфелька тоже не понял — интерфейс не переиспользуется не-пойми для чего, а каждый объект описывается своим. Как раз эта схожесть подхода катастрофически удобна, хотя и ломает стереотипы. Стоит только попробовать. Я сам не сразу решился на такой кардинальный шаг.
Про глобальность — во-первых модели это не переменная, это API, доступ к моделям происходит через функции. Таким образом недостатка «а кто это поменял» здесь нет — при отладке любой доступ легко отслеживается по стек трейсу, либо нажатием ctrl+alt+f7 в той же Идее, чего никак не скажешь про другие фреймворки. Синглтон в приложении к моделям это всего лишь объект, встречающийся в приложении один раз, а не тот классический статический объект.
Наследование в функциональном языке — до сих пор делается костылями. И не использование этих костылей я не считаю недостатком. А es6 классы это просто чуть подкрашенная обертка вокруг все тех же костылей. Давайте уже честно писать на функциональном языке функциями. Но если мне все же захочется унаследоваться сейчас, напишу вот так:
var modelBase = {...}
var modelInherited = $.extend({}, modelBase, {extra-properties-for-child});
Но вообще метод add или updateAll возвращает объект модели, и при честном использовании классов es6 — я просто создам этот объект в коде и верну его (для репозиториев). Можно сказать, что модель это java reflection, если знакомо — и по нему воссоздается класс объекта.
почему без вьюшек, если охватить все, то сейчас там есть вьюшки, шаблоны, event bus, абстракция программной логики (а-ля джавовские интерфейсы с подменяемой реализацией), аякс абстракции, модули, API для работы с хэш-навигацией (на порядок лучше чем любая из известных мне реализаций, включая убогий angular), возможность загрузки сразу нескольких приложений на страницу, с разделяемой опять же хэш-навигацией, кроссдоменность на лету, подгрузка html-реализации тех же вьюшек и шаблонов. Просто это очень много всего, здесь я написал только про один из компонентов.
Кстати, чем API кривовато?
После них не работает к сожалению.
Касательно примеров — часть коммерческие приложения и чтобы дать на них ссылку мне надо получить разрешение. Из того что доступно — достаточно крупное — игрушка http://frombeyond-game.com, на которой собственно отлаживалась и проверялась на жизнеспособность в произвольном окружении концепция, домашняя страница и сама игра там реализованы полностью на jiant.
Также есть локально реализация todo-mvc, в ближайшие дни выкладываю на github (думал уже выложил ) )
ну да, только во всех примерах так не делают. а ведь все кто возьмется это использовать — начнут с примеров. Я говори про общую идеологию архитектуры приложения, не про конкретные локальные фреймворки. Некоторые стимулируют к разделению логики, другие наоборот к смешиванию
спасибо за интересные ссылки, почитал и еще буду изучать. Чем-то похоже на angular. Но мне не понравилось опять смешивание логики и представления, это возможно экономит минуты при написании, но потом чтобы разобраться при поддержке и модификации — теряется гораздо больше времени. Это мой личный опыт, может быть попадались такие проекты. В случае абстрактной нотации html код не несет абсолютно никакой логики. И при использовании фреймворка оказывается что проще писать логику отдельно, чем помещать в html быстрые однострочные скрипты. То есть направления тут просто противоположные.
я сейчас пишу реализацию ToDoMVC и в ближайшие дни выложу с подробными объяснениями процесса разработки. Подход хорошо ощущается именно в динамике, он больше ориентирован на процесс разработки и последующие изменения-поддержку.
На knockout смотрел. По сравнению с Jiant — там нет автозавершения кода вместо строк, нет проверки что ссылки на элементы html валидны (например, можно написать строку с опечаткой и потом разбираться с ошибкой) — jiant сообщает о всех расхождениях, что в комплекте с автозавершением повышает качество кода на порядок. Чтобы понять структуру приложения, события, состояния и все значащие элементы в jiant достаточно посмотреть на json определение. Вхождение нового человека в проект и его чтение и понимание структуры возрастает также в разы.
Ну и главное — это то самое абстрактное определение интерфейса, с которого все начинается. В knockout это смешано с html кодом.
Внутри пока нет. Совсем недавно встал вопрос валидации в одном проекте и решение было следующим — на каждый код ошибки размещался свой элемент с описанием ошибки, сервер возвращал код ошибки или ничего. Если возвращался код ошибки — показывался соответствующий элемент с ошибкой. Сэкономил на клиентской проверке. Задача была специфической, проверки были не только из разряда «пустое поле», а и довольно изощренные, типа наличие целевых контактов и тп.
Привык что Идея авто-завершает функции скобками и не поставил на автомате )
1) derived — это как раз функции с реализацией, типа
2) кэша на них нет, ситуация где значение такого поля используется больше 1-2 раз мне так с ходу не придумывается и не попадалась, но наверное бывает
3) таким образом как в ampersand-model передача на сервер не сделала, я думал над этим, но пока не ощутил необходимости в таких функциях именно в модели. Собственно отправка модели на сервер выполняется так:
вместо ссылки на синглтон модель из примера можно подставить конкретный элемент коллекции, либо можно послать всю коллекцию
4) отправляются все геттеры модели кроме объявленных как jiant.transient — эти на сервер не посылаются (и кроме derived)
5) задача валидации не входит в модель, для этого есть jquery плагин validate
6) проверки типов тоже нет, в разрабатываемых проектах ни разу не возникло ситуации чтобы я подумал что она нужна
7) значения по умолчанию — вот это изредка возникает, и этого сейчас нет, чтобы установить какие-то начальные значения, нужно их ставить через сеттеры или через update()
А вообще именно ampersand-model мне не попадался, искренне благодарю за наводку. Он действительно хорошо расширяет бэкбон и надо будет поизучать. Единственно — синглтон приложение (если я верно понял) — это несерьезно. У нас повсюду минимум два приложения крутится на страницах — одно это чат, другое основное, а кое-где и по 3-4, с разных доменов, и они прекрасно друг с другом уживаются, включая совместную работу. Ну и хэш навигация у них как почти везде сделана явно в лоб. В этом jiant сильно обогнал их.
Лучше попытаться и обломаться чем не попытаться.
По-крайней мере ниша нормального фреймворка на javascript сейчас пуста, то что доминирует — такое убожество, что просто приглашает попытаться.
Если мне удастся найти несколько человек, заинтересованных в новом фреймворке, это уже комьюнити для начала.
Присоединяйтесь, хотя бы попробуйте )
env.author()
или
env.reviewer()
это действительно удобно и изящно
Насчет одинакового ида — как раз здесь это плевое дело — при обновлении переменной передаются старое и новое значения. Допустим, мне прилетело по вебсокетам обновление на запись, тогда у меня сработает вот такой код:
Где oldText — текущее значение, newText — новое. Подавляющее большинство задач в jiant решается на порядок меньшим объемом кода, это кстати из отзывов реальных людей (что-нибудь типа «почему тут так мало кода»), попробовавших на нем писать, а не реклама.
По делу — Например, в бэкбон вот так:
а здесь вот так:
Выглядит похоже. Но во втором случае есть автозавершение от IDE и это гарантирует что я не описался в строчной переменной и сэкономило мне от секунды до нескольких написания. Казалось бы — мелочь, но сколько времени экономится и потенциальных ошибок обходится. Аналогично get.
Вообще когда я начинал jiant — я не смог найти ни одного дружащего с автозавершением js фреймворка, поэтому начал свой )
По объявлению интерфейса — В джаве тоже очень похожая запись будет интерфейса. А в С# еще больше.
И вот за этими "..." внутри бэкбон функции скрывается тоже ведь строчка кода, которую надо написать или скопировать. Это объявление не пустое.
Насчет изобретения велосипеда — Форду или кому-то еще когда-то не понравились все имевшиеся на тот момент автомобили и он сделал свой. И неплохо получилось.
Взорвать мозг, забыв что там, довольно сложно, так как всегда можно взглянуть на объявление. Плюс по смыслу обычно всегда понятно, не знаю почему, может проектировать удачно выходит. Уже название модели подсказывает что это такое и как используется.
Попробую этот подход и здесь.
Два пользователя — допустим, такой сценарий — пользователь, пишущий комментарий, и пользователь, опубликовавший запись )
Они идентичны по параметрам, поэтому да, один репозиторий, допустим такой:
Мы уже видим что у нас в приложении есть объект пользователя с именем и идентификатором, далее есть варианты на выбор, какой больше соответствует религии данного программиста:
1) Объявим модель env с полями author, reviewer и выставим туда нужных пользователей
2) Аналогично 1му, но методы доступа помещаем прямо в user:
3) Добавить поле пользователю role, выставлять его и искать по нему
3й способ расширяем, 1й почти как новые объекты, но вместо new — add, плюс перед new — возможность увидеть сразу список полей модели
При чем тут золушкина туфелька тоже не понял — интерфейс не переиспользуется не-пойми для чего, а каждый объект описывается своим. Как раз эта схожесть подхода катастрофически удобна, хотя и ломает стереотипы. Стоит только попробовать. Я сам не сразу решился на такой кардинальный шаг.
Про глобальность — во-первых модели это не переменная, это API, доступ к моделям происходит через функции. Таким образом недостатка «а кто это поменял» здесь нет — при отладке любой доступ легко отслеживается по стек трейсу, либо нажатием ctrl+alt+f7 в той же Идее, чего никак не скажешь про другие фреймворки. Синглтон в приложении к моделям это всего лишь объект, встречающийся в приложении один раз, а не тот классический статический объект.
Наследование в функциональном языке — до сих пор делается костылями. И не использование этих костылей я не считаю недостатком. А es6 классы это просто чуть подкрашенная обертка вокруг все тех же костылей. Давайте уже честно писать на функциональном языке функциями. Но если мне все же захочется унаследоваться сейчас, напишу вот так:
Но вообще метод add или updateAll возвращает объект модели, и при честном использовании классов es6 — я просто создам этот объект в коде и верну его (для репозиториев). Можно сказать, что модель это java reflection, если знакомо — и по нему воссоздается класс объекта.
Про двух пользователей чуть позже.
Кстати, чем API кривовато?
Касательно примеров — часть коммерческие приложения и чтобы дать на них ссылку мне надо получить разрешение. Из того что доступно — достаточно крупное — игрушка http://frombeyond-game.com, на которой собственно отлаживалась и проверялась на жизнеспособность в произвольном окружении концепция, домашняя страница и сама игра там реализованы полностью на jiant.
Также есть локально реализация todo-mvc, в ближайшие дни выкладываю на github (думал уже выложил ) )
Ну и главное — это то самое абстрактное определение интерфейса, с которого все начинается. В knockout это смешано с html кодом.