Языки программирования – 17

Бывают ситуации, когда что-то развивается и в какой-то момент уже можно говорить, что возникло какое-то узкое место, затрудняющее дальнейшее развитие. Это вовсе не означает, что писать нельзя. Но это нечто накопленное, которое вышло из состояния «мелкая проблема, которую преодолевают не замечая» и стало тем на что неплохо бы как-то отреагировать.
Здесь было про возможности и проблемы ASP и AJAX:
http://akostina76.ucoz.ru/blog/2016-10-09-3503

Это не делает технологию тем, что нельзя использовать. Это именно усложняет процесс, заставляя думать и вещах, которые хотелось бы переложить на авторов программного инструментария.
(Про варианты решения некоторых проблем силами Интернета писать не буду. Может позже, но точно не сейчас.)
Вторая проблема, которая периодически возникает и требует серьёзного к себе отношения – разные виды и даже версии браузеров (IE, Chrome, FireFox, Opera и т.д.). Теоретически язык HTML один и всё у всех должно работать одинаково. Практически браузеры ведут себя по разному, т. е по разному интерпретируют полученные тексты и отрабатывают скрипты. Отличия малы, но их достаточно чтобы требовалась не одна отладка как обычно а как минимум 4 в разных браузерах если говорить о реальном качестве.
Ещё одна проблема, хотя скорее неприятная чем такая уж страшная. Страницу HTML принято прокручивать вверх вниз. При этом верх страницы полностью невидим. Это удобно для Интернета но не для таблицы с данными, у которой вверху находятся названия колонок, которые желательно видеть всегда. Их и видно всегда в форме в Windows которая окно, а не страница. Это решаемо но это чуждо всей идеологии HTML потому во-первых страшно в виде того, что для этого надо писать, во-вторых, есть все основания ждать, что в следующей версии чего-нибудь эта возможность пропадёт и функция перестанет работать. Особенности AJAX делают таблицы, не помещающиеся на страницу тем, чего быть просто не должно при вводе информации. Но ведь есть и длинные бумажки, которые можно вывести для просмотра и там эта проблема остаётся.
Следующее и всерьёз неприятное – очень трудоёмкие отчёты, предназначенные для печати а не просмотра. Тут я писала про то, как развивался инструментарий для опытного пользователя:
http://akostina76.ucoz.ru/blog/2016-10-15-3515

… и что является нормальным уровнем возможностей, которые должны быть предоставлены. Всё, конечно, сложнее. Не всякая программа даёт такие возможности, да и не везде они нужны. Но если клиентское решение для работы с базой данных в локальной сети это всё позволяет то понятно, что чем бы ни было вызвано ограничение при работе в Интернете это будет законным поводом кривить морду. Отчёты 1С – не единичный пример. В тексте я как раз пыталась показать, что это общее направление движения у всех, т.е то, что пытаются реализовывать все более или менее удачно. А в Интернете я делаю бумажки для печати примерно также как это делалось во времена DOS-а, т.е тут даже конструкторов отчётов как в обычных оболочках-языках нет. Но здесь не DOS с всё тем же текстовым режимом. Здесь Windows со всеми разными шрифтами, разными по ширине буквами и прочим. Т.е это даже хуже чем в DOS-е.
Я отчасти придираюсь, потому что хочу программную разбивку на страницы. Вообще-то, браузер способен засунуть документ в принтер и даже расставить номера страниц. Но во-первых, это халтура, во-вторых не только я знаю, что это халтура. Есть всё тот же нормальный уровень качества к которому приучен человек работающий в с базами в локальных сетях через клиентские приложения.
Я нарисовала штуку, точнее свой собственный объект для печати отчётов:

Это ещё один хороший пример ситуации, в которой нужен свой собственный написанный объект. Во внутренних переменных тут сохранены всевозможные высоты букв разных шрифтов (в пикселях) и прочая информация, которую надо один раз выяснить, «спрятать» во внутренние функции и больше никогда не видеть.
Вот тут он как-то определяет высоту строки таблицы с рамкой или без (и пусть определяет):

При использовании это примерно так:

… Т.е после with имя объекта печати. И всё, что начинается с «.» - обращение к свойствам или методам этого объекта. Дальше там всё очень страшно потому, что нормальный отчёт обычно содержит кучу промежуточных итогов которым логично находится на той же странице где и основанная информация. Тот самый привычный конструктор отчётов в любой среде Windows занимался расположением данных на страницах сам.
Здесь же приходится вручную по данным очередной строки отлавливать своеобразное событие:

… и уже по нему как-то что-то выводить в рисуемый отчёт:

И то не всегда получается правильно «угадывать» потому на форму со списком отчётов вытащена высота страницы:

