Рубрика: Правила и рекомендации

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

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

node bin/www

происходит перестроение файла ~/modules/dbcontext.js. Данный файл предоставляет API для работы с базой данных. 

Читать далее «Генерация контекста для работы с базой данных»

Основным инструментом для логирования был выбранlog4js (https://www.npmjs.com/package/log4js) 

Информация сохраняется в файловой системе по такому пути ~/logs.

Для создания собственных обработчиков для socket требуется регистрация обработчика. Примером для регистрации может быть rpc. В данном приложение вызов всех RPC функций возможен не только по HTTP, но и через WebSocket. 

Регистрация происходит в файле ~/modules/socket/main.js. Для этого требуется подписаться на определенное событие. В текущем примере будет идти речь об rpc.

socket.on(‘rpc', function);  

, где function — это функция которая будет вызвана при получении сообщения от rpc. Данная функция должна выглядеть примерно так: 

function(req, res, socket) { // (1) 
    return function (data) { // (2) 
 
    } 
}  

, где:

• res и req (1) — объекты которые примерно эмитируют стандартные response и request;
• socket (1) — объект подключения;
• data (2) — данные которые были переданы.

Данная возможность позволяет внедрять собственный код при вызове стандартной RPC-функции. Например, нам требуется при создании нового пользователя записать информацию в лог.  

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

Создаем файл ~/modules/injections/notification.js.

exports.userCreateWithLog = function(state, action, method, data) {  // (1) 
   if(action == ‘sys_users’ && method == ‘Add’) { // (2) 
     var login = data.login; // (3) 
     console.log(‘Пользователь с логином ’ + login + ‘ создан.’); 
   } 
}  

Файл должен экспортировать функцию (1), в нашем случаи это — userCreateWithLog. Данная функция принимает несколько параметров (1): 

• state: any — информация об авторизованном пользователе. 
• action: string — имя RPC — объекта (сущности базы данных); 
• method: string — имя метода RPC объекта. 

• data: any — данные переданные RPC функции. 

В функции создаем условие на проверку объекта и метода, который хотим обрабатывать (2). 

Далее получаем (3) данные из объекта и выполняем с ним требуемую работу. 

Создание функция заключается формирование объекта в определенном формате. Для работы RPC требуется, чтобы каждый объект находился в определенном пространстве имен, например в текущем проекте это — PN.  

Например, нам требуется создать собственный объект, который позволит получить серверное время. Для этого нам нужно создать файл, который должен располагаться в папке ~/modules/custom-context. Пусть это будет shell.js

Информация, которая находиться в файле shell.js

/** 
* объект для формирования ответа 
*/ 
var result_layout = require('mobnius-pg-dbcontext/modules/result-layout'); // (1) 
  
/** 
* Объект с набором RPC функций 
*/ 
exports.shell = function (session) { // (2) 
  
    return { // (3) 
     isLocal: true, // нужно указывать, иначе безопасность при создании meta не пропустит (4) 
 
        /** 
         * Получение серверного времени 
         * @param {*} data  
         * @param {*} callback  
         * @example 
         * // никаких параметров не нужно передавать 
         * PN.shell.getServerTime({}, function(){}) 
         */ 
        getServerTime: function (data, callback) { // (5) 
            callback(result_layout.ok([new Date()])); // (6) 
        } 
    } 
}  

Читать далее «Создание собственных RPC — функций»

Если применяется «Basic – авторизация», то токен должен состоят из строки «Token», символа пробела, плюс логина и пароля, которые разделены символом «:» (двоеточие) и закодированы в строку base64. Например, «Token » + convertToBase64(user:password);.  

Рисунок 1.Пример токена авторизации. 

Токен авторизации должен передаваться в заголовке запроса, например, это – заголовок «rpc-autorization». 

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

«Пакет» — единица данных для обмена информацией. Обмен данными между мобильным устройством происходить при помощи «пакетов». Пакет состоит из:

• заголовка;
• метаданных;
• строкового блока;
• бинарного блока.

Заголовок

– представляет из себя строку, в которой указывается число. Число предназначено для определения длины метаданных. Строка имеет длину 16 символов и состоит из типа, чисел, «наполнителя» и статуса пакета. Наполнителем должен являться символ «.» (точка). Статусы пакета: 

• 0 – создан
• 1 – доставлен 
• 2 – в обработке 
• 3 – обработан 
• 9 – обработан с ошибкой

Пример

NML950………0

, где NML — тип пакета, 950 – это длина строки, в которой содержатся метаданные «пакета», а остальные символы — это «наполнители».

Примечание: Длина строки должна равняться 16 символам.

Читать далее «Пакет для передачи данных»

Для автоматической генерации интерфейса ExtJS требуется придерживаться следующих правил:

1. Для каждой таблицы/представления/функции должен быть создан комментарий — указать наименование (описание).
2. Для колонок так же должен быть указан комментарий — это краткое описание колонки. Колонка так же поддерживает несколько дополнительных параметров, которые указываются в комментариях. Для этого перед комментарием указываем «[]» и внутри пишем параметры. Разделителем параметров выступает символ «|». Список параметров:
   • e100 — параметр сортировки, чем больше число тем выше будет выведено поле.
   • d — поле выводиться по умолчанию в выпадающем списке. В рамках одной таблице должно встречаться, только один раз.

Примеры

• id: integer — [e100] идентификатор
• c_name: text — [e90|d] наименование

Для хранения настроек применяется таблица cd_settings, которая хранит информацию, как ключ-значение.

Правило именования

1. Имена настроек должны содержать только латинские символы и числа. В качестве разделителя должен применяться символ «_» (нижнее подчеркивание).
2. Для разных категорий настройке должен быть свой префикс.
   • ALL_ — общая
   • DB_ — база данных
   • SRV_ — сервис
   • UI_ — пользовательский интерфейс
   • MBL_ — мобильное приложение
3. Для указания региона, к которому должна применять настройка, доступно поле f_maindivision в котором требуется указать null, если требуется чтобы настройка применялась для всех. Либо выбрать конкретный регион.
4. Для указания, что настройка должна быть привязана только к определенному пользователю требуется заполнить поле f_user.