LSS Техническая документация

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
====== Техническое задание на разработку ======
===== Техническое задание на разработку LSS протокола =====
Разработать LSS протокол для обмена данными и управляющими командами между LSS визуализатором, размещенном на клиенте и слоем бизнес логики, размещенном на сервере. 
==== Общие требования к LSS протоколу ====
Протокол должен удовлетворять следующим требованиям:
  * Использовать в качестве транспортного слоя HTTP и/или HTTPS.
  * Использовать XML представление.
  * Использовать кодировку UTF-8.
  * Протокол должен быть независим от деталей реализации как LSS визуализатора, так и от деталей реализации слоя бизнес логики.
  * Протокол должен быть нагляден и понятен человеку (программисту, разработчику, тестировщику), даже если эта наглядность приведет к потерям в производительности компьютера.
  * Протокол должен опираться на паттерн REST.
  * Протокол должен опираться на паттерн MVC.
  * Протокол должен поддерживать защиту от CRF атак посредством использования CRF ключа.
  * Должен быть разработан унифицированный LSS формат данных для единообразного и независимого от особенностей площадок представления данных.

==== Требования к запросам ====
Запрос это то, что LSS визуализатор направляет слою бизнес логики, размещенному на сервере.
  * Запросы должны иметь простую, унифицированную структуру:
    * заголовок запроса, содержащий основное описание требуемых действий.
    * параметры запроса, позволяющие передать на сервер дополнительную информацию, требуемую выполнения запроса.
  * Необходимо разработать запросы для реализации аутентификации в системе.
  * Необходимо разработать запросы для получения визуализатором декларативных описаний наборов строк и экранных форм.
  * Необходимо разработать запросы для чтения и правки данных наборами строк.
  * Необходимо разработать служебные запросы, обрабатываемы на клиенте и не отсылаемые на сервер, например запрос на закрытие активной экранной формы.
==== Требования к ответам ====
Ответ это то, что слой бизнес логики отправляет LSS визуализатору в качестве результата запроса.
  * Необходимо разработать ответ, содержащий декларативное описание экранной формы. Это описание должно состоять из следующих разделов:
    * Раздел иерархического описания наборов строк, задействованных в экранной форме.
    * Раздел описания запросов уровня экранной формы, представляющие собой именованные цепочки последовательно выполняемых запросов.
    * Раздел описания внешнего вида экранной формы, представляющий собой вложенную иерархию панелей, связанных с соответствующими наборами строк и предназначенными для отображения их содержимого.
  * Необходимо разработать ответ, содержащий декларативное описание табличного набора строк. Это описание должно состоять из следующих разделов:
    * Раздел описания полей набора строк.
    * Раздел описания поддерживаемых набором строк запросов.
  * Необходимо разработать ответ, содержащий декларативное описание древовидного набора строк. Это описание должно быть устроено следующим образом:
    * Строки древовидного набора строк должны различаться по типам.
    * Для каждого типа строк описание должно быть устроено аналогично описанию табличного набора строк: описание полей и описание запросов.
  * Необходимо разработать ответ, содержащий данные - результаты выполнения запроса:
    * Необходимо разработать вариант ответа, содержащий данные, уже сохраненные в базе и позволяющий передать в визуализатор текущее актуальное состояние данных в базе на сервере.
    * Необходимо разработать вариант ответа, содержащий данные, еще не сохраненные в базе, которые будут отображены визуализатором и сохранены только при очередном сохранении текущей строки.
    * Необходимо разработать вариант ответа, содержащий сведения об удаленных в результате выполнения запроса строках.
  * Необходимо разработать ответ, описывающий неуспешность выполнения запроса.
  * Необходимо разработать ответ, описывающий необходимость выполнить экранной формой или набором строк определенный запрос с заданными значениями параметров запроса.