… которой можно поиграть если вид полученной бумажки не устраивает. Тут, кстати видно какой смысл заводить внутренние переменные объекта а не подбирать и вставлять какие-то константы. Какая, когда всё уже отлажено, разница цифрой задаётся высота букв шрифта 8pt или переменной? Но когда есть внутренняя переменная, то можно легко и быстро поменять всю работу объекта, поменяв её значение. Тут меняется высота страницы, которая для всех листов формата A4 вроде бы одинакова. Но компьютеру все равно какую цифру учитывать при обсчете того когда надо переходить на следующую страницу. Потому можно получить чуть другое расположение заставив его думать, что страница, например на 10% короче и печатать следующую надо раньше.
Но всё это как-то криво, трудоёмко и неудобно. А в тот момент когда всё это было осознано 1С как раз выпустил версию, которой уже можно пользоваться. До этого меня останавливало то, что он работал со своим форматом данных как-то записываемых в DBF. Этот недостаток перевешивал вообще любые возможные достоинства. Раз эта проблема снята имеет смысл отдельно поговорить о вопросах качества программного продукта, который можно сделать с помощью конкретного инструмента.
Но вначале интересное. Про стандартную форму с среде  Windows тут:
http://akostina76.ucoz.ru/blog/2016-09-30-3477

… т.е это нечто с кнопками. Кнопки можно перетаскивать мышью. Хранится описание формы в отдельном текстовом файле со своей структурой.
В программах для Интернета роль этого файла с объектами на экране/странице стала выполнять ASP надстройка над HTML форматом. При этом расположение, как это и принято в HTML определялось таблицами с видимыми или невидимыми рамками. Т.е чтобы кнопка была точно над тестом надо завести невидимую таблицу, отцентровать строки и засунуть в первую строку кнопку а во вторю текст.
Возможность просматривать то, как это будет выглядеть уже на стадии программирования есть… но лично я этим не пользовалась. По-моему там нет возможности что-то корректировать. Я просто меняла тексты в виде тексов, а не таскала объекты мышью.
1Совцы в формах, ориентированных на возможность работы в Интернете это сделали так:

Раз уж таблицы для форматирования в Интернете всё равно не таблицы (а только использованный инструмент), то никакой HTML-похожей текстовой структуры у них нет. То, что в ASP делается тэгами таблиц тут делается древовидной структурой слева сверху. Структура показывает вложения элементов. Раз мне надо на форме несколько вкладок, первое что у меня определяет структуру формы – группа «Страницы». В эту группу вложены уже отдельные страницы (В HTML было бы аналогичное вложение таблиц). Под страницей «Основная» уже несколько групп, например «Группа1», в которой находится несколько текстов. Всё вместе – форма на экране такая как будет при выполнении. Таскать кнопки и всё остальное мышью прямо на форму нельзя. Их надо таскать в «дерево» в левом верхнем углу. Но именно таскать мышью, а не вводить что-то руками. Т.е это удобно хотя непривычно.
Есть ещё две вещи, которые меня очень серьёзно интересовали: как тут работает выбор из списка и ввод информации в следующую строку.
Дело в том, что качество и того и другого ухудшилось в Windows по сравнению в DOS-ом. Утверждение немного смелое потому уточню, что я имею в виду. Windows ориентирован на работу мышью, а сплошной ввод информации лучше осуществлять вообще не трогая мышь, только вбивая что-то на клавиатуре. Так просто намного быстрее. Интернет и даже сеть могут сделать скорость ввода информации менее существенным фактором. Например, пользователь Банк-Клиента сам вводит свои платёжные поручения, а сотрудник банка только что-то проверяет и отправляет дальше. Ему не надо с дикой скоростью вбивать пачку принесённых бумажек. Но есть места где такие вещи всё-таки существенны. Удобно когда по Enter курсор переводится на следующий элемент, в котором должна быть введена информация. Удобно, когда выбор из списка можно открыть не мышью а сочетанием Alt+СтрелкаВниз. Удобно, когда ввод следующей строки документа (после только что введённой) начинается на нажатию Enter на последнем элементе. Альтернатива – щелчок мышью по кнопке «Новая строка». Это доля секунды но это существенно когда в документе сотня строк и всех их кто-то должен ввести.
К сожалению я видела одну программу, полностью ориентированную на мышь. Формально это не считается браком. Там была возможность ввести всю информацию, но мышью надо было открывать список, мышью же листать и выбирать нужный элемент. Наверное это было не сложно когда в списке было 5 строк  Там не было поиска и сортировка была какая-то неудобная. И так работали все списки. Как результат минут 5 занимал ввод документа который должен был занимать секунд 30.
Стандартные таблицы данных – тоже проблема. Чьё-то творчество лучше ни использовать потому, что по нему через 5 лет информации не найти, а стандартные GRID типа этой:
http://www.andreavb.com/forum/viewtopic_7882.html

… так и остались ориентированными на вывод списка с возможностью его листать но не корректировать. Причина всё та же – в клиент-серверных приложениях настойчиво рекомендовалось работать с одной записью. 
Потому мне и было интересно как это всё работает в 1С. Не вдаваясь в подробности – хорошо работает. Не совсем так как это принято в стандарте а пожалуй даже лучше (я примерно такое сооружала сама потому что без этого неудобно).