?

Log in

No account? Create an account
Во-первых, я завожу новое слово BlackBoxComponentBuilder и буду его тотально применять везде, где дело касается BlackBox Component Builder. Поскольку название BlackBox Component Builder - очень недружественное к поисковым системам. Сокращённым названием будет BBCB или Коробка Вирта.

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

Дальше я не очень понимаю, но модули могут быть скомпонованы в исполняемый файл или лежать в файловой системе (как dll/so). Если они лежат отдельно, то будут подгружаться по мере надобности.

Единицей компиляции является модуль, есть две команды - «Компилировать» и «Компилировать и выгрузить». Почти всегда нужна вторая из них, а горячая клавиша есть только у первой. Это странно, но исправимо, нужно открыть Dev\Rsrc\ru\Strings.odc средой и забрать подчёркнутую букву от другой команды:
<pre>
&Compile Компилировать
&Compile And Unload &Компилировать и выгрузить
</pre>

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

Модули распространяются или в виде ужасных закодированных файлов с абракадаброй. Такой файл обрабатывается так:
Меню/Файл/Новый - Вставить ужасный текст - Меню/Инструменты/Раскодировать . После этого там предлагается что-то сделать - скомпилировать или что-то. Это надо сделать.

Второй вариант - просто в виде файлов. odc, mod и т.п. Как с этим работать, я не знаю.

Связывание, компоновка, линковка. Делается тоже из среды. Для того, чтобы создать новую Коробку Вирта с вашими изменениями, иногда нужно воспользоваться файлом Dev/Docu/Build-Tool
Правая кнопка по пустому месту экрана/персонализация/ищем "подчёрк" и попадаем в нужный пункт: "подчёркивать клавиши доступа, когда они доступны", или же "подчёркивать сочетания клавиш доступа в меню, если они доступны".

Сами они инвалиды. Бл☼. 
Как и обычно, есть несколько поколений инструментов с пересекающимися областями применения. Шпаргалка.

Webpack (якобы) позволяет избавиться от bower и gulp/grunt.

Но grunt у нас есть по условию. Нам нужен bower?

Есть статья от декабря 2017 года
Bower умер, да здравствует npm. И Yarn. Что в ней?

Для чего был хорош Bower? Это - пакетный менеджер, который управляет фреймворками, библиотеками, ассетами (я так понял, ассеты - это «вручную» изготовленные (а не сгенерированные сборщиком) файлы css и js, хотя внятного определения не нашёл), утилитами. Он устанавливает их и контролирует корректность зависимостей.

Традиционно во многих проектах npm использовался для серверной стороны, а bower - для клиентской.

Основным преимуществом bower было то, что он ставит минимальный набор зависимостей, избегая дублировать библиотеки и предоставляя пользователю контроль над такими ситуациями. Например, bower позволял пользователю выбрать подходящую версию jQuery (разные библиотеки могут быть совместимы с разными дипазонами версий jQuery).

Эти возможности теперь реализованы в npm,Yarn и вебпак (каждым по отдельности или только системой из них -  об этом пока ни слова! - читаем дальше и надеемся на лучшее - прим.перев).

Далее приводится 6 причин, по которым надо отказаться от Bower. Из них вполне объективной  видится причина 2: экономичный граф зависимостей теперь
доступен в npm и yarn.

И далее - увы - веб, как обычно, разочаровал. Bower заменяется на систему из всех трёх инструментов. Никакого одного не достаточно. Про вебпак я уже составил своё мнение: пока есть возможность, я им пользоваться не буду.

На этом статья о серти bower заканчивается, и в конце даётся ссылка на статью автора bower о том, как мигрировать с bower.

Здесь автор bower даёт практические рекомендации, как выводить из bower старые проекты. 
При вводе двуязычных текстов всегда трудно узнать, является ли "а" или "с" кириллической или латинской. Я разработал для Яра режим, при включении которого латиница подчёркивается.



