Никто не знает подобного?

Чтобы описывать пользовательский интерфейс в текстовом виде быстро вручную.
По типу:

FORM ‘FormName1’ (Width 400, Height 400, Title ‘Авторизация’);
GROUP ‘Group1’ (Title ‘’, Group ‘Vertical’) IN ‘FormName1’;
FIELD ‘Login’ IN ‘LeftGroup1’;
FIELD ‘Password’ IN ‘LeftGroup1’;
GROUP ‘Group2’ (Group ‘Horizontal’) IN ‘Group1’ ;
BUTTON ‘OK’ (Title ‘ОК’) IN’‘ Group2’ ;
BUTTON ‘Cancel’ (Title ‘Отмена’) IN’‘ Group2’ ;


На уф? Хотя возможно и сделать если начинается с блока дефолтовых описаний реквизитов формы в 100500 параметров

(1) Пофиг на чем.
Мне идеи нужны, ваяю фреймворк для Golang.

Хотите снова придумать дельфю и DFM-файлы?

(3) Скорее аналог 1С:Предприятие.Элемент

(4)+ Развитие идеи Metadata.js

(3) В DFM от Delphi мне не нравится вложенность.
Как и прочие подобные на XML (всякие XULы и т.д.) или JSON.
Хочу линейность чтобы когда на форме дофига контролов это не превращалось в дикую елочку в виде дерева.

(6)+ Можно конечно аля CSS попытаться вложенность

(6) вложенность один из базисных принципов vcl, в соответствии с которым каждый компонент имеет своего owner'а. Если твоя библиоттека на иных принципах - ну, тогда можно и без вложенности.

(8) Owner всегда будет
Но хочу его указывать по линейному принципу!

Аля утиная типизация с опорой на уникальные id:
Group1.FIELD 'Login'

Или по принципу SQL:
FIELD 'Login' IN 'Group1'

(9)+ а не так:
GROUP 'Group1' ...
  FIELD 'Login' ...

И не так
GROUP 'Group1' {
FIELD 'Login' ...
}

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

(11) Именно!
И автоформатирование само поправит порядок элементов ))

(12)+ Т.к. файл состоит из отдельных строк разделитель ";"
То никаких проблем отсортировать.

Цель быстрое создание или правка UI.
Даже можно перекрывать свойства через SET (или UPDATE) 'Login'.Title = 'Вход'

А у Go есть своя визуальная либа? Я просто не в курсе... Удобная?

(14)+ Понятно автоформатирование должно это правильно отработать, соединив отдельные команды

(0) В мобилках все формы через текст оформляются. Изначально упор на это

(15) В смысле?

(15) Есть https://github.com/fyne-io/fyne
Но там та же проблема со вложенностью:

package main

import (
    "fyne.io/fyne/v2/app"
    "fyne.io/fyne/v2/container"
    "fyne.io/fyne/v2/widget"
)

func main() {
    a := app.New()
    w := a.NewWindow("Hello")

    hello := widget.NewLabel("Hello Fyne!")
    w.SetContent(container.NewVBox(
        hello,
        widget.NewButton("Hi!", func() {
            hello.SetText("Welcome :)")
        }),
    ))

    w.ShowAndRun()
}


https://ru.wikipedia.org/wiki/YAML

(20) Та же проблема сильных вложенностей, да еще и питон-стайл (ненавижу, отвращение) с отступами-пробелами

(18) ну в смысле библиотека на которой клепать интерфейсы. Питон, например, "из коробки" скриптовой + web, хотя для десктопов энтузиасты кое-что прикрутили, в частности Qt.

* скриптовой и консольный, хотел сказать

(19) а как ты собрался работать с интерфейсом, представляющим собой вложенность элементов, без вложенности?

(24) ссылками

он написал уже выше

(22) Из коробки ничего пока в Go нет, он изначально бэкендовый
Но уже много чего понаписали

(24) см (9) и (10)

(25) вложенность одного в другое хоть как придётся описывать

(29) Да придется.
Но не так:
Владелец{
  Объект
}

А так:
Объект.Владелец = Владелец
Владелец.Объект ...
Объект ... IN Владелец

(30) то есть ты хочешь уйти от объектного стиля (как обычно принято и как удобно описывать UI), к процедурному стилю? Но зачем?

(31) Удобное текстовое редактирование даже сильно вложенных форм

(32)+ С выделением цветом выбранных идентификаторов будет прекрасно.
И автоформатированием "кода".

(32) это пока мало кода, когда будет много, получишь жуткое месиво. Годами придумывали всякие там макеты UI, декаларативные описания, чтобы уйти от подобного

(33)+ Плюс контролы и группы контролов можно выносить в отдельные файлы
В нужном месте ссылка на них по типу "вложенных подзапросов"
Редактор специальный наваять чтобы при наведении показывал содержимое а при клике открывал файл в отдельном окне

