Добрый день!

Прочитал очень хорошую статью про управляемые формы "Под капотом управляемых форм":
https://infostart.ru/1c/articles/198766/

Управляемые формы - это по сути веб-приложение. Верно?

Меня заинтересовал "теоретический" вопрос.
Хочется лучше понять и разобраться с "внутренней" структурой (архитектурой), на основе которой построено это 1С-веб-приложение (управляемая форма).
На какой веб-архитектуре реализована работа управляемых форм?

В статье "Современные архитектуры фронт-энда" есть вот такая картинка:
https://habr.com/ru/articles/500072/

Является ли эта картинка правильной схемой, которая правильно отображает работу управляемой формы?
Если нет, то какая схема будет более правильная?

Теории УФ нет и не будет. И слава 1С за это.
Вон, та вон картинка - это пример предельного маразма мудрецов из башни Слоновой кости. Абсолютно правильная и абсолютно бесполезное.

Поймите - ИТ, как и математика - это не наука, это инструмент и ремесло, оно почти не нуждается в теории. В отличии от физики,которая большую осознанную свою жизнь проводит в теории.

(1) > В отличии от физики,которая большую осознанную свою жизнь проводит в теории.

Это ты сейчас о людях, которые выдумали темную материю и темную энергию, только потому что реальность в их теорию не укладывается?

"только потому что реальность в их теорию не укладывается" тем хуже для реальности... теперь физики будут ломать голову, как подогнать реальность под теорию.
Математика - вот пример чистой и незамутненной теории. Всю математику можно вывести из двух вопросов - сколько у меня на руках и ногах пальцев (теория чисел и все с ней связанное)? и сколько бананов составляет кучу (теория множеств, колец и тому подобное)?

(1) >> Теории УФ нет и не будет

Не придирайся к словам. Давай назовем это не "теорией".
Интересует "внутренняя" архитектура управляемой формы. В чем ее отличие\сходство от веб-архитектуры?

Так как архитектура удобнее воспринимается в виде схем, то хотелось бы увидеть такую схему, которая отображает "внутренности" управляемой формы: составные части, их взаимосвязи и взаимодействие.

>> Вон, та вон картинка - это пример предельного маразма...
>> ... Абсолютно правильная и абсолютно бесполезное.

Почему картинка - это маразм?
Конструкция, например, ракеты содержит тысячи чертежей. По другому никак. Разве это маразм?
Картинки\схемы\чертежи - это очень эффективный способ передачи информации об "устройстве" чего-либо.
И поэтому такие картинки имеют огромную пользу.

(1) осуждаю

(5) как я вижу, он имеет в виду, что если вы узнаете, что унутре у ней xml, или html, или javascript - вам в разработке это никак не поможет, потому что вас все равно никто не подпустит к этим кишкам. Они закрыты от разработчика. Поэтому нет смысла забивать этим голову, ее с УФ и без этого есть чем позабивать, одного растаскивания по клиент-серверу хватит...

(0) фиддлер вроде ловит данные к/с взаимодействия

(7) >> ... если вы узнаете, что унутре у ней xml, или html, или javascript ...

Нет-нет, меня не интересуют очень низкие технические детали реализации.
Меня интересует "внутреннее" разделение УФ на части и связи между ними.

Похоже ли "внутренне" устройство клиентской части УФ на фронт-енд?
Похоже ли "внутренне" устройство серверной части УФ на бэк-енд?
Как фронт-енд УФ взаимодействует с бэк-енд-ом? Интересует схема, а не технические детали.

>> ... нет смысла забивать этим голову, ее с УФ и без этого есть чем позабивать, одного растаскивания по клиент-серверу хватит...

Вот мне кажется, что понимание внутреннего устройства поможет в правильном разделении кода на клиент-сервер.
Это как с автомобилем. Пока вы автомобилем пользуетесь чисто как автолюбитель-шофер, то вы не сможете ничего в нем отремонтировать, даже мелкий ремонт типа предохранитель заменить.
А если вы хотите уметь что-то самостоятельно с автомобилем делать, хотя бы масло поменять, то вы должны разобраться: какое масло, куда и сколько заливать. Это уже более глубокое знание автомобиля. Но не настолько глубокое, чтобы делать серьезный ремонт.

(9) "Вот мне кажется, что понимание внутреннего устройства поможет в правильном разделении кода на клиент-сервер." Здесь иная логика. Сервер не знает, какого цвета кнопочка на форме. Форма понятия не имеет, об объектах базы данных. Это единственная 100% истина,  и от нее и надо плясать.

(9) https://infostart.ru/1c/articles/682305/ - вот довольно неплохая статья, которую вместе с "под капотом управляемых форм" полезно было почитать.

(10) >> Сервер не знает, какого цвета кнопочка на форме. Форма понятия не имеет, об объектах базы данных.

Это все понятно. Это базовые принципы разделения кода.
Я хочу узнать чуть подробнее как реализовано это разделение.

(11) >> https://infostart.ru/1c/articles/682305/ - вот довольно неплохая статья

Я читал эту статью.
Там описывается клиент-серверное взаимодействие на "высоком уровне".

Кроме этого, меня интересует еще и "внутреннее" устройство управляемой формы, то есть более подробное взаимодействие на более низком уровне.
Например, в этой статье никак не отражен тот факт, что форма присутствует и на стороне клиента и на стороне сервера.
Хотелось бы увидеть описание\схему, которая подробнее раскрывает взаимодействие этих двух "частей" управляемой формы, а также другие подробности.

(13) типа сериализации данных между клиентом и сервером ( состояний )?

(14) >> типа сериализации данных между клиентом и сервером ( состояний )?

Нет. Технический способ передачи данных - это тоже низкоуровневая реализация, которая не так важна.

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