==== Требования к формату представления данных ====
LSS протокол должен быть реализован посредством XML описания. Данные в нем должны описываться в виде строк. Нужно унифицированное описание строкового представления для всех используемых типов данных.
  * Разработать список допустимых в протоколе типов данных.
  * Разработать унифицированный формат представления числовых данных.
  * Разработать унифицированный формат представления дат.
===== Техническое задание на разработку LSS визуализатора =====
==== Общие требования ====
  * LSS визуализатор должен быть реализован в виде одностраничного сайта, использующего JavaScript и AJAX.
  * Необходимо обеспечить высокую степень совместимости с различными web-браузерами, в том числе с Internet Explorer, браузерами на основе Chromium и FireFox.
  * В качестве библиотеки построения экранных элементов необходимо использовать Dojo Toolkit (лицензия BSD).
  * В качестве сторонних графических элементов дизайна необходимо использовать ресурсы сайта icons8.ru
==== Требования к модулю взаимодействия с сервером по AJAX ====
  * Все взаимодействие по с сервером по LSS протоколу должно происходить через единый модуль, обеспечивающий это взаимодействие посредством AJAX.
  * Должна быть реализована удобная технология логирования LSS запросов к серверу и ответов на них сервера.
  * Запросы должны делиться на 
    * синхронные, с принудительным ожиданием ответа
    * асинхронные, не блокирующие работу визуализатора до получения ответа
  * модуль взаимодействия должен анализировать ответы и направлять их для последующей обработки в соответствующую экранную форму или набор строк.
  * модуль взаимодействия должен реализовать механизм отправки на сервер выбранных пользователем файлов и скачивания файлов с сервера.
==== Требования к модулю табличного набора строк ====
  * Набор строк должен обеспечить работу с данными согласно LSS протоколу.
  * Все строки в наборе строк должны иметь уникальный id
  * Необходимо реализовать несколько стратегий формирования уникального id строки:
    * При создании пустой строки, до ее сохранения в базе данных - как результат запроса append
    * При первом сохранении строки в базе данных - как результат первого save, при этом до сохранения у строки значение id временное, которое меняется после сохранение на постоянное
  * Набор строк должен обеспечить построение списка полей и списка допустимых запросов по декларативному XML описанию набора строк.
  * Набор строк должен обеспечить хранение данных в виде упорядоченной таблицы, с удобным поиском по уникальному ключу, нахождением первой, последней, следующей и предыдущей строки.
  * Набор строк должен обеспечить оповещение визуальных элементов экранной формы о необходимости перерисовки при изменении своего содержимого. При этом следует разделять изменения только в полях текущей строки и изменения, затрагивающие и другие строки.
  * Набор строк должен обеспечивать выполнение запросов посредством отправки запросов на сервер через единый модуль взаимодействия и обеспечения приема и обработки ответов.
  * Набор строк должен обеспечить возможность постраничной работы с данными.
  * Набор строк должен обеспечить автоматический вызов сохранения накопившихся изменений при смене текущей строки или при передаче фокуса на другой набор строк.
  * Набор строк должен обеспечить автоматическую перечитку подчиненных наборов строк при смене текущей строки.
  * Должна быть реализована возможность работы набора строк в качестве фильтра:
    * У такого набора строк должна быть одна и только одна строка. Соответственно, недопустимы операции добавления и удаления строк.
    * Подчиненные наборы строк автоматически перечитываются при смене значения любого поля.
  * Набор строк должен обеспечить работу механизма пометок строк - хранение списка помеченных строк, возможность отправки этого списка на сервер, возможность корректировки этого списка посредством поступивших ответов от сервера.
  * Набор строк должен обеспечивать контроль доступности правки в зависимости от признаков readonly, на уровне всего набора строк, строки и поля.
==== Требования к модулю древовидного набора строк ====
  * Древовидный набор строк должен быть сделан на основе табличного.
  * Он должен обеспечивать работу с разными типами строк.
  * Для каждого типа строк свой набор полей и свой набор допустимых запросов.
  * Должна быть обеспечена возможность хранения данных в виде дерева.
  * Должна быть обеспечена навигация по древовидным данным.
  * Предполагается уникальность id среди дочерних строк одного родительского узла.
 
