Не часто в низкоуровневых спеках встретишь слово Javascript; удивление было не инженерного свойства, скорее как в учебнике по алгебре встретить анекдот.
в Европе, куча компаний спокойно живёт с кодом разработанным ещё на коболе
C Коболом вообще всё прекрасно до сих пор, это необычный, но очень удачный язык для всяких штук, связанных с денежными делами – компилится в быстрый компактный код, типизация прямо в именах переменных и тп штуки. Типа как Эрланг для телекома – тоже очень странный и ни на что не похожий, но для распределённых систем лучше ничего не придумали.
Это может быть какая-то кривая наколенная имплементация XML, типа мы processing instructions выдаём как ASCII, а всё остальное у нас в той кодировке, которая указана в этих PI. Я такое видел, но в прошлом веке ещё. Помню точно, что у какого-то сервиса ФНС был такой «типа XML» в котором атрибуты без кавычек и ни одним стандартным парсером он не разбирался.
Нет, если от КОИ-8 отрезать старший бит останется 7 бит ASCII, полноценная латиница. В КОИ-7 Н2 в младших семи битах содержится и кириллица, с ASCII оно совместимо очень частично.
Мне после просмотра у CuriousMarc серии видео о восстановлении телетайпа модели 19 (https://www.youtube.com/playlist?list=PL-_93BVApb5-9eQLTCk9xx16RAGEYHH1q) показалось, что это адский геморрой – там механически довольно сложный узел, который в весьма бойком ритме должен без заеданий работать. То-есть заменить-то может и можно, но вот сделать это в режиме «вынул-вставил» точно не получится.
Плюс это всё надо на несколько моделей распространить, в общем, мне не кажется, что это беспроблемный процесс.
Широкий угол как раз нехорошо, потому что при равном разрешении камеры широкий угол понижает видимость мелких деталей поверхности, за которые может уцепиться алгоритм дискриминатора сдвига. Алгоритм кстати очень простой и вычислительно несложный, придуман А.В. Русаковым в 1975 сами догадайтесь для какого применения. Существенно контрастные маркеры этому алгоритму не обязательны, достаточно мелких неровностей. Именно этот алгоритм позволял даже AR.Drone – первому массовому дрону – висеть как вкопанному на месте на любой доступной высоте, и это в 2010 году, c надирной ч/б камерой разрешением 160х160 и хилым процессором.
Условное форматирование – как в Экселе: если значение отвечает условию 1 (условие – функция), присвоить css .red (а если не отвечает – снять класс .red), если отвечает условию 2 – присвоить/снять класс .blue, и тд.
Пересчёт зависимостей – тоже примерно как в Экселе: если есть инпут #X, инпут #Y и див #R в котором X*Y, див надо пересчитывать на каждое изменение X или Y.
Асинхронная инициализация – это когда вы форму стартуете, а она промис вернула (или оригинальный jQuery object, расширенный промисом, так можно и цепочку не ломает), и ресолвит его только когда закончила зависимости грузить, данные обновлять, рисовать и пр.
… привяжет проперти x к DOM-ноде #x вне зависимости от того, что там за нода. Если там div – просто покажет значение; если там input – свяжет этот инпут так, что если в него что-то написать, то в объекте с данными тоже значение обновится; если там например инстанцирован плагин типа select2 или $.ui.slider – реактивно свяжет сразу с плагином полностью скрывая всю многословную механику взаимодействия с ним и отлова его событий.
Доп.фунции будут перегружать
Это как посмотреть. Мультиметоды сильнее перегружают – то-есть когда у вас от аргументов существенно зависит что метод делает, это нехорошо, дохрена всего помнить надо. Чтобы этого избежать и придуманы в соглашении для jquery-плагинов команды – то-есть для анбайнда лучше делать $(selector).event('unbind', 'varName'); для обновления – $(selector).event('update', newValue) и тд. Команды – не самая красивая идея, но точно лучше кучи неочевидных сигнатур одной функции, особенно если вы минимализм декларируете.
Даже просто с точки зрения читаемости лучше: сразу понятно, что написано unbind, не надо угадывать, что там в переменных, которые вы как параметры передали.
$('#parentDiv').my({
data: {x:1, y:2},
ui: {'#x':'x', '#y':'y'}
});
// чтобы поменять значение извне, используем
// соглашение jquery на команды для плагинов
$('#parentDiv').my('data', {x:15}); // обновится только x
Объединять в один объект (то, что вы называете «слепить в одну соплю») имеет смысл по очевидной причине: этот объект становится унитарным реюзабельным компонентом (в $.my они называются манифестами). Такой компонент, однажды определённый, можно будет инстанцировать на разные DOM-ноды, подставляя в данные новый объект. Термин «пространство имён» не очень подходит есчо. Каждый инстанс компонента – это, скорее, отдельный scope, а не отдельный namespace.
Есть дополнительный бонус: если написать сериализатор-десериализатор таких объектов в json (в $.my такой есть), эти компоненты можно а) писать-читать в NoSQL базу, б) объединять, в) просто обрабатывать как объекты, а не как код. То-есть вкладывать друг в друга как подчинённые компоненты, мёржить, использовать одни как генерики-прототипы для других более кастомизированных, и пр.
То-есть мёрж-экстенд это примерно так для $.my:
var app = {
data:{x:0, y:0}, // дефолтные значения
ui:{
'.x':(data)=>data.x,
'.y':(data)=>data.y
}
};
var data1 = {x:5, y:10},
data2 = {x:15, z:20};
$('#node1').my(app, data1); // инстанс в #node1 покажет data1
$('#node2').my( // расширенный инстанс в #node2 покажет data2
$.extend(!0, {ui:{'.z':(data)=>data.z}}, app), // расширяем компонент
data2 // передаём data2 как данные
);
Если вы собираетесь делать что-то большее, чем небольшой статический шаблонизатор (их полно и так, и есть куда короче вашего), вам не избежать усложнения инструмента для упрощения записи компонентов для него.
А если ещё немного подумать и порешать кучу сопутствующих задач типа условного форматирования, привязки инпутов, пересчёта зависимостей, асинхронной инициализации и пр – то как раз и получится jQuery.my.
Кстати, для jQuery-плагинов чётко специфицирован рекомендуемый формат вызовов: если первый аргумент – строка, то она должна быть запрашиваемым действием, типа там "init" или "update".
Не часто в низкоуровневых спеках встретишь слово Javascript; удивление было не инженерного свойства, скорее как в учебнике по алгебре встретить анекдот.
Меня в своё время просто убила
FJCVTZS, я сначала подумал это прикол какой-то )Это в английской версии волка сварили и съели, в русской он просто обжегся и убежал.
Гораздо раньше. VM/370 вышла в 1972, и она не первая.
Там относительно ASCII сброшен 6-й бит, то-есть кодировка совсем простая: A–1, B–2, C–3 и т.д.
C Коболом вообще всё прекрасно до сих пор, это необычный, но очень удачный язык для всяких штук, связанных с денежными делами – компилится в быстрый компактный код, типизация прямо в именах переменных и тп штуки. Типа как Эрланг для телекома – тоже очень странный и ни на что не похожий, но для распределённых систем лучше ничего не придумали.
Если коротко, там пересечение стандартов. Некоторые просто мёртвые, некоторые устаревшие, а что вышло – живее всех живых.
Это может быть какая-то кривая наколенная имплементация XML, типа мы processing instructions выдаём как ASCII, а всё остальное у нас в той кодировке, которая указана в этих PI. Я такое видел, но в прошлом веке ещё. Помню точно, что у какого-то сервиса ФНС был такой «типа XML» в котором атрибуты без кавычек и ни одним стандартным парсером он не разбирался.
Стойте, как это?
Атрибут
encoding, набранный строчными, в КОИ-7 превратится вЕНКОДИНГпо идее, нет?Нет, если от КОИ-8 отрезать старший бит останется 7 бит ASCII, полноценная латиница. В КОИ-7 Н2 в младших семи битах содержится и кириллица, с ASCII оно совместимо очень частично.
Эммм… Так на неё ссылка же втором абзаце )
Мне после просмотра у CuriousMarc серии видео о восстановлении телетайпа модели 19 (https://www.youtube.com/playlist?list=PL-_93BVApb5-9eQLTCk9xx16RAGEYHH1q) показалось, что это адский геморрой – там механически довольно сложный узел, который в весьма бойком ритме должен без заеданий работать. То-есть заменить-то может и можно, но вот сделать это в режиме «вынул-вставил» точно не получится.
Плюс это всё надо на несколько моделей распространить, в общем, мне не кажется, что это беспроблемный процесс.
Билетные принтеры вообще используют КОИ-7, до сих пор. Как минимум в спецификациях к ним так написано.
Широкий угол как раз нехорошо, потому что при равном разрешении камеры широкий угол понижает видимость мелких деталей поверхности, за которые может уцепиться алгоритм дискриминатора сдвига. Алгоритм кстати очень простой и вычислительно несложный, придуман А.В. Русаковым в 1975 сами догадайтесь для какого применения. Существенно контрастные маркеры этому алгоритму не обязательны, достаточно мелких неровностей. Именно этот алгоритм позволял даже AR.Drone – первому массовому дрону – висеть как вкопанному на месте на любой доступной высоте, и это в 2010 году, c надирной ч/б камерой разрешением 160х160 и хилым процессором.
Условное форматирование – как в Экселе: если значение отвечает условию 1 (условие – функция), присвоить css .red (а если не отвечает – снять класс .red), если отвечает условию 2 – присвоить/снять класс .blue, и тд.
Пересчёт зависимостей – тоже примерно как в Экселе: если есть инпут #X, инпут #Y и див #R в котором X*Y, див надо пересчитывать на каждое изменение X или Y.
Асинхронная инициализация – это когда вы форму стартуете, а она промис вернула (или оригинальный jQuery object, расширенный промисом, так можно и цепочку не ломает), и ресолвит его только когда закончила зависимости грузить, данные обновлять, рисовать и пр.
)) Ок. У меня правда реактивное связывание и из коробки распознаётся куча контролов, то-есть:
… привяжет проперти
xк DOM-ноде#xвне зависимости от того, что там за нода. Если там div – просто покажет значение; если там input – свяжет этот инпут так, что если в него что-то написать, то в объекте с данными тоже значение обновится; если там например инстанцирован плагин типа select2 или $.ui.slider – реактивно свяжет сразу с плагином полностью скрывая всю многословную механику взаимодействия с ним и отлова его событий.Это как посмотреть. Мультиметоды сильнее перегружают – то-есть когда у вас от аргументов существенно зависит что метод делает, это нехорошо, дохрена всего помнить надо. Чтобы этого избежать и придуманы в соглашении для jquery-плагинов команды – то-есть для анбайнда лучше делать
$(selector).event('unbind', 'varName'); для обновления –$(selector).event('update', newValue)и тд. Команды – не самая красивая идея, но точно лучше кучи неочевидных сигнатур одной функции, особенно если вы минимализм декларируете.Даже просто с точки зрения читаемости лучше: сразу понятно, что написано unbind, не надо угадывать, что там в переменных, которые вы как параметры передали.
В общем, дерзайте ))
Не уверен, что понял вопрос, но всё же:
Кроме 'data' у инстанса ещё довольно много других команд, вот тут http://jquerymy.com/api.html#CW-external-c все.
Идея с раздельными
.varи.eventтак себе – потому что вы делаете два плагина вместо одного. Есть устоявшаяся практика и рекомендации jQuery https://learn.jquery.com/plugins/basic-plugin-creation/#minimizing-plugin-footprint.Объединять в один объект (то, что вы называете «слепить в одну соплю») имеет смысл по очевидной причине: этот объект становится унитарным реюзабельным компонентом (в $.my они называются манифестами). Такой компонент, однажды определённый, можно будет инстанцировать на разные DOM-ноды, подставляя в данные новый объект. Термин «пространство имён» не очень подходит есчо. Каждый инстанс компонента – это, скорее, отдельный scope, а не отдельный namespace.
Есть дополнительный бонус: если написать сериализатор-десериализатор таких объектов в json (в $.my такой есть), эти компоненты можно а) писать-читать в NoSQL базу, б) объединять, в) просто обрабатывать как объекты, а не как код. То-есть вкладывать друг в друга как подчинённые компоненты, мёржить, использовать одни как генерики-прототипы для других более кастомизированных, и пр.
То-есть мёрж-экстенд это примерно так для $.my:
Если вы собираетесь делать что-то большее, чем небольшой статический шаблонизатор (их полно и так, и есть куда короче вашего), вам не избежать усложнения инструмента для упрощения записи компонентов для него.
Очевидное улучшение – не писать
jQuery().eventна каждый контрол, а делать один вызов и передавать туда объект, например так:Если думать дальше – имеет смысл сделать отдельные ветки для объекта с данными и с привязкой контролов к данным:
А если ещё немного подумать и порешать кучу сопутствующих задач типа условного форматирования, привязки инпутов, пересчёта зависимостей, асинхронной инициализации и пр – то как раз и получится jQuery.my.
Кстати, для jQuery-плагинов чётко специфицирован рекомендуемый формат вызовов: если первый аргумент – строка, то она должна быть запрашиваемым действием, типа там
"init"или"update".Не, автор не дотянул, но думает в том же направлении ))