Однако сейчас приходится заниматься другими файлами, и их удобнее обрабатывать не в среде Яра. Соответственно, возник вопрос о реализации подобного функционала для других сред разработки.

Здесь я соберу информацию, которую удалось на эту тему найти:
https://bitbucket.org/budden/iaroklava-js/src/master/

Общая идея - пробел служит модификатором. Если пробел нажали и удерживаем, то вводятся буквы латиницы, а если нажали и отпустили - то вводится пробел. Такой способ ввода рассчитан на слепой 10-пальцевый метод ввода. Он позволяет вводить, к примеру, html или md файлы с русским языком без переключения раскладки вообще. Но он требует обучения (до нескольких недель).

Соответственно, варианты такие. Для веба - это скрипт, результат которого можно посмотреть тут:


Для Windows - скрипт для программы Autohotkey.

Для Linux - ручная настройка xkb + набор взаимодействующих программ.

Смотрите все подробности в репозитории. Смотрите также другие записи с тегом "раскладка клавиатуры".

Что это за текст


Текст написан для себя. По ходу дела я подумал, что он может быть интересен и другим (новичкам). Но редактирование поста в LiveJournal через медленную мобильную сеть не доставляет особой радости, поэтому оформление явно подкачало. И кое-где остались другие мелкие огрехи. Во всяком случае, я выполнил правило «если что-то непонятно, разберись и напиши об этом пост - когда забудешь - нагуглишь его».

Завязка


Прежде всего, о названиях. В семейство входят (как минимум) три имени: Mustache, Handlebars и Hogan.

В целом синтаксис mustache объяснён в руководстве по mustache (перевод тут, правда они не осилили перевод и перевели partials как "обособленные фрагменты" и тут же - как "частные значения"). Но есть две проблемы:



  • partials непонятны

  • не написано о наследовании шаблонов, которое, впрочем, является нестандартным расширением