(0) Вот тут кое-что написано https://habr.com/ru/companies/1c/articles/315414/
https://habr.com/ru/companies/1c/articles/778986/

И вообще, про внутреннюю кухню платформы кое-что можно почитать тут https://habr.com/ru/users/PeterG/publications/articles/

Ещё кое-что одинесовцы рассказывали на своих девконах. Лень искать

(16),(17) Спасибо.
Это близко к тому, что я спрашивал. Правда там в общем про всю "архитектуру" платформы.

Попробую поискать, может быть среди статей PeterG есть что-то конкретно об УФ. --- Нет, про УФ нету статей :(

(0)Интересно конкретное название компонент и модулей, используемых 1с для построения данного решения? Такое вряд ли можно найти в общем доступе, если  только на уровне слухов и личного опыта) Можно предполагать, что используется некий движок, на основе условной xml-схемы, получаемой на вход, строящий визуальную часть.

АУФ = Архитектура Управляемых Форм

символично

(19)
>> Интересно конкретное название компонент и модулей, используемых 1с для построения данного решения?

Да.
Интересно не только "физические" компоненты и модули, но и их организация в "логические" (то есть архитектурные) блоки.
Как пример. Есть шаблон MVC для разделения данных и представления. А использует ли 1С такой шаблон при реализации управляемых форм? Как в управляемых формах разделяются данные и представление?

>> Такое вряд ли можно найти в общем доступе, если  только на уровне слухов и личного опыта)

Ну я надеялся, что есть какое-то описание.

(0) >> Управляемые формы - это по сути веб-приложение. Верно?
- Нет. Это вариант декларативных форм работающих в клиенте(Win, Mac, Linux) и в web. Ушли с привязки к Win интерфейсу(обычные формы).

>> На какой веб-архитектуре реализована работа управляемых форм?
- На своей собственной 1С, закрытая реализация (внутри меняется от версии к версии)

Ваша картинка к 1С не имеет отношение.
Жизненный цикл управляемой формы -
https://infostart.ru/1c/articles/849540/

(23) >> Это вариант декларативных форм работающих в клиенте(Win, Mac, Linux) и в web.

Есть где-нибудь описание схемы\архитектуры как работают декларативные формы?
В чем отличие приниципов работы декларативных форм от веб-приложений?

>> ...  закрытая реализация ...

Интересно глянуть хоть на какой-нибудь вариант какой-нибудь версии.

(24) "Есть где-нибудь описание схемы\архитектуры как работают декларативные формы?"
- Идешь на работу в 1С, подписываете соглашение о неразглашении, ныряешь в Легаси-код ;)
(Я в 1С не работал мне болтать можно...)

"В чем отличие принципов работы декларативных форм от веб-приложений? "
- веб-приложения - приложения работающие на стеке вэб технологий
- декларативные формы как правило сейчас xml формы описывающие интерфейсную часть (В 1С можно увидеть при выгрузке в файлы)

"Интересно глянуть хоть на какой-нибудь вариант какой-нибудь версии."
Статья 272. Неправомерный доступ к компьютерной информации ;)

Если думаешь, что сможешь перехватывать взаимодействие сервера и браузера - могу тебя разочаровать.

(25) не надо разочаровывать, нет никакой технической проблемы посмотреть трафик клиент-сервера, только юридическое.

(24) >>В чем отличие приниципов работы декларативных форм от веб-приложений?
Достаточно почитать (применительно к 1С): https://its.1c.ru/db/metod8dev/content/3616/hdoc
"Т.к. данные формы доступны и на клиенте и на сервере, то основным хранилищем всех данных выступает сервер, просто потому что взаимодействие клиента и сервера инициируется только с клиента. Это означает, что в момент работы в памяти сервера находятся все данные формы, и доступ к ним осуществляется напрямую. На клиенте же имеется в общем случае частичное представление этих данных, при необходимости подгружаемое с сервера. При дальнейшей работе с формой изменения данных могут передаваться туда и/или обратно для синхронизации состояний клиента и сервера."

УФ, грубо говоря, находится на сервере, в этом ключевое отличие. Это не имеет никакого отношения к популярным MVC/MVP-паттернам (в этом смысле тонкий клиент 1С довольно "тонкий"), скорее всего, концепция УФ разрабатывалась с оглядкой на 3-звенные архитектуры начала 2000-х, все эти сервера приложений от Oracle и пр.. Имхо.

(0) Посмотри Vaadin
Фактически это как УФ, только на Java
И все будет понятно с "теорией"

(28)+ Vaadin с 2002 года
В 1С тогда еще только ОФ было

(27) >> Достаточно почитать (применительно к 1С): https://its.1c.ru/db/metod8dev/content/3616/hdoc

Хорошая статья. Спасибо.
Побольше бы таких статей.

>> УФ, грубо говоря, находится на сервере, в этом ключевое отличие.

Точнее - данные УФ находятся на сервере.
И это действительно отличие от веб-приложений. Так как для веб-приложений считается, что сервер должен быть без состояния, то есть не должен хранить данные.

>> Это не имеет никакого отношения к популярным MVC/MVP-паттернам

А вот с этим не согласен.
Наоборот, из описания в статье как раз прослеживается MVC модель. На сервере хранятся данные ("M" - Model), а на клиенте они только отображаются во View: "... На клиенте же имеется ... частичное представление этих данных".
Разве это не MVC?

(28) >> Посмотри Vaadin. Фактически это как УФ, только на Java

Да, похоже.
Нашел в интернете картинку "Архитектура Vaadin".

(30)
УФ это извращенное MVC
Там часть данных могут мигрировать с сервера на клиент (и обратно) через сериализацию
РеквизитФормыВЗначение и ЗначениеВРеквизитФормы