====== Основные идеи ======
[[start:|lss]]

===== Кроссплатформенность =====
Можно накладывать жесткие требования на платформу сервера, но клиентские платформы должны поддерживаться любые, чем шире охват, тем лучше.

Остановимся на связке **HTML** и **JavaScript**. Им присуще множество недостатков, но зато от этой связки можно добиться работы на любой платформе, будем считать это главным. Чтобы не писать все с нуля, будем использовать свободную библиотеку **DOJO**, она распространяется по лицензии **BSD**, нам это подходит.

===== Прикладной программный код хранится на сервере =====
Удобнее вносить изменения в программный код, если он весь расположен в одном месте - на сервере. А на клиенте - стандартное системное программное обеспечение, не требующие специального администрирования и поддержки. Технология **HTML** под WEB браузером в этом смысле очень удобна.
===== Комфорт для разработчиков конечного продукта =====
Прикладной программист должен хорошо разбираться в автоматизируемой им предметной области. И не должен чрезмерно отвлекаться на хитрые компьютерные технологии. Чем технологии и используемые протоколы проще и нагляднее, чем их меньше, тем лучше.

У связки **HTML**, **JavaScript**, **AJAX** в этом плане все очень плохо. **HTML DOM** модель развесиста и сильно различается для разных браузеров. Язык **JavaScript** хорош для мелких затычек и плохо подходит для крупных проектов. Текст кода, работающего на клиенте, имеет тенденцию перемешиваться в кашу вместе с кодом, который обрабатывается на сервере.

Мы отказываемся от прикладного программного кода на клиенте. Прикладной программист не должен владеть комплексом технологий, связанных с **HTML**, библиотекой **DOJO** и т.д. На клиенте под WEB браузером работает системная оболочка - **[[Viewer]]**. Она взаимодействует с серверными прикладными скриптами, обмениваясь с ними по **HTTP** **XML документами** в виде запрос - ответ (**[[Protocol]]**). Особое внимание мы уделили **простоте и наглядности этого протокола**.

Настройка клиентской оболочки под требуемую конкретику осуществляется серверными прикладными скриптами посредством декларативных описаний. Использование декларативных описаний вместо программного кода увеличивает наглядность за счет уменьшения гибкости.

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

Совсем игнорировать потерю производительности невозможно, тут мы остановились на следующем компромиссе: на клиенте отрабатывают динамически вычисляемые выражения - предикаты, возвращающие истину/ложь. Они контролируют видимость, доступность для вызова и правки отдельных элементов интерфейса. Аргументы для них - значения полей источников данных. Эти выражения просты, в сложных случаях всегда можно создать дополнительное поле, вычислить его на сервере, передать клиенту и использовать для упрощения динамического выражения. Ничего не надо знать об особенностях реализации клиента, ибо для чтения полей есть специальная функция, а записывать результат никуда не надо. Язык динамических выражений - **JavaScript**, в отрыве от **DOM модели**, для мелких не связанных между собой выражений он удобен.

===== Единые принципы построения UI =====
Экранные интерфейсы надлежит строить из типовых блоков. Описывать экранные интерфейсы следует грубыми мазками, лаконично, без подробностей и ненужных украшений. Такой подход оправдан при разработке больших проектов, состоящих из множества экранных форм. 

Выигрываем в скорости разработки - проигрываем в красоте.

Бывают случаи, когда стандартных элементов не хватает. Тогда надо подключать системного программиста и расширять функциональность **[[Viewer]]**, добавляя в него поддержку требуемого экранного элемента. Все возможности для этого есть: **[[Viewer]]** расширяем, его код задокументирован.

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

===== Актуальные данные лежат на SQL сервере =====
Актуальные данные лежат на **SQL сервере** - с ним надо как можно чаще синхронизировать клиента. Исправления отписывать сразу. Перечиток не бояться. Лучше 10 лишних раз перечитать данные, чем один раз заработать взаимную блокировку и заставить клиента повторно править данные.

Лишние перечитки снижают производительность, зато клиент видит и правит актуальные данные.