==== Требование к модулю визуальных панелей ====

Необходимо разработать панели следующих типов:
  * Необходимо разработать панель, обеспечивающую отображение и правку данных в виде таблицы
  * Необходимо разработать панель, обеспечивающую отображение и правку данных в виде полей текущей строки набора строк
  * Необходимо разработать панель, обеспечивающую отображение дерева из древовидного набора строк
  * Необходимо разработать панель, обеспечивающую отображение произвольного HTML содержимого по адресу
  * Необходимо разработать панели, обеспечивающие размещение внутри себя других панелей
    * панель TAB размещающая другие панели в виде закладок.
    * панель SCROLL обеспечивающая последовательное вертикальное размещение дочерних панелей с возможностью прокрутки при необходимости.
    * панель PANEL обеспечивающая размещение дочерних панелей слева, справа, снизу, сверху и по середине
  * Необходимо разработать панель FORM обеспечивающую размещение внутри себя экранной формы

Панели должны обеспечивать:
  * Панели должны быть привязаны к набору строк и отображать его содержимое.
  * Панели должны обеспечивать перерисовку содержимого при получении соответствующего оповещения от набора строк.
  * Необходимо разработать механизм, позволяющий разрабатывать и регистрировать в системе новые типы панелей, делая тем самым их доступными для использования в визуализаторе.
  * Панели должны уметь автоматически рассчитывать свои размеры по своему содержимому.
  * Необходимо разработать механизм изменения видимости панели по условию, задаваемому предикатом.
  * Необходимо разработать механизм цветовых схем, позволяющий изменять цветовые решения дизайна панелей.
  * Необходимо разработать механизм размещения на панелях управляющих кнопок, позволяющих запускать выполнение запросов.
  * В рамках экранной формы только одна панель должна быть текущей. На нее направляется ввод с клавиатуры. Связанный с ней набор строк считается текущим, при смене текущего набора строк несохраненные изменения в нем должны отписываться на сервер посредством вызова запроса save.

==== Требование к модулю экранных форм ====
  * Модуль экранных форм должен обеспечить построение экранной формы по декларативному описанию согласно LSS протоколу:
    * Обеспечить построение описанных в экранной форме наборов строк.
    * Обеспечить построение описанных в экранной форме визуальных панелей.
    * Сформировать список именованных запросов уровня формы.
    * обеспечить построение наборов строк справочников, на основании описания полей, требующих для своей работы начитки данных из справочников.
  * Модуль экранных форм должен обеспечить вызов именованных цепочек запросов уровня формы.
  * Модуль экранных форм должен обеспечить перерисовку панелей по оповещениям, поступающим от источников данных.
  * Модуль экранных форм должен обеспечить механизм переключения от одной экранной формы к другой и механизм закрытия экранной формы.
  * Модуль экранных форм должен обеспечить механизм смены фокуса ввода между визуальными панелями.


==== Требование к модулю виджетов для разных типов полей ====
Необходимо разработать следующие виджеты для отображения и редактирования полей:
  * Поле для отображения и редактирования строк.
  * Поле для отображения и редактирования дат с выпадающим диалогом календаря.
  * Поле для отображения и редактирования чисел.
  * Поле многострочного редактора.
  * Поле выбора из справочника.
  * Поле выбора из фиксированного списка значений.
  * Поле галочки.
  * Поле радио-группы.
  * Поле отображения иконки по имени иконки.
  * Поле справочника множественного выбора.

Виджеты полей должны обеспечивать:
  * Автоматическую синхронизацию в обе стороны со значениями полей набора строк.
  * Удобное управление с помощью клавиатуры без использования мыши.
  * Автоматический расчет высоты многострочных элементов.