Т.е. не визуальный редактор а текстовый!
Примерно как OpenSCAD vs AutoCAD

(34) Они все заточены на визуальщину и мышередактор
Хочу кодом с клавы.

(36)+ Примерно как программное создание/исправление элементов форм.
Но в удобном компактном виде, без долгого прописывания лишнего.

(34) В случае разнесения по файлам месива не будет
Еще можно области/секции как в коде 1С

(36) в андроиде разбивают одну вьюху на маленькие фрагменты, а потом описывают с помощью Jetpack Compose

https://developer.android.com/guide/fragments

https://developer.android.com/jetpack/compose

оно?

(32) если текстовое, то как раз "елочка"-то лучше будет. Особенно если предусмотреть сворачивание-разворачивание вложенных блоков. Все в одном месте.

когда визуальное, то эти файлы редко кому нужны в них смотреть, и в общем-то норм. А вот если чисто текстовое... тогда это другое.

(40) Я пробовал с елочкой формы править и это ужас.
Когда уровней вложенности мало (2-3) это куда ни шло но когда сложные формы с кучей вложенности превращается в кошмар.
Представь например вкладки-табы и внутри еще вкладки и там разные группы

(39) Не оно. Это комшарная елочка
Ты только глянь на эту картинку https://developer.android.com/static/images/jetpack/compose/landing-code-static.svg
И представь как это выглядит когда нормальная сложная форма

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

(43) и что? Суть в том, что с Jetpack Compose "ёлочку" интерфейса легко декомпозировать. Уже не требуется монолитный макет со 100500 уровнями вложенности и часовым скроллингом. Попробуй то же самое в процедурном стиле провернуть. Запутаешься быстрее, чем допишешь форму

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

(45) (46) Про GIT в курсе?

(47) и что GIT?

(48)+ Коллективная разработка с merge и историей версий для форм

а что гит? Я ж не предлагаю в бинарниках описания форм хранить, хотя и такое было во времена Delphi 2-4 точно. По-моему, только в пятерке окончательно перешли на текст.

(50) елочка в гите плохо
отдельные строки хорошо

(49) GIT и другие системы контроля версий прекрасно дружат с тем же Jetpack Compose

(51) seriously???

по-моему, текст он и в африке текст. Как-то же хранят HTML и XML, а там иной раз елочки дай боже какие

(52) угу построчно )) целиком блоками или файлами когда куча строк удалено и куча добавлено
хотя всего внутри {} один символ поменяли

(55) какую-то искусственную проблему придумываешь. А как же тогда живёт функциональное программирование? Там весь код сплошные "ёлочки". Вот, например:
https://clojure.org/about/functional_programming

(53) https://habr.com/ru/post/195674/
"Стратегия resolve"

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

(56) Плохо живет функциональное
Сам почитай как там с GIT'ом

1С например только на уровне процедур/функций умеет авто сливать
Сам код вручную правь, тоже самое с блоками внутри елочки

(58)+ Если два разраба одну процедуру/функцию изменили то трехстороннее слияние только руками
В моем случае если разные строки даже внутри одного контрола пофиг

(6) "Хочу линейность чтобы когда на форме дофига контролов это не превращалось в дикую елочку в виде дерева."
В виде дерева гораздо понятнее. И что мешает писать на xml или JSON не в виде дерева?

(58) читал, и всё у них хорошо с GIT. Твои псевдопроблемы разруливаются инструментальными средствами. В том же EDT есть штатные плагины, которые позволяют сравнивать формы как формы, а не как XML. И всё хорошо работают. Да даже если бы была проблема с GIT, язык должен быть удобен для решения возложенных на него задач, а не для GIT'а

(61) >В том же EDT есть штатные плагины, которые позволяют сравнивать формы как формы, а не как XML. И всё хорошо работают.

"А мужики то и не знают"©

Пруф плиз

(60) Не мешает но смысла мало
Можно примеры как это будет выглядеть на XML/JSON?

(0) есть что-то такое, уже придумано для форм, но назввание не помню, у фузиновцев поспрошай

Да даже если с голым GIT. Ну декомпозируй ты "ёлочки" на множество отдельных "веточек", и всё будет отлично. Одна "ёлочка" будет описывать одну кнопку, вторая "ёлочка" другую кнопку, треться "ёлочка" текстовое поле и так далее. Хоть десять разрабов будут долбить одну форму, каждый будет колупать свои "ёлочки"

(62) https://its.1c.ru/db/edtdoc#content:10050:hdoc

(65) В случае вложенных это не работает. Как поделишь то?

(66) И? Где там про сравнение и объединение форм?
Ты сам с EDT то работал?

