Скоро грядет EDT, в котором пока отсутствует и не планируется поддержка обычных форм. Основной причиной является закрытость формата обычных форм, т.е. для них не реализована сериализация. Хотелось бы лучше разобраться в причинах и как следствие перспективах.
Очень жду мнения от Орефкова.

Вопрос возник в связи с аналогичной темой партнерской конференции https://partners.v8.1c.ru/forum/t/1547898/m/1547898

А зачем?

как EDT связана с ОФ ?

Потому что если бы 1С сделало их сериализацию, то получились бы управляемые формы.

(0) И не стыдно такие вопросы задавать?
Если "1С не сделало их сериализацию", то как они тогда сохраняются?

Если вопрос почему сериализация делается в закрытый формат, а не в какой-то открытый / человеко-читаемый - то она ведь и для управляемых форм в закрытый формат делается. XML выгрузку специально приделывали. А для ОФ не сделали, потому что с точки зрения исторической перспективы они мертвы.

Сериализация конечно есть, просто она в формат со скобочками.

(2)+ Это такой намек что очень вероятен скорый выход версии платформы 1С уже без поддержки ОФ.

ЗЫ А еще они могут и без "платформы 1С" версию выпустить в будущем, просто наборы библиотек/фреймворков (привязянных к ключам) и компилятор 1С>java|nodejs :))

Обычное приложение хотя уже и не развивается, но поддержка его в платформе остается и думаю еще долго будет оставаться. А потому и прикладные решения на нем еще долго будут жить и даже развиваться. Ну и конечно многим из них предстоит переход на управляемое приложение. Поэтому хотелось бы чтобы реализовало сериализацию обычных форм при выгрузке конфигурации в файлы. Что это даст?

    Станет возможной полная поддержка обычного приложения в EDT, а это необходимо для плавного перевода в EDT конфигураций с обычного приложения на управляемое.
    Станет возможным удобный контроль версий обычных форм в сторонних средствах.
    Станут возможными автоматизированные конверторы структуры (дерева элементов) обычной формы в управляемую. Надеюсь такое сделают в EDT.
    Станет возможным отдельное сравнение диалога и модуля обычной формы (при сравнении и объединении).

(6) Нет смысла, поддержка ОФ уже давно никому не сдалась (в 1С). Все новые решения на УФ принудительно, клиентам у кого счас ОФ просто предложат переход на новые конфиги.

(7) 1С до сих пор выпускает немало конфигураций на обычных формах.

(8) Вынужденно, пока не сделали аналог этих решений.

(4) Не стыдно. И не стыдно думать, что я не знал, что обычные формы хранятся в конфигурации? =)

(9)+ Для некоторых решений и аналога не будут вероятно делать, просто предложат перейти на урезанные решения во фреш и все.

В (0) задавался вопрос скорее о технической стороне. Мой недочет, что я сразу это не обозначил.

(12) В данном случае вопрос не технический а политический )) точнее чисто коммерческий же.

Было бы выгодно - давно сделали.

(7)Статистика есть?Моя говорит об обратном

(14) Моя только о древних решениях (которые часто еще на 77 сидят) потому что "денег нетути".

Из актуальных это переход УТ10.3 > УТ11 пока еще проблеммный но почти-почти оно.

(9) Пока УПП поддерживают будут и поддерживать ОФ.
А УПП как минимум еще 3 года будут поддерживать

(16) Поддержка УПП не означает ее поддержку (как и ОФ в целом) в новых платформах. На старых будут поддерживать и все.

(17) Большое заблуждение.

Ничего, кроме исправления ошибок, в новой платформе для поддержки ОФ делаться не будет. Хотите оставаться на том уровне - оставайтесь, пока денег хватает.

(0) Мое мнение о причинах. До недавнего времени 1С боялась быть "слишком открытой". А вдруг появится конкурирующая платформа с возможностью конвертации в нее и структуры метаданных, и форм, и кода (OneScript таки появился). То есть с возможностью легкого переноса прикладных решений.

(19) УФ в текущей реализации требуют на порядок больше трудозатрат программистов... Банально код больше!

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

вот если бы 1с как-то сделала УФ простыми в разработке, вот тогда народ массово повалил-бы...

(0) Пару лет назад проверял код Стр = ЗначениеВСтрокуВнутр(ОбычнаяФорма); - работало, а ОбычнаяФорма = ЗначениеИзСтрокиВнутр(Стр); - валило платформу с дампом.

(21) Прямо бальзам на душу написал,вот что значит опыт