===== Техническое задание на разработку LSS сервера =====
==== Общие требования ====
  * LSS сервер должен работать по HTTP и/или HTTPS.
  * LSS сервер должен обеспечивать корректную обработку LSS запросов.
  * LSS сервер должен обеспечивать работу с SQL серверами PostgreSql, MySql, MSSQL.
  * LSS сервер должен работать на основе паттерна REST.
  * Необходимо использовать язык программирования PHP, не ниже 7.
  * В качестве основного web-сервера следует использовать Apache.
  * LSS сервер должен быть кроссплатформенным - работать как под Windows так и под Linux.
  * LSS сервер должен быть явно разделен на:
    * Общие для всех прикладных проектов библиотечные элементы.
    * Элементы, уникальные для каждого прикладного проекта.
==== Требования к контроллерам источников данных ====
Контроллер источника данных это экземпляр класса, обеспечивающий обработку LSS запросов к данным. Обычно источник данных соответствует таблице SQL сервера.
  * Необходимо реализовать механизм, позволяющий по имени источника данных найти и загрузить в память соответствующий контроллер источника данных.
  * Необходимо реализовать механизм описания в виде массива списка полей источника данных.
  * Необходимо реализовать механизм описания в виде массива списка поддерживаемых источником данных запросов.
  * Необходимо реализовать механизм прав, проверяющий доступность выполнения источником данных запроса для текущего пользователя.
  * Необходимо реализовать формирование контроллером источника данных декларативного описания согласно LSS протоколу, на основе описателей полей и описателей поддерживаемых запросов.
  * Необходимо реализовать механизм формирования SQL запроса SELECT для источника данных.
  * Необходимо настроить механизм фильтров - дополнительных условий в секции WHERE запроса SELECT на основе переданных в запросе к источнику данных значений параметров фильтра.
  * Необходимо реализовать механизм формирования SQL запросов INSERT, UPDATE, DELETE для правки источника данных, на основе описателей полей и переданных в запросе параметров.
  * Необходимо реализовать механизм выполнения адресованных источнику данных запросов и получения результатов в виде массива строк - для удобного использования источников данных на стороне сервера при обработке промежуточных результатов
  * Необходимо реализовать механизм преобразования массива строк, являющегося результатом выполнения запроса, в XML согласно LSS протоколу.

  * Необходимо реализовать механизм, позволяющий описывать структуру базы данных в виде описателей, по этим описателям автоматически строить контроллеры источников данных базовой функциональности. 
  * Необходимо наладить механизм внесения изменения в автоматически сформированные контроллеры источников данных. Нужна возможность
==== Требования к контроллерам экранных форм ====
Контроллер экранной формы это экземпляр класса обеспечивающий обработку LSS запросов адресованных к экранной форме.
  * Необходимо реализовать механизм, позволяющий по имени экранной формы найти и загрузить в память соответствующий контроллер экранной формы.
  * Контроллер экранной формы должен обеспечивать формирование декларативного описания экранной формы в формате LSS протокола, с учетом переданных в соответствующем запросе значений параметров.
  * Необходимо реализовать механизм получения декларативного описания экранной формы из соответствующего XML файла шаблона.
  * Необходимо реализовать механизм обработки запросов, адресованных контроллеру экранной формы.
  * Необходимо реализовать возможность дополнительной обработки запросов, адресованных источникам данных, размещенным в экранной форме.

==== Требования к контроллерам отчетов ====
Контроллер отчета это экземпляр класса, обеспечивающий анализ входных параметров и формирование соответствующего отчета.
  * Необходимо реализовать механизм, позволяющий по имени отчета найти и загрузить в память соответствующий контроллер отчета.
  * Необходимо реализовать интерфейс разбора передаваемых через url входных параметров.
  * Контроллер отчетов должен уметь формировать отчет в виде HTML для отображения на экране.
  * Контроллер отчетов должен уметь формировать отчет в виде MS Excel и MS Word. Допустимым является вариант формирования HTML, который корректно воспринимается и отображается в Excel и Word.