(67) да в смысле не работает??? Всё прекрасно работает. Я же тебе дал ссылку на Jetpack Compose, там и примеры кода есть. Отдельная функция описывает отдельный элемент (кнопку, поле или др.) и всё пучком

(68) у меня к тебе тот же вопрос. Ты сам с EDT+GIT то работал?

(70) Да, работал. В БИТ:ERP.
Но ты так и не ответил на вопрос.

(69) В случае вложенных как? Независимые то понятно.

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

(72) а это и есть описание вложенных элементов

https://www.youtube.com/watch?v=qvDo0SKR8-k

(63) ну так, допустим

{
FormName1: {type:"FORM", Width:400, Height:400, Title:"Авторизация"},
Group1: {type: "GROUP", Title:"", GroupType:"Vertical", Parent:"FormName1"},
ButtonOk: {type: "BUTTON", Title:"ОК", Parent: "Group1"},
ButtonCancel: {type: "BUTTON", Title:"Cancel", Parent: "Group1"}
}

(73) Трехстороннее?

(76) А зачем тут json?
Выкинуть лишние скобки, пробелов за глаза хватает

(78) ты же сам хотел JSON. Бухой что ли.
"Можно примеры как это будет выглядеть на XML/JSON?"

вот прям правильный JSON

{
  "FormName1": {
    "type": "FORM",
    "Width": 400,
    "Height": 400,
    "Title": "Авторизация"
  },
  "Group1": {
    "type": "GROUP",
    "Title": "",
    "GroupType": "Vertical",
    "Parent": "FormName1"
  },
  "ButtonOk": {
    "type": "BUTTON",
    "Title": "ОК",
    "Parent": "Group1"
  },
  "ButtonCancel": {
    "type": "BUTTON",
    "Title": "Cancel",
    "Parent": "Group1"
  }
}


Так что не выдумывай проблемы и используй JSON. А то знаем мы вашего брата-бездельника - начнет писать парсер своего выдуманного языка описания интерфейса, не допишет, забросит и на этом супер пупер фреймворк на golang закончится.

(79) Намекал что в том стиле {} лишние

(81) Парсер фактически к виду (80) и будет приводить
Так что согласен что можно сразу это за основу брать

Есть еще yml
Тоже хороший язык,но проще.
Правда,вложенность поддерживается.

(77) да

Вы придумываете fxml? Зачем?

В javafx это уже есть вроде

вот вам бизнес-план, берете fxml, конверите его в yaml. это наверное было бы удобно.

(86) у fxml тоже вложенность ёлочкой

(0) про Фузину уже говорили? Там всё именно так: https://docs.lsfusion.org/ru/FORM_statement/

(0) sql сделан удобным для запросов. Для описания структур нужно xml или json. По которым уже в свою очередь можно делать запросы типа sql. (те структуры запросто ложаться на просто таблицы). Изобретать еще один описатель структур будет лишним.

"в текстовом виде быстро вручную", оно замечательно быстро описывается, если знаешь классы на которых описываешь. В остальных случаях это не быстрее и не легче чем любая из существующих библиотек для этого. И если придумаешь свои классы, то единственное что их будет отличать, то что лично ты их будешь знать. Хотя быстрее изучить что-либо существующее, чем изобрести подобное новое.

(90) Нет там совсем не так.
И не то что мне требуется.

(91) В SQL кроме SELECT есть еще много разных конструкций.
Например CREATE, DROP и т.д.

И да у меня просто CREATE опущено впереди, краткая форма:
FORM 'FormName1' (Width 400, Height 400, Title 'Авторизация');
GROUP 'Group1' (Title '', Group 'Vertical') IN 'FormName1';
FIELD 'Login' IN 'Group1';
FIELD 'Password' IN 'Group1';

Полная форма:
CREATE FORM 'FormName1' (Width 400, Height 400, Title 'Авторизация');
CREATE GROUP 'Group1' (Title '', Group 'Vertical') IN 'FormName1';
CREATE FIELD 'Login' IN 'Group1';
CREATE FIELD 'Password' IN 'Group1';

Вот если элемент надо удалить то
DELETE (или DEL) FIELD 'Password'

И да получить значение
GET FIELD 'Password'

Установить
SET FIELD 'Login' "Вася"

(93)+ Технически "FIELD" можно опускать
DEL 'Password'
GET 'Password'
SET 'Login' "Вася"

(6) Вложенность, это свойство разворачивания ссылок. Не нравится вложенность - назначай идентификаторы и ссылайся на них. Либо так, либо так, и третьего варианта вроде нет.

(94)+ Некая абстракция из элементов управления (контролов)
И методы общения с ними с сервера, ибо сами контролы на клиенте

Т.е. клиент рассматривается как сервер в аналогии СУБД
А серверный код как выполняющий запросы к формам

(95) Вопрос был нет ли уже подобного лаконичного языка работы с UI?