Что значит сериализация формы ?
Нужен интерфейс сохранения значений элементов формы, а сериализация - особенно с объектами - это маразм - все связи с объектами при записи в файл теряются.

(21) Стало больше возможностей, поэтому больше кода. Если же требуется "_на_порядок_больше_трудозатрат_", то это уже вопрос к квалификации.

(24) Список реквизитов формы и дерево ее элементов

(25) Ради любопытства,А каких стало больше

(21) На разработку одинакового функционала на УФ нужно потратить значительно меньше сил, чем на ОФ.

Другое дело, что в 1С явно перемудрили с типовыми на УФ. "И простое сделаем сложным" - новый девиз 1С.

Так у обычных форм есть коллекция элементов - то есть все элементы можно перебрать и сохранить, скажем в файл - и при открытии формы восстановить из этого файла - чем не сериализация ?

(28) Только если функционал примитивный.

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

Согласен с мнением, что из-за клиент-серверного разнесения кода и асинхронности (хотя она как бы не обязательна) количество методов в разы больше приходится делать в управляемой форме. Количество кода, который надо писать в управляемой форме, тоже в среднем больше чем в обычной форме. Разрабатывать обычные формы заметно проще (на управляемых разработку веду уже года 3). Но ведь прикладные решения делаются не для разработчиков, поэтому удобствами разработки были на втором плане при рождении механизма управляемых форм. Во многом неудобства для разработчика обусловлены сильными ограничениями объектной модели на тонком клиенте, местами даже чрезмерно. Все ради влезания в тонкие и прерывистые каналы связи.

Кто хает механизм УФ, а вы пробовали самим наваять аналог?

Вот моя попробовать и придти к заключению что УФ внутри (структурно) гениальны до минимальной простоты. Там практически идеальная структура, когда начал с 0 придумывать пришел к полностью аналогичному решению ))

Разница только в именах полей и вместо директив компиляции &НаСервере|&НаКлиенте сделать разные отдельные модули намного нагляднее и проще для компилятора.

(33) Основной вопрос - зачем вообще форме нужен серверный модуль - объекту из базы - да, но форме - нет.

(34) Чтобы не засовывать этот код в другие объекты базы )) Или в общие модули.

Интересно принципы УФ запатентованы? Если нет то это огромная недоработочка от 1С ))

(36) У нас патентовать технологию нельзя - только готовую программу. Просто, любое Web-решение будет выглядеть похоже - если реализация будет на другом языке, то никто ничего похожего, кроме окон не найдёт.

(0)
Автор этого проекта явно изучал:
https://github.com/Rugut/UPP/blob/master/1С/Документы/АктСверкиВзаиморасчетов/ФормаДокумента/Форма.xml
Здесь кто-то изучал:
https://app.assembla.com/spaces/V8Unpack/documents/
И была еще ветка на Инфостарте, где предлагалось поучаствовать в разработке изучатора на дельфях. Сейчас не могу найти, ТС там категорически отказывался делиться наработками.
Ну и я в данный момент изучаю. Есть наработки (правда, на Питоне).
Общее впечатление - внутренний формат обычных форм (запятые и скобки промеж текста) развивался стихийно и ожидаемо порос костылями. Многие атрибуты не имеют фиксированного места, а прыгают от сохранения к сохранению. Большая беда с кнопками командной панели - у них каждый раз генерятся новые гуиды. Видимо, поэтому платформа не всегда отображает их в визуальном сравнении 2 форм. В файле версий поля "заголовка" и "строк" идут в рандомном порядке при каждом новом сохранении, и не отделены друг от друга. И так далее.

(38) Учитывая всю эту ересь, разрабы платформы наверняка почесали затылок и решили написать все с нуля в УФ, а ОФ просто больше никогда не трогать. Я б тоже так сделал.

(38) Вот первый ответ по существу. Спасибо. Да, описанная кривость претендует на техническую причину (0).

Если бы в 1С можно было просто сделать:

лФорма=Новый Форма;
лСтрФормы=лФорма.ДобавитьСтраницу("Страница1");
лСтрФормы.ДобавитьЭлемент("ПолеВвода");

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

(41) Не поверишь но в УФ практически так и есть... Ну только сначала предлагается свою либу-модуль написать для подобного, а дальше вот прямо такой код если хочешь.

(42)+ Да замечание там есть конечно некоторые траблы с отдельными элементами, но это именно траблы от недоработки и оно правится 1С успешно.

Это было в Microsoft Access 4.0 ещё под Windows 3.11
Как бы не было смешно, но это где-то 94-95 год.