Поиск JS-фреймворка для генерации UI


    Как-то я захотел попробовать реализовать одно маленькое клиент-серверное приложение. Реализация в задумке была такая: на клиентской стороне рисуем с помощью какого-нибуть JS-фреймворка окошки, на серверной стороне обрабатываем вызовы с клиента с помощью скомпилированного приложения, написанного например на Go.


    Я начал подбирать фреймворк, предоставляющий декларативный интерфейс. В моём представлении он на входе должен получать в максимально упрощённом виде описание содержимого формы (например в формате YAML, JSON, BEMJSON, XML, или даже INF), а на выходе рисовать в браузере красивую форму с работающими элементами управления.


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


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


    HTML- и CSS-шаблоны


    Всё, что я находил, работало не так как мне хотелось. Я не хочу ничего знать про вёрстку и стили. Я так же не хочу заполнять HTML, как это делается при применении фреймворков типа Bootstrap, Skeleton, MDL и т. д.


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


    <div class="input-group mb-3">
      <div class="input-group-prepend">
        <div class="input-group-text">
          <input type="checkbox" aria-label="Checkbox for following text input">
        </div>
      </div>
      <input type="text" class="form-control" aria-label="Text input with checkbox">
    </div>
    <button type="button" class="btn btn-primary btn-lg btn-block">Block level button</button>

    Всё, что я хочу подать на вход, должно быть примерно такого вида:


    {
        "main": {
            "prop":{},
            "elements": [
                {
                    "type":"checkbox",
                    "name":"Использовать что-то",
                    "style":"classic",
                    "checked": true
                },
                {
                    "type":"button",
                    "name":"Сохранить",
                    "style":"outline",
                    "onclick":"btnsave_onclick"
                }
    
        }
    }

    Ну и чтобы можно было элементы в группы объединять и указывать как должны быть расположены элементы внутри группы: вертикально или горизонтально. Какое там будет оформление, мне не особо важно. Я ожидал найти даже какой-нибудь визуальный редактор окошек, однако — нет.


    Сборки технологий


    Тогда я попробовал поискать какие-то сборки технологий — кто-то наверняка проложил давно короткий путь и не раз.


    И я нашёл что-то похожее на то, что мне нужно: Сайт с нуля на полном стеке БЭМ-технологий.


    Пример BEMJSON:


    ({
        block: 'page',
        title: 'Hello, World!',
        styles: [
            { elem: 'css', url: 'index.min.css' }
        ],
        scripts: [
            { elem: 'js', url: 'index.min.js' }
        ],
        content: [
            'Hello, World!'
        ]
    })

    Когда я прокрутил примерно 20-й экран текста, а ползунок находился всё ещё вверху, я подумал, что этот короткий путь какой-то длинный. Не пойдёт.


    Почитал я кстати про этот БЭМ — суть мне понравилась, да ещё хорошо и доступно описано. Есть разные шпаргалки, например мне понравилась вот эта. Поискал ещё информацию и обнаружил, что не всем нравится технология (например тут и тут). А здесь на мой взгляд изложена суть спорных моментов.


    Интересно то, что используя поиск, я кроме БЭМ-а, долго не мог обнаружить более никаких альтернативных технологий. Однако они есть: OOCS (вроде как тот же БЭМ, только попроще), SMACSS, AtomicCSS, CSSinJS (найдено тут).


    Node.js


    Я тогда подумал, ок, можно отказаться от первоначальной идеи и реализовать серверную часть на скриптовом языке, т. е. попросту использовать nodejs. Это не только модно, стильно, молодёжно, это ещё возможность писать на всех слоях на одном языке. Масса статей опять же (про быстрый старт мне понравилась эта). Если я правильно понял, под него написано бесчисленное количество NPM-пакетов, практически под любые задачи. Есть ещё под это дело такая серьёзная штука, как Electron.


    Пример кода страницы с использованием Electron:


    <head>
      <meta charset="utf-8">
      <link rel="stylesheet" href="assets/css/variables.css">
      <link rel="import" href="sections/about.html">
    </head>
    <body>
    
      <nav class="nav js-nav">
        <header class="nav-header">
          <h1 class="nav-title">Electron <strong>API Demos</strong></h1>
        </header>
        <div class="nav-item u-category-windows">
        </div>
        <footer class="nav-footer">
          <button type="button" id="button-about" data-modal="about" class="nav-footer-button">About</button>
        </footer>
      </nav>
      <main class="content js-content"></main>
      <script>
        require('./assets/normalize-shortcuts')
      </script>
    </body>
    </html>

    Единственный минус nodejs, что можно написать более производительную вещь, используя Go.
    Допустим я хочу использовать nodejs. Есть каталог NPM-пакетов, чтобы можно было выбрать себе что-то подходящее.


    Есть пакет, который так и называется forms. Вот пример кода:


    var forms = require('forms');
    var fields = forms.fields;
    var validators = forms.validators;
    
    var reg_form = forms.create({
        username: fields.string({ required: true }),
        password: fields.password({ required: validators.required('You definitely want a password') }),
        confirm:  fields.password({
            required: validators.required('don\'t you know your own password?'),
            validators: [validators.matchField('password')]
        }),
        email: fields.email()
    });

    В саму форму это собирается командой reg_form.toHTML();. Интересный вариант, но не то.


    Есть ещё Element, Riot, TotalJS и iView. Это можно добавить к списку из Bootstrap-а, MDL-а и т. д.


    Пример кода страницы с использованием Element:


    <!DOCTYPE html>
    <html>
    <head>
      <meta charset="UTF-8">
      <!-- import CSS -->
      <link rel="stylesheet" href="https://unpkg.com/element-ui/lib/theme-chalk/index.css">
    </head>
    <body>
      <div id="app">
        <el-button @click="visible = true">Button</el-button>
        <el-dialog :visible.sync="visible" title="Hello world">
          <p>Try Element</p>
        </el-dialog>
      </div>
    </body>
      <!-- import Vue before Element -->
      <script src="https://unpkg.com/vue/dist/vue.js"></script>
      <!-- import JavaScript -->
      <script src="https://unpkg.com/element-ui/lib/index.js"></script>
      <script>
        new Vue({
          el: '#app',
          data: function() {
            return { visible: false }
          }
        })
      </script>
    </html>

    Есть ещё Blueprintsjs. Это пожалуй максимально похоже на то, что я искал. Есть возможность настраивать элементы управления по отдельности друг от друга.


    Код выглядит как-то так:


    Много кода с использованием Blueprints
    /*
     * Copyright 2018 Palantir Technologies, Inc. All rights reserved.
     *
     * Licensed under the terms of the LICENSE file distributed with this project.
     */
    
    import * as React from "react";
    
    import { FormGroup, H5, InputGroup, Intent, Switch } from "@blueprintjs/core";
    import { Example, handleBooleanChange, handleStringChange, IExampleProps } from "@blueprintjs/docs-theme";
    import { IntentSelect } from "./common/intentSelect";
    
    export interface IFormGroupExampleState {
        disabled: boolean;
        helperText: boolean;
        inline: boolean;
        intent: Intent;
        label: boolean;
        requiredLabel: boolean;
    }
    
    export class FormGroupExample extends React.PureComponent<IExampleProps, IFormGroupExampleState> {
        public state: IFormGroupExampleState = {
            disabled: false,
            helperText: false,
            inline: false,
            intent: Intent.NONE,
            label: true,
            requiredLabel: true,
        };
    
        private handleDisabledChange = handleBooleanChange(disabled => this.setState({ disabled }));
        private handleHelperTextChange = handleBooleanChange(helperText => this.setState({ helperText }));
        private handleInlineChange = handleBooleanChange(inline => this.setState({ inline }));
        private handleLabelChange = handleBooleanChange(label => this.setState({ label }));
        private handleRequiredLabelChange = handleBooleanChange(requiredLabel => this.setState({ requiredLabel 
    
    }));
        private handleIntentChange = handleStringChange((intent: Intent) => this.setState({ intent }));
    
        public render() {
            const { disabled, helperText, inline, intent, label, requiredLabel } = this.state;
    
            const options = (
                <>
                    <H5>Props</H5>
                    <Switch label="Disabled" checked={disabled} onChange={this.handleDisabledChange} />
                    <Switch label="Inline" checked={inline} onChange={this.handleInlineChange} />
                    <Switch label="Show helper text" checked={helperText} onChange=
    
    {this.handleHelperTextChange} />
                    <Switch label="Show label" checked={label} onChange={this.handleLabelChange} />
                    <Switch label="Show label info" checked={requiredLabel} onChange=
    
    {this.handleRequiredLabelChange} />
                    <IntentSelect intent={intent} onChange={this.handleIntentChange} />
                </>
            );
    
            return (
                <Example options={options} {...this.props}>
                    <FormGroup
                        disabled={disabled}
                        helperText={helperText && "Helper text with details..."}
                        inline={inline}
                        intent={intent}
                        label={label && "Label"}
                        labelFor="text-input"
                        labelInfo={requiredLabel && "(required)"}
                    >
                        <InputGroup id="text-input" placeholder="Placeholder text" disabled={disabled} 
    
    intent={intent} />
                    </FormGroup>
                    <FormGroup
                        disabled={disabled}
                        helperText={helperText && "Helper text with details..."}
                        inline={inline}
                        intent={intent}
                        label={label && "Label"}
                        labelFor="text-input"
                        labelInfo={requiredLabel && "(required)"}
                    >
                        <Switch id="text-input" label="Engage the hyperdrive" disabled={disabled} />
                        <Switch id="text-input" label="Initiate thrusters" disabled={disabled} />
                    </FormGroup>
                </Example>
            );
        }
    }

    Результат выглядит так:


    Даже если учесть только последнюю часть: всё-равно как-то не очень лаконично.


    metadata.js


    Вот ещё нашёл на просторах Сети интересную вещь — metadatajs. Быстрый старт — тут. Данная библиотека обладает избыточным функционалом, а в статье нет на мой взгляд самого главного — описания самой библиотеки. Это есть здесь.


    Форму описывать нам предлагают так:


    Описание формы с использованием metadata.js
    {
      "enm": {},
      "cat": {
        "Номенклатура": {
          "form": {
            "selection": {
              "fields": [
                "is_folder",
                "id",
                "Артикул",
                "_t_.name as presentation",
                "`cat_КлассификаторЕдиницИзмерения`.name as `ЕдиницаИзмерения`",
                "`cat_НоменклатурныеГруппы`.name as `НоменклатурнаяГруппа`"
              ],
              "cols": [
                {"id": "id", "width": "120", "type": "ro", "align": "left", "sort": "server", "caption": "Код"},
                {"id": "Артикул", "width": "150", "type": "ro", "align": "left", "sort": "server", "caption": "Артикул"},
                {"id": "presentation", "width": "*", "type": "ro", "align": "left", "sort": "server", "caption": "Наименование"},
                {"id": "ЕдиницаИзмерения", "width": "70", "type": "ro", "align": "left", "sort": "server", "caption": "Ед"},
                {"id": "НоменклатурнаяГруппа", "width": "170", "type": "ro", "align": "left", "sort": "server", "caption": "Номенклатурная группа"}
              ]
            }
          }
        },
        "ДоговорыКонтрагентов": {
          "form": {
            "selection": {
              "fields": [
                "is_folder",
                "id",
                "_t_.name as presentation",
                "`enm_ВидыДоговоров`.synonym as `ВидДоговора`",
                "`cat_Организации`.name as `Организация`"
              ],
              "cols": [
                {"id": "presentation", "width": "*", "type": "ro", "align": "left", "sort": "server", "caption": "Наименование"},
                {"id": "ВидДоговора", "width": "150", "type": "ro", "align": "left", "sort": "server", "caption": "Вид договора"},
                {"id": "Организация", "width": "150", "type": "ro", "align": "left", "sort": "server", "caption": "Организация"}
              ]
            }
          }
        }
      },
      "doc": {
        "ЗаказПокупателя": {
          "form": {
            "selection": {
              "fields": [
                "date",
                "number_doc",
                "Контрагент",
                "СуммаДокумента",
                "posted",
                "СостояниеЗаказа",
                "Комментарий"
              ],
              "cols": [
                {"id": "date", "width": "120", "type": "ro", "align": "left", "sort": "server", "caption": "Дата"},
                {"id": "number_doc", "width": "120", "type": "ro", "align": "left", "sort": "server", "caption": "Номер"},
                {"id": "Контрагент", "width": "170", "type": "ro", "align": "left", "sort": "server", "caption": "Контрагент"},
                {"id": "СуммаДокумента", "width": "120", "type": "ron", "align": "right", "sort": "server", "caption": "Сумма"},
                {"id": "СостояниеЗаказа", "width": "100", "type": "ro", "align": "left", "sort": "server", "caption": "Состояние"},
                {"id": "Комментарий", "width": "*", "type": "ro", "align": "left", "sort": "server", "caption": "Комментарий"}
              ]
            },
            "obj": {
              "head": {
                " ": ["number_doc", "date", "ВидОперации", "Организация", "Контрагент", "Договор"],
                "Планирование": ["СостояниеЗаказа", "Старт", "ДатаОтгрузки"],
                "Дополнительно": ["Проект", "Касса", "Событие", "НалогообложениеНДС", "СуммаВключаетНДС", "Ответственный", "Комментарий",
                  {"id": "СуммаДокумента", "path": "o.СуммаДокумента", "synonym": "Сумма документа", "type": "ro"}
                ]
              },
              "tabular_sections": {
                "Запасы":  {
                  "fields": ["row","Номенклатура","Характеристика","Количество","ЕдиницаИзмерения","Цена","ПроцентСкидкиНаценки","Сумма","СтавкаНДС","СуммаНДС","Всего","ДатаОтгрузки","Спецификация","Содержание"],
                  "headers": "№,Номенклатура,Характеристика,Колич.,Ед,Цена,% Скидки,Сумма,% НДС,НДС,Всего,Отгруз.,Спецификация,Содержание",
                  "widths": "40,*,*,70,50,70,70,70,70,70,70,70,70,80",
                  "min_widths": "40,200,140,70,50,70,70,70,70,70,70,70,70,80",
                  "aligns": "",
                  "sortings": "na,na,na,na,na,na,na,na,na,na,na,na,na,na",
                  "types": "cntr,ref,ref,calck,refc,calck,calck,ron,refc,ron,ron,dhxCalendar,ref,txt"
                }
              }
            }
          }
        }
      },
      "ireg": {},
      "areg": {},
      "dp": {},
      "rep": {},
      "cch": {},
      "cacc": {}
    }

    Это очень похоже на то, что нужно. Однако возникают вопросы: набор кнопок похоже задан по умолчанию? Можно ли его менять? Где описание синтаксиса (что такое "enm", "cat" и т. д.)?
    Видно, что на проект много усилий вложено, но библиотека пока сыровата.


    Заключение


    Давайте порассуждаем. Формочки можно заранее нарисовать на сервере, скомпилировать и отдавать на сторону клиента готовый html/css/js-код. В этом случае нужно искать совсем другое. Но если мы хотим, чтобы пользователь работал у нас в одном окне браузера, и в этом окне видел дочерние окна веб-приложения, не было бы логичным закешировать css/js-код на клиенте, который будет получать от сервера короткие команды с описанием очередной формочки и будет рисовать их за счёт ресурсов клиента?


    Коллеги, где вы прячете фреймворк с декларативным интерфейсом? )


    Он должен быть! Почему я не могу его найти?

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Каково Ваше мнение?

    Поддержать автора
    Поделиться публикацией

    Комментарии 94

      +1
      Если вы захотите эти автогенерируемые формы гибко настраивать (цвет там, шрифт, положение и пр.), то абстрагировать HTML+CSS, хотя это не даст уменьшения количества информации, я не вижу смысла.
      Если не боитесь безликого типового внешнего вида, то это довольно несложно и самому сделать, даже на базе обычного Go'шного html/template.

      А вообще рекомендую взглянуть на экосистему Clojure/Clojurescript и библиотеку re-frame.
        +1
        вот это от mozilla посмотрите github.com/mozilla-services/react-jsonschema-form
          –1

          Долгие поиски решения задачи подобной вашей, что успешно завершились Ruby on Rails + EmberJS (ember-paper). Это просто супер кайф от разработки и производительность, после VueJS, ReactJS и тем более Angular. Минимум пишешь, максимум получаешь. Сорян если, кто не пробовал… я все перепробовал… увы...

            0

            На golang веду мелкий микросервис, большое приложение не советовал бы. ...

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

              «Фреймворк для генерации UI» — именно в таком, максимально широком виде — это всё те самые HTML+CSS+JS. Генерируй себе по самое нехочу. Когда появляется желание на чем-то сэкономить и уменьшить сложность — нужно очень четко представлять, что именно вы хотите сэкономить, и где конкретно уменьшить сложность; потому что каждое уменьшение сложности — это еще и сокращение функционала, уменьшите не там — получите прикольную бесполезную штуку, с помощью которой попросту нельзя сделать то, что вам хочется.

              Вам нужно генерировать формочки? Это задача типичного кровавого энтерпрайза, которую на голом энтузиазме вряд ли кто-то кинется решать. Вам остаётся либо написать это самому, либо заплатить тому, кто напишет. Вон, вы уже нашли 1Сников, которые для 1С формочки генерят, заинтересуйте их — и, думаю, они вам и в общем виде напишут, без привязки к 1С.
                +1
                Согласен, что универсальнгого решения нет.
                Но есть современные инструменты которые помогут бысторо построить решение для «узкого пространства задач».
                +6
                Для некрофилов есть ExtJS
                  0
                  Всё еще живет и процветает в энтерпрайз среде RIA приложений
                    0
                    Надеюсь они уже подвезли что-то новое. Т.к. полтора года назад ситуация была печальная: он платный + ES5.
                      0
                      Уже есть GPL и ES6 :)
                        0
                        GPL был сначала для всех версий, потом только для мажорных, а сейчас дикая Community Edition.
                  0
                  Если нет необходимости в супер-функциональности, может имеет смысл оглянуться по времени назад?
                  Был такой фреймворк jsRender, довольно простой и в то же время гибкий, основан на старом добром jQuery.
                  На Хабре была статья про него.
                    +2
                    Мне понравился webix.
                    Есть редактор форм.
                      +1
                      Удваиваю вебикс. Часто он «просто работает». Конечно, если нужно что-то сильно кастомное — никаких фреймворков.
                        +1
                        все же помнят что он НЕ бесплатный?)))
                        а то у нас тут один разработчик воткнул вебикс «просто потому что он работает», и очень сильно обижался что я его заставил выпилить это изделие из проекта. или заплатить за него из своего кармана. потому что мы не можем установить клиенту не лицензионное ПО, а 2500-4000 американских денег в бюджете проекта на вебикс у нас на тот момент не было.

                        хотя да, выглядит он не плохо.
                      0
                      Автор нашел множество готовых фреймворков (и наверняка их гораздо больше), но они ему чем-то не понравились. В такой ситуации надо продолжать искать дальше, отрабраковывать ещё и ещё, чтобы потом понять, как именно самому нравится и начать велосипедить свой собственный фреймворк. С аутлайнами и фрейлинами.
                        –1

                        Webix + NodeJS, а между ними Socket.io

                          +1

                          Давным давно, когда я был молодой и неопытный и за доширак клепал сайты визитки, меня тоже посещала мысль о волшебном фреймворке для всяких crud операций — скармливаем ему метаданные а он нам всякие формочки рисует и данные обрабатывает. Был и свой велосипед, и даже сданные пректы на нем. Вот только чем сложнее были проекты, тем страшнее разрастался велосипед, и все-равно он не мог решать задачи оптимальным образом. И я забросил эту затею.


                          Чем универсальнее и функциональнее решение, тем выше порог входа и сложнее кастомизировать некоторые чамти. Поэтому надо выбирать, что-то среднее.


                          По вашему описанию не до конца понятно что именно требуется. Если вам действительно окошки — то это скорее к extjs, несмотря на то что это уже позавчерашний день. Если по большей части crud — присмотритесь к react admin. Ну и раз прошли такой большой путь в поисках присмотритесь к классике проверенной временем — django. Не совсем то что вы ищите, но это та самая золотая середина.

                            0
                            Чем универсальнее и функциональнее решение, тем выше порог входа и сложнее кастомизировать некоторые чамти. Поэтому надо выбирать, что-то среднее.


                            очень согласен с этой частью )
                              –1

                              И тем не менее это не так. Да, высокоуровневая, но кастомизируемая система — редкая птица. Но не невозможная.

                              0
                              Метаданные не удается описать декларативно, потому что нужно учесть поведение. Раньше считали, что можно отделить описание интерфейса и поведение (HTML/JS), теперь понимают, что это неотделимо, и возникли всякие реакты с дартами, где вся разметка перекочевала в скрипт. Проще описать структуру классов на том же JS, чем всякий валежник типа XML/JSON. Программизм не умрет.
                                –1

                                Всё прекрасно отделимо. Просто фейсбук написан на пхп, поэтому они нанимают пхпшников, у которых, за что ни возьмутся, получается пхп.)

                                  0
                                  Dart тоже писали PHP-шники? Я сам честно пробовал, но не получается отделить в нормальном динамическом SPA, где поведение определяет интерфейс, а не наоборот.
                                    –1
                                    Dart тоже писали PHP-шники?

                                    Вы наверно имели ввиду Flutter? Они просто следуют за трендами в этом вопросе.


                                    Я сам честно пробовал, но не получается отделить в нормальном динамическом SPA

                                    Гляньте $mol. Там всё отделено. И есть так желанное вами наследование и переопределение чего угодно.

                                      0
                                      Спасибо, интересно
                                  0
                                  дарты возникли потому что в js есть тьма нюансов, которые надо помнить.А дарт попытался сделать язык с понятным поведением где не будет столько свободы воли в реализации тех же классов, которые в разработке либ каждый городит как ему кажется правильнее.
                                    0
                                    дарты возникли потому что в js есть тьма нюансов, которые надо помнить

                                    До этого понятное поведение было у ActionScript. Но была зависимость от песочницы. Поэтому возник dart

                                0
                                450 тысяч строк кода однако
                                habr.com/ru/company/1c/blog/315414
                                  –1

                                  https://mol.js.org именно то, что вы ищите.

                                    –2
                                    имхо, автор вопрос ставит не верно.

                                    без полновесной системы метаданных, увязывающей как бд так и шаблонизатор — не выйдет, имхо.
                                    а это задача куда больше чем «фреймворк для генерации формочек».

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

                                    при этом этот «механизм построения формочек» должен еще уметь расширять бизнес логику работы этой самой формы — под различные варианты алгоритмов валидации.

                                    и это еще не обсуждены вопросы реструктуризации бд и гуи, когда у вас изменятся структуры данных.

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

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

                                    из того что связывает «воедино фронт и бек» вспоминается только 1с и qt (которые могут собрать приложение и в виде сервера с веб формой управляемой через вебсокет. но у qt нет метаданных связанных с орм и генерацией гуи. собственно, и орм то в свое время для qt я писал сам)

                                    не стоит этого ждать решений такого рода от массовых фреймворков заточеных под массовый веб-js-девелопмент «бложеков и вконтактиков» и потому, что эта область просто не содержит задач такой сложности — требующей генерации интерфейса работы с данными. потому не ищите js-фреймворков.
                                    не под автоматизацию бизнес-процессов они все заточены.

                                    т.е. все они «муссируют» идею массового веба, простых процессов и максимальной разгрузки сервера с выносом бизнес процессов на клиента. именно в этой области работают большая часть тех, кто голосует «фреймворк не нужен, учитесь пользоваться тем что дают»)) и не стоит удивляться что таковых в пересчете на число душ — большинство.

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

                                    и вам, имхо, надо искать решение в этой области, когда у вас нет массового доступа к системе, сложные бизнес процессы со сложной валидацией данных.

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

                                    теперь что есть: из схожего — есть изделия «кровавого интерпрайза» от hp / ibm / etc, но с этими монстрами встречаться не хочется. костылей там много, и это что ни на есть тот самый кровавый интерпрайз который тянется из ранних эпох становления веб-интерфейсов и даже самих идей работы с метаданными.

                                    из менее крового и достаточно функционального — идейно смотрите на систему метаданных 1С, аналогов которой имхо, все таки ни у кого нет. даже той системы метаданных какая была в 7.7.
                                    к достоинствам 1С скажу что часто вознкают учетные задачи и вот чего точно не хватает в java-фреймворках — это не только их системы метаданных, но и их учетных механизмов — тех-же регистров.

                                    я бы очень хотел видеть такое например в java но увы, ничего кроме собственных наработок нет, а публиковать наши фрейворки мы не будем как минимум еще полгода, тем более бесплатно.
                                    и до 1С мы во многом не дотягиваем, хотя нам пока вроде хватает — мы освоили метаданные, орм, основы автогенерации форм, шаблонизацию, работу с клиентом и с генеренными формами и тп.

                                    но т.к. это не будет публично еще какое то время — потому, увы — «пилите сами», тем более если на go. смотрите как работает механизм метаданных в 1С и думайте как это увязать в классическую клиент серверную архитектуру. у меня на то что бы получить более-менее стройный вариант для веб — ушло несколько попыток. и несколько лет )

                                    ну вот как-то так.)

                                      +3
                                      Не согласен, что системах, которые ищет автор, должен быть ОРМ и вообще они что-то должны знать о хранилище. Если и должна быть какая-то генерация кода для сервера из общих с фронтом метаданных, то она должна остановиться на генерации DTO и возможности его провалидировать. Как обрабатывать валидные DTO — полная ответственность бэка.
                                        0
                                        Вы это все к чему?
                                          0
                                          без полновесной системы метаданных, увязывающей как бд так и шаблонизатор — не выйдет, имхо.
                                            0
                                            Сорян, это у меня в мобильном приложении высветилось будто вы ответ дали на мой коммент где об этом вообще речи не было. В прилаге Хабра комменты часто бажут. (((
                                          0
                                          вот вы тоже противопоставляете фронт и бек))

                                          и я не говорил что классический фронт должен что то знать о том как классический бек хранит информацию или наоборот. они по прежнему могут делать это без оглядки друг на друга, но что бы синхронизировать и сработаться — им нужна третья сторона. в обычном программировании роль синхронизатора выступает архитектор/разработчик с его «высшим пониманием», в системах с метаданными — записи метаданных (а архитектор/разработчик в идеале изменяет уже только метаданные)

                                          сервер по прежнему отвечает за корректность обработки. а фронт за корректность отображения.

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

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

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

                                          ps: отмечу, что, идея о том, что объект должен сам уметь себя хранить в бд — она валидна только для отдельных архитектур (простите не помню названия этого подхода).
                                          например — скажите — откуда объект должен знать как ему собирать или размещать себя в хранилище типа datavault? это ответственность хранилища, точнее орм, который знает правила «трансляции» записей метаданных на «физику» хранилища.

                                          pps: и да, я не говорю что ваш подход и ваши идеи плохи. я говорю о том, что есть спектр ситуаций, в которых ваши подходы будут работать не так хорошо и давать совокупный результат хуже, чем системы, которые не соответствуют вашим идеям об архитектуре.
                                          и, естественно, наоборот: системы с метаданными и автогенерацией нет смысла применять на вебсайтах. но мы же сейчас обсуждаем автогенерацию форм.
                                            –1
                                            Я к тому, прежде всего, что форма — самодостаточный инф. объект в системе, особо от других объектов независящий и чаще всего не требующий хранения в базе или ещё где. Отправка формы на бэк — это не создание или изменение каких-то связанных объектов, а создание на бэке временного объекта «форма» и её дальнейшая обработка. UserForm ничего не знает об User, а он о форме. Об обоих знает какой-то UserFormHandler, который может тупо 1:1 копировать данные формы в «настоящий» объект и с помощью ORM сохранять его, а может делать что-то совершенно другое. Но фронта это никак не касается, он от объекта User изолирован полностью.
                                              0
                                              Давайте ещё раз проговорим)

                                              мы же, в контексте топика не о «классических подходах», а говорим в первую очередь о _генерации_ форм?

                                              т.е.продолжая термины вашего примера — у вас не будет никакого UserForm.
                                              У вас будет AutoGeneratedForm. один на всех.

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

                                              Хотите — передавайте ей User, хотите — AccountingYearReport, хотите — OperationLogElement — она сама перестроится и отобразит это на экране.

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

                                              Теперь к вам вопрос: каким образом реализовать такую систему?

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

                                              И над сущностями User/AccountingYearReport/OperationLogElement и над AutoGeneratedForm висит «домокловым мечом» система метаданных, которая по мере необходимости дает и той и другой стороне (и фронту и беку) необхоимую информацию о том, как работать с передаваемой сущностью.

                                              детали реализации — будет у вас хендлер или что то ещё, будут у вас метаданные храниться в объекте или централизованно — это уже не важно. Важно что и информационная сущность, и форма синхронизируются (или сопоставлены если хотите) через третью сущность — метаданные.

                                                0
                                                Генерация бывает разной. У нас может быть UserForm.yaml с метаданными и автоматически сгенерированные UserForm.js, UserForm.go и т. п. Обычно что-подобное имеют в виду, когда говорят об генерации.

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

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

                                                  хотя это тоже вариант. работаем же с «wsdl-вебсервисами» в джаве аналогичным образом ?))) работаем.

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

                                                  так же, мне не нравится сама идея «форм собираемый в компайл тайм», хотя бы потому, что много с этим наелись в jsf. не самый элегантный, имхо подход, но для своего времени и многих областей — пригодно.

                                              –4
                                              не делаете орм в беке, который по метаданным умеет сохранить объект в бд

                                              Если использовать не реляционную, а объектную субд, то и Объектно-Реляционный Маппинг и не потребуется.

                                                +1
                                                с объектно ориентирвоанными БД тоже много засад. правильная объектная БД должна уметь валидировать объекты которые ей подсовывают.

                                                т.е. в идеальном варианте — например поддерживать механизм типа XSD или хотя бы на крайний случай JSON Schema или им подобным.

                                                Если она не делает этого, то эти вопросы потребуется решать вам, в вашей сситеме.

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

                                                но если у вас объхектная СУБД не умеет валидировать данные (как например очень популярная легковесная MongoDB), а пишут в эту БД несколько систем, особенно если они от разных команд или производителей — то вы рано или поздно получите проблему когда вы с вашими коллегами ассинхронизируетесь в понимании как разбирать структуры в вашей бд.

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

                                                Если вам интересны примеры — сошлюсь на проект разработки первой версии ЕГРН для Росреестра давностью года 3 назад. Тамошние/тогдашние подрядчики создали именно такую ситуацию — в могно-дб лежали настолько разношерстные данные, что написать бота, который бы вытащил из этой БД хоть какие-то полезные данные было совершенно невозможно. и произошло это, по моей версии, как раз из за того что писали данные туда 2 системы, структуры данных развивались, а сама монго-дб не умела хоть как-то вализировать присылаеый ей мусор.

                                                — ну так вот. я к тому, что метаданные для объектно ориентирвоанных БД или ОРМ которые скрывают работу с объектными БД — тоже нужны.
                                                Только играют они иную роль и по другому выглядят, по другому называются.

                                                XSD, Json-schema и тп — становятся неотъемлемой частью системы метаданных если вы используете объектныю бд на больших долгоживущих проектах.
                                                  0
                                                  То, что вы описываете, называется «документная СУБД», «объектная СУБД» — это совсем другое, и там схема обычно присутствует.

                                                  Проблема объектных СУБД в другом — конкурировать по скорости с реляционными они не могут.
                                                    0
                                                    Почему это не могут?
                                            0
                                            Развитое ООП решает вопрос с метаданными, где сам класс является единицей метаданных, и сам умеет сохранять себя в БД. Это пока не очень популярно, после провала объектных БД, еще MVC рулит, но все к этому пониманию медленно возвращаются.
                                              +1
                                              на один ооп язык не предоставляет вам информации о том, как надо отображать объект.
                                              потому вам надо что то дополняющее те метаданные которые вы можете вытащить например через рефлекшен в java, через систему метаданных в Qt или другие механизмы в вашем языке.

                                              например вам надо отображать поле с типом Integer. какой контролс следует использовать системе генерации «формы редактирования по умолчанию» — поле ввода с калькулятор-дроп-дауном, поле со стрелочками вверх-вниз как в хроме, или может быть скроллер для повышения визуальности? где указать допустимые для ввода границы что бы еще на этапе ввода отсечь нежелательные значения?

                                              метаданные синхронизируют в этих вопросах поведение универсальных механизмов MVC. метаданные, если можно так сказать, выступают 4м элементом, которые позволяют в одном месте указать информацию которой будут пользоваться и «модель», и «контроллер», и «вид». они по прежнему отвечают каждый за свое как и надо в модели MVC, но универсальные механизмы имеющиеся в каждой из этих частей, используют информацию из метаданных для того, что бы работа была синхронизированна.

                                              можедь знала что надо обработать поле с числом типа int, контроллер что надо позволять только отрицательные числа от 0 до -20, а вид — что надо использовать дропдаун с выбором значения.

                                                –1
                                                Про «ни один ООП язык» — это вы зря, в дарте сделано, да и на JS можно. Смотрите на объект шире — это самостоятельная и живучая сущность, которая сама о себе заботится (CRUD), и сама себя презентует (генерируя HTML/CSS). Если у вас желудок и мозг в пределах одного тела, то почему вы объект пытаетесь разрезать на искусственные сущности контроллер и вью? Я знаю, что мнение непопулярно, но можем вернуться к спору через 10 лет, когда MVC умрет, а ООП будет переосмысленно (строго ИМХО).
                                                  0
                                                  вы говорите что «на js можно поместить в объект информацию о том как его отображать» — я же правил но вас понимаю?

                                                  тут 2 момента.
                                                  1) вы по сути подтверждаете мой тезис о том, что сам по себе ооп-язык не предоставляет механизмов и правил описания как отображать данные.
                                                  2) вы говорите про детали реализации, которые распределяют задачи функциональных подсистем на программные классы систем.
                                                  действительнь — почему бы не разместить в объекте его собственный кусочек метаданных, и отнаследовать откуда то кусочек для орм, который дает объекту самому сохраняться в хранилище — почему нет? это не более чем детали реализации тех же сущностей о которых я говорю: объект и метаданные.

                                                  только система метаданных у вас организована так, что каждый объект «знает о себе всё».
                                                  и я так делал. так был построен мой орм для qt.

                                                  но когда мне потребовалось реализовать вариативный орм который имел бы одинаковый н ерфейс и для 3nf бд и для datavault — я использовал другую идеологию.

                                                    0
                                                    Я понял проблему. Если нужна вариативность вывода HTML или интерфейса к БД, понятно, нужно применять что-то типа паттерна фасад, или там прокси. Стандартно это делают отдельным компонентом (собственно view или model), но есть и другой подход — если все ваши объекты унаследованы от одного предка — достаточно прокси реализовать в этом предке, и весь ваш фасад будет вызовом super(). Это извечный спор о том что лучше — композиция vs наследование, или там микросервисы vs монолит. Конечно, композиция гибче, но монолит предсказуемей и управляемей. И самое главное — в моем случае метаданные тоже могут наследоваться!
                                              0
                                              У автора (по крайней мере из статьи вырисовывается) нет хорошего понимания о том, что ему нужно — а соответственно, объем работ тут точно так же очень неопределен. У автора есть запрос на «просто», но нет строгого описания (а значит и понимания, скорее всего), что в это «просто» должно входить.
                                              Но это даже не обсуждается, что «фреймворку для генерации формочек» потребуется дополнительная информация — из чего же он эти формочки нагенерит иначе? И заострять внимание именно на этом — ну фиг знает, по-моему излишне. Это и так подразумевается, как например запрос «построить график» подразумевает, что есть данные, по которым его можно строить.
                                                0
                                                Странно, почему минусуют этот комментарий.
                                                На мой взгляд комментарий по делу:
                                                1. просто фронт нарисовать — поверхностное решение. Желательна поддержка бэка.
                                                В фронт должна идти масса информации от бэка и метаданных: типы данных, формат, валидации. Эта информация уже определена на бэке, так почему ее не транслировать на фронт?
                                                2. аналогично с автором комментария, у меня на решение ушло в общей сложности 8+ лет и сейчас финальная, 4-я редакция, которая основана на метаданных и покрывает фронт и бэк.
                                                Это охрененное количество работы и денег, с подключением экспертов из разных областей.
                                                  +1
                                                  Комент хороший, но все ж от задачи зависит, у меня например такая была — автономное PWA мобильно-десктопное приложение с локальной БД, и периодической синхронизацией с сервером. Бэка по сути нет вообще, вся валидация и первичное хранение на клиенте, при появлении интернета — простая JSON-репликация по сокету — и нафига мне тут фреймворк с метаданными? А те кто минусуют — может они просто энтерпрайза не видели, и воспринимают 1С как магию…
                                                0

                                                есть ещё devextreme — формочки, и вполне себе декларативно.
                                                причем под кучу фреймворков сразу
                                                правда есть два "но":


                                                1. платно
                                                2. полностью от написания html не избавят
                                                  0
                                                  Если я все правильно понял, то более всего вашему подходу соответствует pureqml.com
                                                    –2
                                                    Пока web, будет выглядеть вот так
                                                    <...>
                                                    </...>
                                                    он не перестанет вызывать у меня изжогу, ничего отвратительнее не видел(
                                                    WPF по этой причине долго не мог поднять для себя. Но кодируя контролы в самом коде, как то переборол эти тэги, а потом и вовсе смирился с ними. Но к HTML отношение ни капли не поменялось.
                                                      0
                                                      Предложите лучший вариант описания интерфейса. На SQL столько лет плевались, а все равно ничего лучше не придумали.
                                                        0
                                                        Вариантов описания интерфейса куча, в частности, почему бы не быть ему как в Ammy
                                                        SQL читается как роман по сравнению с тегами:) А все что рябит в глазах, это зло.
                                                          0
                                                          Я на эту тему как-то тут спорил, говорил что JSON лучше XML потому что рябит меньше, но товарищи верстальщики меня решительно поправили — закрывающие тэги удобнее, чем каскад закрывающихся скобок, так как видно что конкретно закрывается. Возможно, они даже правы, хотя конечно на JS удобнее описывать поведение, ибо лямбды внутри HTML смотрятся как-то чужеродно. Так что частично с Вами согласен, но браузеры как и страну не выбирают…
                                                            –1
                                                                    </treeLevel>
                                                                  </treeLevel>
                                                                </treeLevel>
                                                              </treeLevel>
                                                            </treeLevel>

                                                            Ну да. Прям видно. Прям нагляднейше. Ни за что бы не подумал, но раз эксперты говорят… ;)
                                                      +1
                                                      const response = {
                                                          "main": {
                                                              "prop":{},
                                                              "elements": [
                                                                  {
                                                                      "type":"checkbox",
                                                                      "name":"Использовать что-то",
                                                                      "style":"classic",
                                                                      "checked": true
                                                                  },
                                                                  {
                                                                      "type":"button",
                                                                      "name":"Сохранить",
                                                                      "style":"outline",
                                                                      "onclick":"btnsave_onclick"
                                                                  }
                                                      
                                                          }
                                                      };
                                                      const domArray = response.main.elements.map(elInfo => {
                                                          const domEl = document.createElement(elInfo.type);
                                                          return Object.keys(elInfo).reduce((el, key) => {
                                                              if (key === 'type')  return el;
                                                              el.setAttribute(key, elInfo[key]);
                                                              return el;
                                                          }, domEl);
                                                      };
                                                      


                                                      полученный массив вставляем куда надо. Фреймворка такого нет потому что никто не будет десять строк оформлять во фреймворк.
                                                        +2
                                                        полученный массив вставляем куда надо

                                                        Лейаута нет, где должна быть логика (обработчики) — непонятно, и т.д.
                                                        Ваши 10 строк просто позволяют хранить HTML в JSON. Нужно это примерно никому (зачем хранить HTML где-то еще, если можно хранить его прямо так?), поэтому и не оформляют.
                                                          0
                                                          как задача поставлена — так она и решена. Безотносительно рациональности самой задачи.
                                                            0
                                                            У него же не JSON, а объект JS, там можно и функции хранить, и вставлять вызовы при генерации разметки, нормальный подход.
                                                              –1
                                                              предполагается что response пришел по сети, то есть все таки json, но функции так можно передавать, главное что бы они были автономными (то есть все используемые в них символы — либо глобальны для js либо приходят в параметрах). Прикручивается при помощи еще пары строк. + еще пара строк — и можно сделать elements рекурсивными, то есть отражать в них вложенные элементы. Не стал этого писать потому что смысла нет, так же как и (на мой взгляд) смысла в поставленной задаче. Есть html templates/jsx/tsx, есть custom elements/react/vue/angular, в общем куча инструментов работающих на уровне view, выбирай на любой вкус. И вопрос декларативности на любом выбранном инструменте решается таким же десятком строк что я привел.
                                                                0
                                                                Спасибо, понятно. Я не поклонник фреймворков по одной причине, о которой вчера как раз думал — а именно производительность. Вообще-то браузеры идеально оптимизированы для отображения HTML, но на каком-то этапе сообщество решило генерировать DOM из скриптов, причем по одному элементу, по сути перестав использовать нативный язык описания интерфейса — HTML. Хоть Дарт, хоть Реакт — везде компоненты добавляются прямо в DOM, и фреймворки сразу попали в ловушку низкой производительности, которую сами и создали. В результате пришлось изобретать виртуальный DOM, единое состояние redux и прочие костыли. Я провел эксперимент, и пришел к выводу, что возвращение к текстовому HTML (в частности insertAdjacentHTML) улучшает производительность в десятки раз. После этого я охладел к объектному подходу, и по прежнему генерирую большие куски HTML в виде текста. Эта ситуация очень похожа на судьбу объектных оберток поверх SQL, которые тоже тормозят, и в высоконагруженных системах не используются. Впрочем, об этом надо статью писать, но лень.
                                                                  –1
                                                                  Попробуйте на чистом html вставить в каждую ячейку селект на сотню-другую опций.
                                                                    0
                                                                    Какая-то гипотетическая ситуация. Зачем в каждую-то, может только в активную, и то после набора первой буквы? В моем примере в дрилл выводиться до 50 тысяч строк таблицы, одним куском HTML, а для редактирования нужно просто кликнуть на ссылку. Если бы я все делал через DOM — ждал бы до утра.
                                                                      0
                                                                      Вы только не забывайте, что с «гипотетической ситуации» вы сами начали.
                                                                      В браузере в 99.8% случаев не надо выводить таблицы на десятки тысяч строк. Браузер, как чисто презентационный движок — работает с такими объемами информации, с которыми удобно работать человеку. За подавляющим большинством ситуаций а-ля «я фигачу в HTML таблицы на 100500 экранов размером и чёт они у меня тормозят» стоит банальное неумение построить UI с более адекватным охватом, или же в крайнем случае — организовать разбивку на части.

                                                                      Да, есть и 0.2% случаев, где безумные объемы данных в браузере таки нужны одним куском. И да, в этих случаях вам действительно не стоит брать реакт, да и вообще по большей части и JS брать тоже не стоит. Но эти случаи мягко говоря нишевые.
                                                                        0
                                                                        Зачем в каждую-то, может только в активную, и то после набора первой буквы?

                                                                        Затем, что нативный селект не умеет ни в ленивый рендеринг, ни в фильтрацию. И вот, нам уже нужен кастомный контрол и фигурная работа с DOM, чтобы при ререндере селекта он не закрывался.

                                                                          0
                                                                          Поэтому никто в автоподборе и не использует select, менюшка прекрасно на nav position absolute делается. Согласен, это отдельный custom element, и ни одного фреймворка.
                                                                            0
                                                                            Прекрасно ровно до тех пор пока вам не надо динамически менять содержимое менюшки, чтобы она могла выпадать за пределы окна браузера, чтобы она позиционировалась так, чтобы не вылезать за границы экрана. И куча других совсем не прекрасных вещей.
                                                                              0
                                                                              Я согласен, гемор, хотя сейчас с появлением viewport-единиц вычисление размеров и позиций стало проще, но кроссбраузерности по прежнему нет :(
                                                                      0
                                                                      >Хоть Дарт, хоть Реакт — везде компоненты добавляются прямо в DOM, и фреймворки сразу попали в ловушку низкой производительности, которую сами и создали.

                                                                      Я прикручивал биндинги к custom elements — получается тот же реакт только без головняков по оптимизации рендеринга, этим занимается броузер и не надо велосипедить. Небольшой проект по работе запустил — полет нормальный. Но средние и больше проекты не рискую переводить на эти рельсы — для народа выглядит непривычно, тим лидер смотрит на меня настороженно :)
                                                                        0
                                                                        Шикарно, я тоже стараюсь использовать последние стандарты. Одна проблема — на старых андроид-браузерах даже классы и модули JS не поддерживаются, и эти браузеры никак не обновить, поэтому видимо и менеджеры косятся. Слава богу хоть IE с Эджем сдохли.
                                                              0
                                                              Что-то похожее, только фулстек, мы с напарником делали года три-четыре назад для себя — getblank.net. Декларативно определяем схему, по которой строится и фронт и бэк.
                                                              Описание с докой не самые актуальные сейчас, т.к. никому кроме нас эта платформа оказалась не интересной, зато сами мы немалое количество проектов выполнили с её помощью.

                                                              В данный момент идёт переосмысление проекта, т.к. оказалось, что излишняя гибкость заложена, что привело к усложнению всего.
                                                                0
                                                                Это судьба таких проектов — для себя только и используется. А другой пилит свою ферму, так как о вашей не знает, ведь трудозатраты написать самому vs разобраться в чужом — сопоставимы. И только фейсбук может нагнуть всех силой своего бренда.
                                                                0
                                                                Любопытная статья.
                                                                Фреймворк не встречал, но последние 3 года разрабатываем командой похожее решение.
                                                                Результат более сложный, чем описанный в статье, но некоторые части аналогичны:
                                                                1. библиотека элементов (UI Elements), аналог бэмовых Element
                                                                2. из UI Elements строятся reusable Page Elements, аналог бэмовых Block
                                                                3. из блоков формируется веб-приложение

                                                                В добавок (малая толика из возможностей):
                                                                1. библиотека UI Elements расширяемая и хранится в базке с соблюдением нормальных форм
                                                                2. каждый UI Element описывается через набор: свойств, методов, событий
                                                                3. серверная часть также генерится на базе метаданных и позволяет начитывать и сохранять данные
                                                                4. на клиентской и серверной части возможны вставки custom code
                                                                5. безопасности уделено особое значение — все контролы, действия, кастомные коды контролируются role-based security system.
                                                                6. динамическая компиляция серверного custom code и подгрузка к приложению
                                                                7. динамическая компиляция daemons (windows services) и deployment на удаленные серверы
                                                                8. динамическое создание AWS Lambda и deployment на AWS
                                                                9. самое важное: веб-приложение позволяет создавать и модифицировать себя-же, не обращаясь к средам разработки. Звучит утопично, но это так.
                                                                10. 2-х уровневое кеширование серверной части (L1 на уровне запроса и L2 на уровне среды с учетом LB deployment)
                                                                11. ядро среды написано на .Net из VS и содержит крайне мало кода. В основном — метаданные для описания базки, таблиц, колонок, триггеров, индексов, SP, UI Elements, Page Elements, etc., хранящиеся в базке с соблюдением нормальных форм. Т.е. изменение таблицы, страницы, контрола, etc.

                                                                Крайне неловко писать о незаконченном проекте, но уже сейчас мы разрабатываем большую часть функционала из самой среды, не модифицируя ядро.
                                                                Может кого-нибудь такой подход заинтересует.
                                                                Пишите в личку, буду рад поделиться
                                                                Пример UI: ibb.co/hB8Vp2G
                                                                  0
                                                                  Выглядит интересно. Я смотрю вы тоже выбрали буклетный дизайн (горизонтальный стек панелей), чтобы приложение имело одинаковый ux что на десктопе, что на мобилке?
                                                                    0
                                                                    Вроде того.
                                                                    Текущая разметка — частный случай ( ibb.co/d6r8dX4 ) и может быть легко изменена.
                                                                    Для мобильной версии проще нарисовать странички с функционалом, специфичным для возможностей и задач мобилки.
                                                                  0

                                                                  Я вот одного не могу не понять зачем что то придумывать если есть https://github.com/formio


                                                                  ??

                                                                    0
                                                                    dhtmlx.com/docs/products/dhtmlxSuite

                                                                    Позволяет писать декларативно описывая компоненты через  json, xml.
                                                                      0
                                                                      Использовал в ранних редакциях. Много унаследованных проблем.
                                                                      У XB есть новая версия — Webix.
                                                                      Перешел на Webix и результат значительно лучше.
                                                                      0
                                                                      В свободное время писал такой фреймворк. На собеседованиях всегда просят показать примеры кода, вот и показываю.
                                                                      www.youtube.com/watch?v=NYqVYc1du3Y

                                                                      Потрогать можно тут
                                                                      polarspa.coolpage.biz/demo.html
                                                                        0

                                                                        Ох ёпрст ) намолотили тут за день — не ожидал такого интереса.


                                                                        Всем спасибо кто откликнулся! В комментах много интересного. Спасибо за ссылки!


                                                                        По поводу моей нечёткой формулировки того, чего я искал — я имел ввиду, что на входе подаёшь вот такое:


                                                                        {
                                                                            "main": {
                                                                                "prop":{},
                                                                                "elements": [
                                                                                    {
                                                                                        "type":"checkbox",
                                                                                        "id": "checkbox1",
                                                                                        "label":"Использовать что-то",
                                                                                        "style":"classic",
                                                                                        "checked": true
                                                                                    },
                                                                                    {
                                                                                        "type":"button",
                                                                                        "label":"Сохранить",
                                                                                        "style":"outline",
                                                                                        "onclick":"btnsave_onclick"
                                                                                    }
                                                                        
                                                                            }
                                                                        }

                                                                        а на выходе получаешь вот такое (страничку с таким содержимым):


                                                                        Просто визуальщина, всё на простых типах, без бэкэнда. И хотелось OpenSource.
                                                                        И чтоб можно было вот так:


                                                                        {
                                                                           "type":"input-int",
                                                                           "name":"Введите число",
                                                                           "min-val":"1",
                                                                           "max-val":"100",
                                                                           "style":"classic"
                                                                        }

                                                                        Но повторюсь, в комментах накидали всякого, надо смотреть.

                                                                          +1
                                                                          такой синтаксис как раз используется в Webix
                                                                          0

                                                                          Ну если исключительно для форм то есть такая штука как Formly, например для ангуляру это https://github.com/ngx-formly/ngx-formly удобный, настраиваемый.

                                                                            0
                                                                            Вы знаете, при первом знакомстве с Webix появляется мысль, что поиск окончен.

                                                                              0
                                                                              В моем проекте UI на Webix.
                                                                              Начал работу с Webix в 2013, когда он был еще на стадии беты.
                                                                              Согласен, хороший framework, но допиливать пришлось каждый контрол.
                                                                                0
                                                                                А нет. Показалось. Попробовал редактор форм — сам размещать похоже не умеет. Нужно руками задавать визуальные параметры контролов (ширину, и т. п.).
                                                                                  +1
                                                                                  Вполне умеет, только не пользуйтесь редактором форм.
                                                                                  Лучше Snippet. Им пользуются для демонстрации proof of concept и траблшутинга.
                                                                                  Редактор форм не очень удачен, пусть он вас не сбивает с пути к Вебиксу. :)
                                                                                    0
                                                                                    Спасибо. Обязательно попробую.
                                                                                      +1
                                                                                      Хм… всё равно как-то не круто. Смотрите, вот код:

                                                                                      webix.ui({
                                                                                          view:"form",
                                                                                      	elements: [
                                                                                      	    {
                                                                                      	        view: "text",
                                                                                      	        label: "Код"
                                                                                      	    },
                                                                                      		{
                                                                                      	        view: "text",
                                                                                      	        label: "Наименование"
                                                                                      	    },
                                                                                      	    {
                                                                                      	        label: "Записать",
                                                                                      	        type: "form",
                                                                                       	        view: "button",
                                                                                      	      	width: "150",
                                                                                      	      	align:"right"
                                                                                      	    }
                                                                                      	]
                                                                                      });
                                                                                      


                                                                                      Вот результат:


                                                                                      Ну чтооо такое… ширина надписей — это просто константа. Чтобы увидеть весь текст, необходимо прописать в каждый элемент явно ширину надписей. Для этого нужно знать ширину самой широкой строки.

                                                                                      Можно конечно вот так попробовать:

                                                                                      webix.ui({
                                                                                          cols:[
                                                                                              {
                                                                                                  view:"form", elements:[
                                                                                                      {
                                                                                                        label: "Код",
                                                                                                        view: "label"
                                                                                                      },
                                                                                                      {
                                                                                                        label: "Наименование",
                                                                                                        view: "label"
                                                                                                      }
                                                                                                  ]
                                                                                              },
                                                                                              {
                                                                                                  view:"form", elements:[
                                                                                                      {
                                                                                                        view: "text"
                                                                                                      },
                                                                                                      {
                                                                                                        view: "text"
                                                                                                      },
                                                                                                      {
                                                                                                          label: "Записать",
                                                                                                          type: "form",
                                                                                                          view: "button",
                                                                                                        	width: "150",
                                                                                                        	align:"right"
                                                                                                      }
                                                                                                  ]
                                                                                              }
                                                                                          ]
                                                                                      });
                                                                                      


                                                                                      Но всё равно, как-то не особо стало лучше:



                                                                                      Между надписями и полями ввода куча пустого пространства. Если убрать кнопку, то колонки становятся равными и снова остаётся место. В данном случае, возможно, должен быть какой-то автоподбор ширины колонки по содержимому, но в документации про это упоминаний не обнаружил.

                                                                                      Если столько манипуляций нужно произвести с простой формочкой на два поля ввода, то что же там дальше?
                                                                                        +1
                                                                                        Форма значительно проще:
                                                                                        snippet.webix.com/r8qu5eds

                                                                                        webix.ui({
                                                                                        cols:[
                                                                                        { view:«form»,
                                                                                        elementsConfig:{labelWidth: 130},
                                                                                        elements:[
                                                                                        {
                                                                                        view: «text»,
                                                                                        label: «Код»
                                                                                        },
                                                                                        {
                                                                                        view: «text»,
                                                                                        label: «Наименование»
                                                                                        },
                                                                                        {
                                                                                        view: «button»,
                                                                                        label: «Записать»
                                                                                        }
                                                                                        ]
                                                                                        },
                                                                                        ]
                                                                                        });
                                                                                          0

                                                                                          Спасибо. Я говорил как раз про необходимость этой строчки, что хотелось бы без неё:


                                                                                          elementsConfig:{labelWidth: 130}, 

                                                                                          Скажите, а зачем в данном случае заворачивать в "cols"?
                                                                                          Форма нарисуется и так:


                                                                                          webix.ui({
                                                                                            view:"form",
                                                                                            elementsConfig:{labelWidth: 130}, 
                                                                                            elements:[
                                                                                              {
                                                                                                view: "text",
                                                                                                label: "Код"
                                                                                              },
                                                                                              {
                                                                                                view: "text",
                                                                                                label: "Наименование"
                                                                                              },
                                                                                              {
                                                                                                view: "button",
                                                                                                label: "Записать"
                                                                                              }
                                                                                            ]
                                                                                          });

                                                                                          … вообще прикольный фреймворк.

                                                                                0
                                                                                хотелось бы без неё
                                                                                Без проблем, но тогда в каждое поле прописывать ширину label.
                                                                                а зачем в данном случае заворачивать в «cols»
                                                                                Такова полная структура. На случай, если нужно отображать несколько ячеек вертикально или горизонтально. Вы привели упрощенную структуру со значением (cols) по умолчанию.
                                                                                Ниже пример:
                                                                                snippet.webix.com/plth3ogb
                                                                                Думаю, наш диалог выходит за рамки статьи.

                                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                Самое читаемое