(93) Беспорно, можно и так описывать. Но это все одно и то же. Разные фантики оборачиваемые вокруг структур, и один синтаксис подчастую конвертируем в другой.

(97) Наиболее компактный это json. В примере (93) синтаксического текста больше написано, чем в json печатать скобочек.

Если не нравится вложенность, то а-ля виндовый ini файл...

(если не нравятся скобочки)

(98) А далее делаем аналогию с SQL
Оно вроде как один и даже стандартизован а реализаций (в виде СУБД) множество как и множество ЯП в которых можно sql запросы

Идея берем некую UI библиотеку аля ExtJS, DHTMLX и т.д.
И вместо изучения ее потрохов работаем через "универсальную" прокладку

(97) Если бы он был, каждому первому не пришлось бы придумывать свой DSL для описания UI.
А то напридумывали HTML/CSS, XUL, XAML, QML etc.

Просто оказывается UI такая штука, которая со словом "просто" в общем случае ну никак рядом не встаёт.

(102)+ Вот и хочу написать микросервис-прокладку
Чтобы из 1С или любого другого бэкендного ЯП рисовать браузерный пользовательский интерфейс и работать с ним универсально.

(96) сюда смотрел https://divkit.tech/ru/ ?

(103) Согласен что не просто.
Хочу урезать по контролам сильно.

Чтобы хотя бы криво но просто рисовать.

(105) Да идея похожая
Но вместо JSON язык по типу SQL

сервер 1С (http-сервис) - микросервис "прокладка" - браузер клиента

при заходе браузером по адресу прокладка выполняет обратный http-запрос на 1С
1С смотря какой запрос формирует команды "языка UI" или на создание UI
или на выполнение действий с формами на клиенте
в процессе 1C может дозапрашивать (HTTPСоединение) у прокладки некие данные так же на "языке UI", там хранится состояние клиента в течении сессии

(108)+ по сути это аналог "Metadata.js" или веб-клиента 1С

(108)+ чем то похоже на текстовый протокол HTTP
только высокоуровневая абстракция над ним, заточено для бизнес-контролов

конкретная задача для которой это изобретается это написание личного кабинете клиента привязанного к данным в серверной базе 1С
веб-клиента нельзя ибо лицензий нет столько

в будущем это должно легко допиливаться и сопровождаться обычным 1Сником, без погружений в потроха HTML/CSS/JS

(107) А что ты в SQL уперся?
Размеченный формат парсить проще.

(111) JSON не очень удобно вручную писать или программно, как и отлаживать
Но встроенный парсер в Структуры 1С будет и обратно

(112)+ Если JSON за основу то придется визуальный редактор форм ваять
Не хочу.

(113) Единственное что отличает СИНТАКСИС у SQL от JSON, это то, что в скл: "create ... ;" а в json: "{}". Все остальное это вопрос того, что и как ты в эти "скобочки" запихнешь.

(114) Если не использовать вложенность ("ёлочку") {{}} то нет смысла сохранять эти скобки
Ключевое слово и пробелов достаточно

(113) А для SQL не придется? Странный аргумент

(115) Пасиб, поржал. Ты исходники питона блокнотом правил когда-нибудь?

(116) не придется, достаточно визуализатора форм
много редакторов-конструкторов SQL и какая в них востребованность?

(117) Отступов не будет! Никакого питона-стайл

(115)+ сравни

CREATE FORM 'FormName1' (Width 400, Height 400, Title 'Авторизация');

{FORM:'FormName1',{Width:400, Height:400, Title :Авторизация'}};

(120) имхо первый вариант без {} читается лучше и пишется легче

(120) и
CREATE FORM 'FormName1' (Width 400, Height 400, Title 'Авторизация');
может быть переписан как
CREATE FORM 'FormName1';
SET 'FormName1'.Width 400;
SET 'FormName1'.Height 400;
SET 'FormName1'.Title 'Авторизация';

(122)+ CREATE и SET можно опускать

(120) писать парсер для своего языка проще, чем взять готовы парсер json/xml/...?

Возьмите Си
Там интерфейс так и пишется
CreateWindow ...
А потом switch на события.

(124) да сначала проще взять json

(122) Посмотри FXML в JavaFX. Как минимум в твоих примерах не видно привязки к процедурам-обработчикам.

(120) Что читается лучше, это абсолютно вопрос только привычки. То, к чему глаза привыкли видеть пока годами пялился в эти ЯП.

в delphi был grid,  его можно растянуть на весь экран и в каждый квадрат этого grid вставить , еще grid , если нужно

(0) На FoxPro 2.5 такое было ))

(130) Хмм про ForPro я уже и забыл, сталкивался с ним только как эникей/админ, сам не писал на нем почти.
Да там нечто похожее но лишь частично.

Хотя задача та же, пользовательский интерфейс для базы данных.