==== Требования к контроллерам утилит ====
Контроллер утилиты это экземпляр класса, обеспечивающий анализ входных параметров и вызов соответствующей утилиты. Утилита это длительная операция, позволяющая отображать процесс своей работы в виде отображаемого на экране лога.
  * Необходимо реализовать механизм, позволяющий по имени утилиты найти и загрузить в память соответствующий контроллер утилиты.
  * Необходимо спроектировать интерфейс разбора передаваемых через url входных параметров.
  * Необходимо реализовать механизм логирования процесса работы утилиты посредством поэтапной передачи HTML лога для отображения клиентским приложением.
  * Необходимо спроектировать интерфейс выполнения операции утилиты для удобного наполнения его нужной функциональностью при разработке конкретной реализации утилиты.

==== Требования к контроллерам сервисов ====
Контроллер сервиса это экземпляр класса, обеспечивающий анализ входных параметров и вызов соответствующего сервиса. Сервис это произвольный серверный код взаимодействующий с клиентом по HTTP и/или HTTPS используя паттерн REST.
  * Необходимо реализовать механизм, позволяющий по имени сервиса найти и загрузить в память соответствующий контроллер сервиса.
  * Необходимо спроектировать интерфейс разбора передаваемых через url входных параметров.
  * Необходимо спроектировать интерфейс выполнения сервиса для удобного наполнения его нужной функциональностью при разработке конкретной реализации.

==== Требования к точкам входа ====
Точки входа это PHP скрипты, к которым можно непосредственно обращаться из клиентского приложения.
  * Весь PHP код, не являющийся точкой входа, должен быть размещен так, что бы к нему нельзя было непосредственно обратиться из клиентского приложения.
  * Точка входа должна быть организована по принципу подключения и вызова стандартного общего библиотечного элемента, не зависящего от реализации конкретного прикладного приложения.
  * Необходимо реализовать точку входа для обработки запросов LSS протокола.
  * Необходимо реализовать точку входа для формирования отчетов.
  * Необходимо реализовать точку входа для выполнения утилит.
  * Необходимо реализовать точку входа для вызова сервисов.

==== Требования к ресурсам ====
Ресурсы это статичные файлы, непосредственно доступные по HTTP и/или HTTPS.
  * В ресурсах должны размещаться файлы, необходимые для развертывания LSS визуализатора.
  * В ресурсах должны размещаться необходимые JavaScript и CSS библиотеки, например bootstrap/
  * В ресурсах должны размещаться необходимые для работы приложения иконки.
  * В ресурсах должны размещаться CSS стили необходимые для отображения отчетов и утилит.
==== Требования к описанию главного меню системы ====
Описатель главного меню системы должен представлять собой XML файл с древовидным описанием наименований пунктов меню и вызываемым по ним экранным формам.
==== Требования к контроллеру прав ====
Контроллер прав это экземпляр класса, обеспечивающий проверку доступности запрашиваемых возможностей для текущего пользователя с учетом его прав.
  * Контроллер прав необходимо разработать в виде абстрактного класса, с соответствующими интерфейсами, так, что бы в процессе разработки конкретного прикладного проекта можно было бы породить потомок от этого класса и реализовать в нем систему прав согласно требованиям этого проекта.
  * Контроллер прав должен обеспечивать интерфейс аутентификацию пользователя, по умолчанию предполагается схема сохранения сведений о пользователе и его правах в сессии.
  * Контроллер прав должен обеспечивать интерфейс проверки доступности запрашиваемого действия для текущего пользователя. Действие задается 2-мя идентификаторами:
    * permmode - группирует доступные ресурсы проекта с точки зрения прав
    * permoper - операция в контексте permmode, например read или write
  * Необходимо связать контроллеры источников данных с контроллером прав посредством группировки таблиц по permmode и связывания запросов с permoper.
  * Необходимо связать описатель главного меню системы с контроллером прав посредством назначения пунктам меню соответствующих permmode и permoper.
  * Необходимо обеспечить проверку доступности по правам в контроллерах экранных форм, отчетов, утилит и сервисов.