... это ГИБКО, “МОБИЛЬНО“ и “ВСЕЯДНО“
Бесконечная гибкость и неограниченная функциональная сложность прикладной программы достижимы, если следовать фундаментальным принципам природы:
- комбинацией экземпляров четырех базисных сущностей мета-модели приложения можно реализовать любую бизнес-логику прикладной задачи.
- комбинацией экземпляров четырех визуальных примитивов можно реализовать бесконечно сложный визуальный интерфейс программы.
Но у прикладной программы есть еще один важный аспект — гибкость использования.
Прикладная программа должна быть равно доступна с любого устройства, настольного или мобильного, независимо от используемой устройством операционной системы. Одновременно, она же должна быть доступна через любой веб-браузер, чтобы ее можно было использовать в том числе и как обычное веб-приложение. И к тому же, при любых вариантах использования прикладная программа должна выглядеть визуально адекватно, независимо от размера и разрешения экрана устройства.
Такая миссия кажется невыполнимой только на первый взгляд.
Независимо от ее назначения, прикладная программа создается с помощью клиентской части платформы, которая для этих целей имеет на борту два визуальных редактора, библиотеки визуальных и интерфейсных компонент, и прочий набор технических средств. Создавать сценарий программы удобно, сидя за большим экраном настольного устройства. Так как серверная и клиентская части платформы существуют как под Windows, так и под Linux, а прикладная программа не содержит программных кодов, то выбор типа операционной системы роли не играет, и может быть даже различным для серверной и клиентской частей. С прочими же операционными системами прикладная программа универсально взаимодействует через веб-интерфейс.
Для этих целей клиентская часть платформы, помимо прочего инструментария, имеет в своем составе относительно простой веб-сервер, и соответственно может быть использована в этом качестве как масштабируемый промежуточный ретранслятор, обслуживающий множество внешних веб-подключений к серверу платформы.
В отличие от веб-программиста, рядовой пользователь за экраном браузера видит всего лишь кликабельную картинку. Эта картинка может быть представлена обычным PNG-рисунком, который дополнен перечнем активных областей на нем (вспомним, самые различные веб-браузеры отображают PNG абсолютно одинаково). При воздействии пользователя на активную область картинки, ее id отправляется через ретранслятор прямиком на на сервер платформы. В ответ сервер возвращает ретранслятору выборку данных + описание формы сценария программы, после чего экранная подсистема клиента выполняет рендеринг и разметку новой PNG-картинки, которая возвращается пользователю в браузер. С учетом того, как сейчас создаются современные веб-формы можно даже ожидать снижения объема трафика.
Для лучшего понимания механики адаптации визуального интерфейса к различным размерам экрана, следует вспомнить, что под управлением платформы пользовательский сценарий прикладной программы образован совокупностью экранных форм представления классов данных. Причем для внутренней подсистемы управления формами сценария характерен двойной полиморфизм интерфейса. Точнее сказать : поли-формизм + полиморфизм. Каждый класс данных потенциально обладает множеством форм своего визуального представления, и каждая его форма полиморфична. То есть, одна и та же форма класса для разных конфигураций сценария может принимать различный внешний вид, включая размер и внутреннюю компоновку. Наличие средств быстрого визуального редактирования WYSIWYG в сочетании с возможностью создавать новые формы простым copy/paste уже существующих, позволяет очень быстро из базовой конфигурации создавать отдельные конфигурации под требуемый размер экрана.