В конце концов я пришёл к выводу, что partials - это вставляемые из другого места фрагменты шаблона (аналог #include в Си), которые тоже могут содержать расширяемые элементы, такие, как {{имя}}. В зависимости от реализации mustache, эти куски могут браться из файлов (по имени файла), или же они должны быть предоставлены при расширении (render) шаблона.



Наши цели



  • сделать простейший работающий пример с partials

  • сделать, чтобы имя в шаблоне, отсутствующее в данных выдавало ошибку, а не просто расширялось в пустую строку - иначе не поймать опечатки

  • компилировать partials (в документации по mustache говорится, что они расширяются во время выполнения)

  • избавиться от необходимости явно передавать partials - это дикость

  • понять варианты использования шаблонизатора и как их реализовывать



Теория


Mustache, по определению - это препроцессор, который на вход получает три вещи:



  • данные, которые по структуре представимы в виде json

  • шаблон - текст с разметкой для подстановки данных

  • реализацию всех partials, упомянутых в шаблоне


и на выходе даёт текст - расширенный шаблон. Препроцессор имеет много реализаций на разных языках программирования и много интеграций с различными средами и может называться mustache, hogan, handlebars (и ещё как нибудь?).



Процесс (на примере hogan) таков:


 Компиляция (Hogan.compile) (нужен только шаблон)
   лексический разбор (Hogan.scan)
   синтаксический разбор (Hogan.parse)
   генерация кода (Hogan.generate)
 Расширение (КомпилированныйШаблон.render)  (на входе - данные и partials)




В простейшем случае компиляция и расширение шаблона производятся клиентом. Но! Данные - каждый раз разные (допустим, это товары или люди), а шаблон - одинаковый. Поэтому логично делать компиляцию пореже, запоминать и повторно использовать её результаты. Обычный Mustache может генерировать код расширения шаблона на Ruby (с помощью утилиты mustache). Hogan (с помощью утилиты hulk) генерирует код на JavaScript. Этот код может выполняться как на клиенте, так и на сервере (в случае node.js). Для PHP я нашёл библиотеку lightncandy, которая декларирует возможность генерировать PHP файлы по шаблону - так достигается серверное кеширование результатов компиляции. GRMustache для Swift не декларирует возможность сгенерировать код расширения шаблона. CL-mustache для common lisp порождает функцию, но по сути внутри неё - интерпретация, partial-ы не прекомпилируются. Есть реализация и для моего любимого tcl.



Так получилось, что для моей текущей работы был выбран Hogan.js - и это хорошо. В нём нет лишнего и он позволяет сохранять результат компиляции.


Пишем «Привет, мир!»



Скачиваем hogan.



> mkdir mu
> cd mu
> npm init 
> npm install hogan.js






Эти строки уже не совсем тривиальны. Если собираетесь использовать express, прочитайте все ответы на этот вопрос на stackoverflow - может быть, вам нужен hogan-express.



Создадим два файла - для шаблона и для фрагмента (partial).



шаблон.хш:



{{! это - файл шаблон.хш }}
Подставляемый говорит: '{{> подставляемый}}' 





подставляемый.хш:



Я - подставляемый и говорю: "{{Приветствие}}"





Это - файлы шаблонов. Обычно они имеют расширение .mustache или .hgs. Но мы, квасные патриоты, всему пытаемся дать русские названия. PhpStorm можно научить, что .хш - это файл mustache, для этого открываем файл, щёлкаем правой кнопкой мыши по его "табу" в списке файлов, далее - Associate with file type и выбираем Handlebars/Mustache.



Прекомпилируем шаблоны и сохраняем результат в файл «скомпилированный-шаблон.js»



> node_modules/.bin/hulk шаблон.хш подставляемый.хш > скомпилированный-шаблон.js





Заглянем в этот «скомпилированный-шаблон.js»:



if (!!!templates) var templates = {};
templates["шаблон"] = new Hogan.Template({
    code: function (c, p, i) {
        var t = this;
        t.b(i = i || "");
        t.b("Подставляемый говорит: '");
        t.b(t.rp("<подставляемый0", c, p, ""));
        t.b("'");
        return t.fl();
    }, partials: {"<подставляемый0": {name: "подставляемый", partials: {}, subs: {}}}, subs: {}
});
templates["подставляемый"] = new Hogan.Template({
    // и т.п.
});






Забавно, что вместо достаточно компактного шаблона получился гораздо больший по размеру код (который клиент должен скачать, скомпилировать и выполнить). На знаю-не знаю, всегда ли так уж хороши их рекомендации по предварительной компиляции.



Собираем всё воедино, в файл «тест-хогана.html»:



<html><head><meta charset=utf-8>
<script src="node_modules/hogan.js/dist/hogan-3.0.2.js"></script>
<script src="скомпилированный-шаблон.js"></script>
<script>
  let Данные = { "Приветствие": "Привет, мир!" };
  let РезультатРасширения = templates["шаблон"].render(Данные, templates);
  console.log(`РезультатРасширения: ${РезультатРасширения}`);
</script>
</head><body>Смотри сообщения консоли разработчика</body></html>





Открываем файл, переходим в инструменты разработчика (F12) и видим в консоли сообщение:



РезультатРасширения: Подставляемый говорит: 'Я - подставляемый и говорю: "Привет, мир!"'





Ловим ошибки


Теперь наша задача - выбрасывать исключение, если имя не существует. Мы запретим отсутствующие имена вообще. Если мы хотим пустоту, то нужно будет явно передать Null.



Во-первых, опции описаны на github. Среди них опции отлова ошибок нет. Смотрим исходник и видим недокументированную опцию doModelGet. Но суть не в том. Судя по коду, можно либо модифицировать код "на горячую", либо форк. Форк плох, т.к. ломается npm install и прочая. Попробуем горячую замену. Вставим в начало нашего скрипта следующие строки:



    // спасибо https://learn.javascript.ru/decorators
  let Старая_rp = Hogan.Template.prototype.rp;
  let Старая_d = Hogan.Template.prototype.d;
  let Старая_f = Hogan.Template.prototype.f;

  Hogan.Template.prototype.rp = function Декорированная_rp() {
    let фр = Старая_rp.apply(this,arguments);
    if (!!!фр) {
      throw new Error(`Не найден подставляемый фрагмент (partial) - ищите ключ отладчиком`);
    }
    return фр;
  };

  Hogan.Template.prototype.d = function Декорированная_d() {
      let зн = Старая_d.apply(this,arguments);
      if (!!!зн) {
          let key = arguments[0];
          throw new Error(`Не найдено имя «${key}»`);
      }
      return зн;
  };


  Hogan.Template.prototype.f = function Декорированная_f() {
      let зн = Старая_f.apply(this,arguments);
      if (!!!зн) {
          let key = arguments[0];
          throw new Error(`Не найдено имя «${key}»`);
      }
      return зн;
  };





Вроде оно работает для нашего простейшего примера, дальше пока не тестировал. Для локализации ошибки нужно с помощью dev tools поставить точку прерывания на место, откуда вылетает исключение, перегрузить страницу. Точка прерывания сработает. Тогда в стеке находим сгенерированный hulk-ом код и по его виду пытаемся понять, в каком месте у нас проблема, а по контексту смотрим, чего не хватает. Не слишком удобно, но лучше, чем ничего. Что делать, если шаблон представлен в виде строки - я не знаю, но, вероятно, где-то на стеке можно будет увидеть текст шаблона.



Наследование шаблонов


Это - ещё одна возможность, не упомянутая в «man 5 mustache», но описанная в непринятом предложении (pull request) для спецификации mustache. Попробую перевести суть сопроводительного письма своими словами:
«Мы часто хотим иметь базовый шаблон, в котором хранится скелет страницы, а каждая настоящая страница просто заменяет секции в этом скелете своим содержимым. Скелет может включать все скрипты аналитики и общую для всех страниц разметку, при этом остаётся возможность заменить заголовок на любой другой. Возможные решения здесь - копировать скелет в каждую страницу или генерировать страницу за два прохода, оба не идеальны. Поэтому мы хотим `наследование' страниц в стиле ООП»

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

Варианты использования

С этим мы толком не разобрались и примеры не были разработаны. Ясны следующие варианты:

  • Шаблоны передаются текстом на клиента, где и расширяются. В SPA могут кешироваться.

  • Шаблоны компилируются во время сборки сайта и превращаются в Javascript, который загружается клиентом и исполняется на им (это вариант нашего "приветмира"). По заверениям Twitter, это лучше, чем передавать шаблоны в виде текста и разбирать их на стороне клиента, но я сомневаюсь - как минимум, размер передаваемых данных увеличивается. Нужно проверять.

  • Шаблоны полностью расширяются на сервере, при возможности результаты расшерения кешируются с помощью утилит, генерирующих код на языке серверной стороны. Это возможно для PHP, Node.js, Swift.

Чего не хватает


  • В проекте https://github.com/kupriyanenko/jsttojs обещают предкомпиляцию в js для нескольких разных шаблонизаторов, включая mustache, но я не смотрел.

  • Плохо то, что сообщения об ошибке не показывают точное место в шаблоне, где ошибка произошла. Конечно, наличие хоть какого-то сообщения вместо молчаливой вставки пустоты - это большой шаг вперёд. Но я слёту не вижу, как можно выводить контекст без серьёзных изменений кода.

  • Предложенный патч толком не протестирован


Полезные ссылки по теме:

SlickGrid

Набор ссылок к выбору грида, и набор ссылок конкретно по SlickGrid

К выбору грида

Выбираем грид для админки - LOR

Хабр - обзор библиотек виджетов

SlickGrid

SlickGrid documentation improvement

Tags:

Учим JavaScript

Учим JS и собираем сюда всю толковое, что удаётся найти.

Собеседование на должность программиста JS (2014 год, явно устарело).

ООП - ссылка с "собеседования" - очень познавательно и хорошо разъясняет взаимосвязь "обычного" ООП и ООП в JS.

Что такое strict mode
Ссылка

'use strict'


По умолчанию применяется внутри модулей, т.е. внутри функций.
Разные глупости, типа присвоения константам, обращения к несуществующим переменным, удаления неудаляемых свойств, приводят к ошибке, а не молча игнорируются. Исключены или сделаны менее уязвимыми способы обращения к arguments, caller. Исключено создание переменной присваиванием. eval не может создать новых переменных в окружении.



Что нового в ES 6
Ссылка

  • let - переменные в текущем блоке, а не в текущей функции; const

  • Обратная кавычка - интерполяция (многострочных) строк

  • Destructuring

  • Классы - синтаксический сахар для конструкторов

  • Обещания

  • Стрелочные функции - сахар для bind. Позволяют использовать в качестве this значение this из текущей области видимости, а не this, определяемый по а.функция()

  • for .. of

Tags:

Вроде фигня - имя пользователя. Нетрудно привыкнуть, что с фамилией Щукин вы называетесь на своём рабочем компьютере Shukin. Или Shhukin? Или Shykin? А кстати, как вообще ваша фамилия, Щукин или Шукин?

А собственно, почему нельзя назвать Щукина - Щукиным? Вот техническое обсуждение темы "Может ли имя linux-пользователя содержать в себе символы кирилицы?" на известном форуме Linux.org.ru.

Приведу выдержки, со своими комментариями курсивом.

Eddy_Em> Может, но так делать не надо.

Nastishka> Создайте нормальную учетную запись в Linux с нормальным именем, а в самбе привяжите её к «самбовскому» имени кириллицей. (под "нормальным" понимается имя в латинице. Т.е. латиница - это нормально, а кириллица - видимо, ненормально)

cadaber> Вопрос, кто там у вас рулевой, кто за штурвалом. Ты, секретарша шефа, или главбух? Определись. Если ты рулишь, так забей на неправельные имена, это явно не твоя проблема. (Здесь предписывается администратору поставить руководство перед фактом, что имена будут "правильными", т.е. в латинице, поскольку он тут "рулит")

drBatty> ты про эпичные дыры юникода не слышал? про несимволы, которые не матчатся точкой? тогда всё ясно...(Речь о следующем: затруднения для создания имён с кириллицей заложены в самом стандарте представления текста utf-8. Это - сложный организационный и технический вопрос, но в России он не поставлен на повестку дня).

drBatty> не говори. А музыканты рабы итальяшек. А вот доктора вообще у какого-то мёртвого народа в рабстве.(Выдвинут тезис, что в компьютерах стандарт - это английский, как в музыке - итальянский. Популярная точка зрения в ИТ.)

Eddy_Em> Ага: у одного - юникод, у второго - КОИ, у третьего - 1251… (Ещё одна существенная техническая проблема. Стандартов представления кириллицы несколько, и когда они встречаются в одном компьютере, возникает проблема их несовместимости между собой. Это - ещё один сложный организационный и технический вопрос)

mumpster> он (Шеннон) взял два языка -англ и рус. как антиподы преимуществом русского оказалось гораздо большая помехозащищённость по сравнению с английским за счёт большей избыточности. компактность англ. достигается в немалой степени за счёт утрат почти полной утраты флексий и как => увеличения зависимости от контекста и полноты слов и снижение помехозащищённости. (Продолжается обсуждение тезиса о том, что русский язык - вообще плохой и не годится для компьютеров. Здесь приведён "математический" аргумент в пользу русского, который был найден Шенноном. Запомним его на будущее :) )

В сухом остатке: нельзя иметь имя пользователя в кириллице в компьютерах под управлением Linux.

Profile

budden73
budden73

Latest Month

February 2019
S M T W T F S
     12
3456789
10111213141516
17181920212223
2425262728  

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by Tiffany Chow