Comments 94
Если вы захотите эти автогенерируемые формы гибко настраивать (цвет там, шрифт, положение и пр.), то абстрагировать HTML+CSS, хотя это не даст уменьшения количества информации, я не вижу смысла.
Если не боитесь безликого типового внешнего вида, то это довольно несложно и самому сделать, даже на базе обычного Go'шного html/template.
А вообще рекомендую взглянуть на экосистему Clojure/Clojurescript и библиотеку re-frame.
Если не боитесь безликого типового внешнего вида, то это довольно несложно и самому сделать, даже на базе обычного Go'шного html/template.
А вообще рекомендую взглянуть на экосистему Clojure/Clojurescript и библиотеку re-frame.
UFO just landed and posted this here
Долгие поиски решения задачи подобной вашей, что успешно завершились Ruby on Rails + EmberJS (ember-paper). Это просто супер кайф от разработки и производительность, после VueJS, ReactJS и тем более Angular. Минимум пишешь, максимум получаешь. Сорян если, кто не пробовал… я все перепробовал… увы...
На golang веду мелкий микросервис, большое приложение не советовал бы. ...
Такого фреймворка нет, и он не появится. В подобных вещах появляется смысл только на более узком пространстве задач (я сейчас по долгу службы как раз один такой пишу, именно для узкого пространства, с получением профита через стандартизацию отдельных мест).
«Фреймворк для генерации UI» — именно в таком, максимально широком виде — это всё те самые HTML+CSS+JS. Генерируй себе по самое нехочу. Когда появляется желание на чем-то сэкономить и уменьшить сложность — нужно очень четко представлять, что именно вы хотите сэкономить, и где конкретно уменьшить сложность; потому что каждое уменьшение сложности — это еще и сокращение функционала, уменьшите не там — получите прикольную бесполезную штуку, с помощью которой попросту нельзя сделать то, что вам хочется.
Вам нужно генерировать формочки? Это задача типичного кровавого энтерпрайза, которую на голом энтузиазме вряд ли кто-то кинется решать. Вам остаётся либо написать это самому, либо заплатить тому, кто напишет. Вон, вы уже нашли 1Сников, которые для 1С формочки генерят, заинтересуйте их — и, думаю, они вам и в общем виде напишут, без привязки к 1С.
«Фреймворк для генерации UI» — именно в таком, максимально широком виде — это всё те самые HTML+CSS+JS. Генерируй себе по самое нехочу. Когда появляется желание на чем-то сэкономить и уменьшить сложность — нужно очень четко представлять, что именно вы хотите сэкономить, и где конкретно уменьшить сложность; потому что каждое уменьшение сложности — это еще и сокращение функционала, уменьшите не там — получите прикольную бесполезную штуку, с помощью которой попросту нельзя сделать то, что вам хочется.
Вам нужно генерировать формочки? Это задача типичного кровавого энтерпрайза, которую на голом энтузиазме вряд ли кто-то кинется решать. Вам остаётся либо написать это самому, либо заплатить тому, кто напишет. Вон, вы уже нашли 1Сников, которые для 1С формочки генерят, заинтересуйте их — и, думаю, они вам и в общем виде напишут, без привязки к 1С.
Для некрофилов есть ExtJS
Всё еще живет и процветает в энтерпрайз среде RIA приложений
Надеюсь они уже подвезли что-то новое. Т.к. полтора года назад ситуация была печальная: он платный + ES5.
Уже есть GPL и ES6 :)
GPL был сначала для всех версий, потом только для мажорных, а сейчас дикая Community Edition.
Мне понравился webix.
Есть редактор форм.
Есть редактор форм.
Удваиваю вебикс. Часто он «просто работает». Конечно, если нужно что-то сильно кастомное — никаких фреймворков.
все же помнят что он НЕ бесплатный?)))
а то у нас тут один разработчик воткнул вебикс «просто потому что он работает», и очень сильно обижался что я его заставил выпилить это изделие из проекта. или заплатить за него из своего кармана. потому что мы не можем установить клиенту не лицензионное ПО, а 2500-4000 американских денег в бюджете проекта на вебикс у нас на тот момент не было.
хотя да, выглядит он не плохо.
а то у нас тут один разработчик воткнул вебикс «просто потому что он работает», и очень сильно обижался что я его заставил выпилить это изделие из проекта. или заплатить за него из своего кармана. потому что мы не можем установить клиенту не лицензионное ПО, а 2500-4000 американских денег в бюджете проекта на вебикс у нас на тот момент не было.
хотя да, выглядит он не плохо.
Автор нашел множество готовых фреймворков (и наверняка их гораздо больше), но они ему чем-то не понравились. В такой ситуации надо продолжать искать дальше, отрабраковывать ещё и ещё, чтобы потом понять, как именно самому нравится и начать велосипедить свой собственный фреймворк. С аутлайнами и фрейлинами.
Webix + NodeJS, а между ними Socket.io
Давным давно, когда я был молодой и неопытный и за доширак клепал сайты визитки, меня тоже посещала мысль о волшебном фреймворке для всяких crud операций — скармливаем ему метаданные а он нам всякие формочки рисует и данные обрабатывает. Был и свой велосипед, и даже сданные пректы на нем. Вот только чем сложнее были проекты, тем страшнее разрастался велосипед, и все-равно он не мог решать задачи оптимальным образом. И я забросил эту затею.
Чем универсальнее и функциональнее решение, тем выше порог входа и сложнее кастомизировать некоторые чамти. Поэтому надо выбирать, что-то среднее.
По вашему описанию не до конца понятно что именно требуется. Если вам действительно окошки — то это скорее к extjs, несмотря на то что это уже позавчерашний день. Если по большей части crud — присмотритесь к react admin. Ну и раз прошли такой большой путь в поисках присмотритесь к классике проверенной временем — django. Не совсем то что вы ищите, но это та самая золотая середина.
Чем универсальнее и функциональнее решение, тем выше порог входа и сложнее кастомизировать некоторые чамти. Поэтому надо выбирать, что-то среднее.
очень согласен с этой частью )
UFO just landed and posted this here
Всё прекрасно отделимо. Просто фейсбук написан на пхп, поэтому они нанимают пхпшников, у которых, за что ни возьмутся, получается пхп.)
UFO just landed and posted this here
Dart тоже писали PHP-шники?
Вы наверно имели ввиду Flutter? Они просто следуют за трендами в этом вопросе.
Я сам честно пробовал, но не получается отделить в нормальном динамическом SPA
Гляньте $mol. Там всё отделено. И есть так желанное вами наследование и переопределение чего угодно.
дарты возникли потому что в js есть тьма нюансов, которые надо помнить.А дарт попытался сделать язык с понятным поведением где не будет столько свободы воли в реализации тех же классов, которые в разработке либ каждый городит как ему кажется правильнее.
UFO just landed and posted this here
https://mol.js.org именно то, что вы ищите.
имхо, автор вопрос ставит не верно.
без полновесной системы метаданных, увязывающей как бд так и шаблонизатор — не выйдет, имхо.
а это задача куда больше чем «фреймворк для генерации формочек».
что бы генерировать типовую форму ввода/просмотра вам надо держать в синхронизации и структуры данных с типами, и описания того как вам это отображать (тупо какой контролс использовать для какого типа и когда), и еще иметь механизм не только построения форм, но и наполнения этих форм данными и получения данных обратно. не говоря про валидацию.
при этом этот «механизм построения формочек» должен еще уметь расширять бизнес логику работы этой самой формы — под различные варианты алгоритмов валидации.
и это еще не обсуждены вопросы реструктуризации бд и гуи, когда у вас изменятся структуры данных.
силами js -фреймворка это все не решить. это должна быть единая связка между серверной системой с метаданными, орм, механизмом генерации и управления гуи, механизмами действующими на клиенте для отображения этой формы.
создать такое «в популярном подходе», когда у тебя есть некий бек с рест-ушками и есть толстый js — принципиально невозможно или крайне затруднительно как по затратам так и идеологически — просто потому бек и фронт в современных «модно-молодежных подходах» к разработке разделяются или даже, по сути, противопоставляются — у вас практически нет производителя который бы все связал в единое целое.
есть плагины гуи-фреймворков для ноды, но это, имхо, больно уж походит на франкенштейна, взаимодействие все равно остается ращорванным рест-сервисами, а генерации гуи по метаданным нет.
из того что связывает «воедино фронт и бек» вспоминается только 1с и qt (которые могут собрать приложение и в виде сервера с веб формой управляемой через вебсокет. но у qt нет метаданных связанных с орм и генерацией гуи. собственно, и орм то в свое время для qt я писал сам)
не стоит этого ждать решений такого рода от массовых фреймворков заточеных под массовый веб-js-девелопмент «бложеков и вконтактиков» и потому, что эта область просто не содержит задач такой сложности — требующей генерации интерфейса работы с данными. потому не ищите js-фреймворков.
не под автоматизацию бизнес-процессов они все заточены.
т.е. все они «муссируют» идею массового веба, простых процессов и максимальной разгрузки сервера с выносом бизнес процессов на клиента. именно в этой области работают большая часть тех, кто голосует «фреймворк не нужен, учитесь пользоваться тем что дают»)) и не стоит удивляться что таковых в пересчете на число душ — большинство.
но помимо массового веб, есть корпоративный веб. который по сути вебом не является. это бизнес системы, а веб-интерфейс у них только как дань моде и доступен он в интранете и только.
и вам, имхо, надо искать решение в этой области, когда у вас нет массового доступа к системе, сложные бизнес процессы со сложной валидацией данных.
именно тут вам часто нужно генерить многие формы автоматически, потому что они типовые: когда у тебя 20 справочников различающихся только атрибутами — рисовать под них формы просмотра, редактирования и т.п. руками — часто тупо геморройно.
теперь что есть: из схожего — есть изделия «кровавого интерпрайза» от hp / ibm / etc, но с этими монстрами встречаться не хочется. костылей там много, и это что ни на есть тот самый кровавый интерпрайз который тянется из ранних эпох становления веб-интерфейсов и даже самих идей работы с метаданными.
из менее крового и достаточно функционального — идейно смотрите на систему метаданных 1С, аналогов которой имхо, все таки ни у кого нет. даже той системы метаданных какая была в 7.7.
к достоинствам 1С скажу что часто вознкают учетные задачи и вот чего точно не хватает в java-фреймворках — это не только их системы метаданных, но и их учетных механизмов — тех-же регистров.
я бы очень хотел видеть такое например в java но увы, ничего кроме собственных наработок нет, а публиковать наши фрейворки мы не будем как минимум еще полгода, тем более бесплатно.
и до 1С мы во многом не дотягиваем, хотя нам пока вроде хватает — мы освоили метаданные, орм, основы автогенерации форм, шаблонизацию, работу с клиентом и с генеренными формами и тп.
но т.к. это не будет публично еще какое то время — потому, увы — «пилите сами», тем более если на go. смотрите как работает механизм метаданных в 1С и думайте как это увязать в классическую клиент серверную архитектуру. у меня на то что бы получить более-менее стройный вариант для веб — ушло несколько попыток. и несколько лет )
ну вот как-то так.)
без полновесной системы метаданных, увязывающей как бд так и шаблонизатор — не выйдет, имхо.
а это задача куда больше чем «фреймворк для генерации формочек».
что бы генерировать типовую форму ввода/просмотра вам надо держать в синхронизации и структуры данных с типами, и описания того как вам это отображать (тупо какой контролс использовать для какого типа и когда), и еще иметь механизм не только построения форм, но и наполнения этих форм данными и получения данных обратно. не говоря про валидацию.
при этом этот «механизм построения формочек» должен еще уметь расширять бизнес логику работы этой самой формы — под различные варианты алгоритмов валидации.
и это еще не обсуждены вопросы реструктуризации бд и гуи, когда у вас изменятся структуры данных.
силами js -фреймворка это все не решить. это должна быть единая связка между серверной системой с метаданными, орм, механизмом генерации и управления гуи, механизмами действующими на клиенте для отображения этой формы.
создать такое «в популярном подходе», когда у тебя есть некий бек с рест-ушками и есть толстый js — принципиально невозможно или крайне затруднительно как по затратам так и идеологически — просто потому бек и фронт в современных «модно-молодежных подходах» к разработке разделяются или даже, по сути, противопоставляются — у вас практически нет производителя который бы все связал в единое целое.
есть плагины гуи-фреймворков для ноды, но это, имхо, больно уж походит на франкенштейна, взаимодействие все равно остается ращорванным рест-сервисами, а генерации гуи по метаданным нет.
из того что связывает «воедино фронт и бек» вспоминается только 1с и qt (которые могут собрать приложение и в виде сервера с веб формой управляемой через вебсокет. но у qt нет метаданных связанных с орм и генерацией гуи. собственно, и орм то в свое время для qt я писал сам)
не стоит этого ждать решений такого рода от массовых фреймворков заточеных под массовый веб-js-девелопмент «бложеков и вконтактиков» и потому, что эта область просто не содержит задач такой сложности — требующей генерации интерфейса работы с данными. потому не ищите js-фреймворков.
не под автоматизацию бизнес-процессов они все заточены.
т.е. все они «муссируют» идею массового веба, простых процессов и максимальной разгрузки сервера с выносом бизнес процессов на клиента. именно в этой области работают большая часть тех, кто голосует «фреймворк не нужен, учитесь пользоваться тем что дают»)) и не стоит удивляться что таковых в пересчете на число душ — большинство.
но помимо массового веб, есть корпоративный веб. который по сути вебом не является. это бизнес системы, а веб-интерфейс у них только как дань моде и доступен он в интранете и только.
и вам, имхо, надо искать решение в этой области, когда у вас нет массового доступа к системе, сложные бизнес процессы со сложной валидацией данных.
именно тут вам часто нужно генерить многие формы автоматически, потому что они типовые: когда у тебя 20 справочников различающихся только атрибутами — рисовать под них формы просмотра, редактирования и т.п. руками — часто тупо геморройно.
теперь что есть: из схожего — есть изделия «кровавого интерпрайза» от hp / ibm / etc, но с этими монстрами встречаться не хочется. костылей там много, и это что ни на есть тот самый кровавый интерпрайз который тянется из ранних эпох становления веб-интерфейсов и даже самих идей работы с метаданными.
из менее крового и достаточно функционального — идейно смотрите на систему метаданных 1С, аналогов которой имхо, все таки ни у кого нет. даже той системы метаданных какая была в 7.7.
к достоинствам 1С скажу что часто вознкают учетные задачи и вот чего точно не хватает в java-фреймворках — это не только их системы метаданных, но и их учетных механизмов — тех-же регистров.
я бы очень хотел видеть такое например в java но увы, ничего кроме собственных наработок нет, а публиковать наши фрейворки мы не будем как минимум еще полгода, тем более бесплатно.
и до 1С мы во многом не дотягиваем, хотя нам пока вроде хватает — мы освоили метаданные, орм, основы автогенерации форм, шаблонизацию, работу с клиентом и с генеренными формами и тп.
но т.к. это не будет публично еще какое то время — потому, увы — «пилите сами», тем более если на go. смотрите как работает механизм метаданных в 1С и думайте как это увязать в классическую клиент серверную архитектуру. у меня на то что бы получить более-менее стройный вариант для веб — ушло несколько попыток. и несколько лет )
ну вот как-то так.)
Не согласен, что системах, которые ищет автор, должен быть ОРМ и вообще они что-то должны знать о хранилище. Если и должна быть какая-то генерация кода для сервера из общих с фронтом метаданных, то она должна остановиться на генерации DTO и возможности его провалидировать. Как обрабатывать валидные DTO — полная ответственность бэка.
Вы это все к чему?
вот вы тоже противопоставляете фронт и бек))
и я не говорил что классический фронт должен что то знать о том как классический бек хранит информацию или наоборот. они по прежнему могут делать это без оглядки друг на друга, но что бы синхронизировать и сработаться — им нужна третья сторона. в обычном программировании роль синхронизатора выступает архитектор/разработчик с его «высшим пониманием», в системах с метаданными — записи метаданных (а архитектор/разработчик в идеале изменяет уже только метаданные)
сервер по прежнему отвечает за корректность обработки. а фронт за корректность отображения.
но откуда им обоим, если не из метаданных, взять информацию об объекте, что бы
1) фронт мог иметь систему генерации форм, способную автомтически сгенерировать форму для отображения любого ифн.объекта в системе?
2) а бек мог корректно это отработать?
я не говорил что фронт должен знать о том, как бек хранит информацию, или бек о том как фронт отображает объект. ответственность не размывается.
я говорю про то что универсальные механизмы и бека и фронта должны уметь обработать объект о котором они буквально секунду назад ничего не знали, и каждый берет необходимую информацию из третьей стороны — метаданные. да, она будет формально на сервере, но она не будет ни мешать работать классическому беку работать с объектом, ни отбирать у него ответственность. она скорее выставляет им обоим — беку и фронту некий реестр требований, по которым они оба должны синхронно жить.
и орм тоже должен участвовать в этом безобразии, ибо если вы делаете только генерацию форм по метаданным, но не делаете орм в беке, который по метаданным умеет сохранить объект в бд — то какой смысл делать метаданные ?- вы замучаетесь руками подтягивать одно к другому при изменении того же атрибутного состава.
ps: отмечу, что, идея о том, что объект должен сам уметь себя хранить в бд — она валидна только для отдельных архитектур (простите не помню названия этого подхода).
например — скажите — откуда объект должен знать как ему собирать или размещать себя в хранилище типа datavault? это ответственность хранилища, точнее орм, который знает правила «трансляции» записей метаданных на «физику» хранилища.
pps: и да, я не говорю что ваш подход и ваши идеи плохи. я говорю о том, что есть спектр ситуаций, в которых ваши подходы будут работать не так хорошо и давать совокупный результат хуже, чем системы, которые не соответствуют вашим идеям об архитектуре.
и, естественно, наоборот: системы с метаданными и автогенерацией нет смысла применять на вебсайтах. но мы же сейчас обсуждаем автогенерацию форм.
и я не говорил что классический фронт должен что то знать о том как классический бек хранит информацию или наоборот. они по прежнему могут делать это без оглядки друг на друга, но что бы синхронизировать и сработаться — им нужна третья сторона. в обычном программировании роль синхронизатора выступает архитектор/разработчик с его «высшим пониманием», в системах с метаданными — записи метаданных (а архитектор/разработчик в идеале изменяет уже только метаданные)
сервер по прежнему отвечает за корректность обработки. а фронт за корректность отображения.
но откуда им обоим, если не из метаданных, взять информацию об объекте, что бы
1) фронт мог иметь систему генерации форм, способную автомтически сгенерировать форму для отображения любого ифн.объекта в системе?
2) а бек мог корректно это отработать?
я не говорил что фронт должен знать о том, как бек хранит информацию, или бек о том как фронт отображает объект. ответственность не размывается.
я говорю про то что универсальные механизмы и бека и фронта должны уметь обработать объект о котором они буквально секунду назад ничего не знали, и каждый берет необходимую информацию из третьей стороны — метаданные. да, она будет формально на сервере, но она не будет ни мешать работать классическому беку работать с объектом, ни отбирать у него ответственность. она скорее выставляет им обоим — беку и фронту некий реестр требований, по которым они оба должны синхронно жить.
и орм тоже должен участвовать в этом безобразии, ибо если вы делаете только генерацию форм по метаданным, но не делаете орм в беке, который по метаданным умеет сохранить объект в бд — то какой смысл делать метаданные ?- вы замучаетесь руками подтягивать одно к другому при изменении того же атрибутного состава.
ps: отмечу, что, идея о том, что объект должен сам уметь себя хранить в бд — она валидна только для отдельных архитектур (простите не помню названия этого подхода).
например — скажите — откуда объект должен знать как ему собирать или размещать себя в хранилище типа datavault? это ответственность хранилища, точнее орм, который знает правила «трансляции» записей метаданных на «физику» хранилища.
pps: и да, я не говорю что ваш подход и ваши идеи плохи. я говорю о том, что есть спектр ситуаций, в которых ваши подходы будут работать не так хорошо и давать совокупный результат хуже, чем системы, которые не соответствуют вашим идеям об архитектуре.
и, естественно, наоборот: системы с метаданными и автогенерацией нет смысла применять на вебсайтах. но мы же сейчас обсуждаем автогенерацию форм.
Я к тому, прежде всего, что форма — самодостаточный инф. объект в системе, особо от других объектов независящий и чаще всего не требующий хранения в базе или ещё где. Отправка формы на бэк — это не создание или изменение каких-то связанных объектов, а создание на бэке временного объекта «форма» и её дальнейшая обработка. UserForm ничего не знает об User, а он о форме. Об обоих знает какой-то UserFormHandler, который может тупо 1:1 копировать данные формы в «настоящий» объект и с помощью ORM сохранять его, а может делать что-то совершенно другое. Но фронта это никак не касается, он от объекта User изолирован полностью.
Давайте ещё раз проговорим)
мы же, в контексте топика не о «классических подходах», а говорим в первую очередь о _генерации_ форм?
т.е.продолжая термины вашего примера — у вас не будет никакого UserForm.
У вас будет AutoGeneratedForm. один на всех.
AutoGeneratedForm — универсальный механизм. угловатый но предоставляющий приемлемый минимальный уровень работы со всеми сущностями.
механизм который умеет динамически себя перестраивать под тот объект который ей передали.
Хотите — передавайте ей User, хотите — AccountingYearReport, хотите — OperationLogElement — она сама перестроится и отобразит это на экране.
Т.е. идея такая: вы один раз написали такую универсальную форму, и после этого практически забыли о типовых CRUD-механизмах работы с сущностями в GUI (просмотр списка, просмjтр карточки, сортировка, выборка, редактирование).
Теперь к вам вопрос: каким образом реализовать такую систему?
т.е. я с вами согласен что непосредственно связывать их — это глупая идея.
и правильный, имхо, ответ на поставленную задачу такой:
И над сущностями User/AccountingYearReport/OperationLogElement и над AutoGeneratedForm висит «домокловым мечом» система метаданных, которая по мере необходимости дает и той и другой стороне (и фронту и беку) необхоимую информацию о том, как работать с передаваемой сущностью.
детали реализации — будет у вас хендлер или что то ещё, будут у вас метаданные храниться в объекте или централизованно — это уже не важно. Важно что и информационная сущность, и форма синхронизируются (или сопоставлены если хотите) через третью сущность — метаданные.
мы же, в контексте топика не о «классических подходах», а говорим в первую очередь о _генерации_ форм?
т.е.продолжая термины вашего примера — у вас не будет никакого UserForm.
У вас будет AutoGeneratedForm. один на всех.
AutoGeneratedForm — универсальный механизм. угловатый но предоставляющий приемлемый минимальный уровень работы со всеми сущностями.
механизм который умеет динамически себя перестраивать под тот объект который ей передали.
Хотите — передавайте ей User, хотите — AccountingYearReport, хотите — OperationLogElement — она сама перестроится и отобразит это на экране.
Т.е. идея такая: вы один раз написали такую универсальную форму, и после этого практически забыли о типовых CRUD-механизмах работы с сущностями в GUI (просмотр списка, просмjтр карточки, сортировка, выборка, редактирование).
Теперь к вам вопрос: каким образом реализовать такую систему?
т.е. я с вами согласен что непосредственно связывать их — это глупая идея.
и правильный, имхо, ответ на поставленную задачу такой:
И над сущностями User/AccountingYearReport/OperationLogElement и над AutoGeneratedForm висит «домокловым мечом» система метаданных, которая по мере необходимости дает и той и другой стороне (и фронту и беку) необхоимую информацию о том, как работать с передаваемой сущностью.
детали реализации — будет у вас хендлер или что то ещё, будут у вас метаданные храниться в объекте или централизованно — это уже не важно. Важно что и информационная сущность, и форма синхронизируются (или сопоставлены если хотите) через третью сущность — метаданные.
Генерация бывает разной. У нас может быть UserForm.yaml с метаданными и автоматически сгенерированные UserForm.js, UserForm.go и т. п. Обычно что-подобное имеют в виду, когда говорят об генерации.
То есть идея такая: есть файл с метаданными и есть утилита, которая генерирует код для конкретных форм по метаданным, и для фронта, и для бэка. Не универсальная форма, которой в рантайме скармливаются разные метаданные, а утилита.
Ну и пока до этого я говорил исключительно о формах, то есть об карточке в ваших терминах, если правильно их понимаю.
То есть идея такая: есть файл с метаданными и есть утилита, которая генерирует код для конкретных форм по метаданным, и для фронта, и для бэка. Не универсальная форма, которой в рантайме скармливаются разные метаданные, а утилита.
Ну и пока до этого я говорил исключительно о формах, то есть об карточке в ваших терминах, если правильно их понимаю.
кодогенерация — это изменение процесса сборки, или доп. ручной труд по поддержке скриптов пересборки объектов при расширении структур данных и их запуску. это не всегда приемлемо.
также это потребует пересборки всех компонент проекта при любом изменении структур данных.
хотя это тоже вариант. работаем же с «wsdl-вебсервисами» в джаве аналогичным образом ?))) работаем.
но лично я предпочитаю рантайм решения для генерации интерфейса.
ну и это расширяет области применения такихьмеханизмов. это позволит например создать конфигуриемый на лету механизм пользовательских карточек, что иногда нужно в Ынтерпраз.
так же, мне не нравится сама идея «форм собираемый в компайл тайм», хотя бы потому, что много с этим наелись в jsf. не самый элегантный, имхо подход, но для своего времени и многих областей — пригодно.
также это потребует пересборки всех компонент проекта при любом изменении структур данных.
хотя это тоже вариант. работаем же с «wsdl-вебсервисами» в джаве аналогичным образом ?))) работаем.
но лично я предпочитаю рантайм решения для генерации интерфейса.
ну и это расширяет области применения такихьмеханизмов. это позволит например создать конфигуриемый на лету механизм пользовательских карточек, что иногда нужно в Ынтерпраз.
так же, мне не нравится сама идея «форм собираемый в компайл тайм», хотя бы потому, что много с этим наелись в jsf. не самый элегантный, имхо подход, но для своего времени и многих областей — пригодно.
не делаете орм в беке, который по метаданным умеет сохранить объект в бд
Если использовать не реляционную, а объектную субд, то и Объектно-Реляционный Маппинг и не потребуется.
с объектно ориентирвоанными БД тоже много засад. правильная объектная БД должна уметь валидировать объекты которые ей подсовывают.
т.е. в идеальном варианте — например поддерживать механизм типа XSD или хотя бы на крайний случай JSON Schema или им подобным.
Если она не делает этого, то эти вопросы потребуется решать вам, в вашей сситеме.
и хорошо если вы их решаете, и при переходе с версии на версию успешно решаете проблемы конвертации старых обхектов в новые форматы и структуры или поддерживаете все механизмы отображения данных в вашей обхектной бд начиная с начала времен.
но если у вас объхектная СУБД не умеет валидировать данные (как например очень популярная легковесная MongoDB), а пишут в эту БД несколько систем, особенно если они от разных команд или производителей — то вы рано или поздно получите проблему когда вы с вашими коллегами ассинхронизируетесь в понимании как разбирать структуры в вашей бд.
т.е. объекты у вас будут, но понять что они означают вы не сможете. потому что давно потеряли информацию о том что записано и как трактовать эти json-структуры.
Если вам интересны примеры — сошлюсь на проект разработки первой версии ЕГРН для Росреестра давностью года 3 назад. Тамошние/тогдашние подрядчики создали именно такую ситуацию — в могно-дб лежали настолько разношерстные данные, что написать бота, который бы вытащил из этой БД хоть какие-то полезные данные было совершенно невозможно. и произошло это, по моей версии, как раз из за того что писали данные туда 2 системы, структуры данных развивались, а сама монго-дб не умела хоть как-то вализировать присылаеый ей мусор.
— ну так вот. я к тому, что метаданные для объектно ориентирвоанных БД или ОРМ которые скрывают работу с объектными БД — тоже нужны.
Только играют они иную роль и по другому выглядят, по другому называются.
XSD, Json-schema и тп — становятся неотъемлемой частью системы метаданных если вы используете объектныю бд на больших долгоживущих проектах.
т.е. в идеальном варианте — например поддерживать механизм типа XSD или хотя бы на крайний случай JSON Schema или им подобным.
Если она не делает этого, то эти вопросы потребуется решать вам, в вашей сситеме.
и хорошо если вы их решаете, и при переходе с версии на версию успешно решаете проблемы конвертации старых обхектов в новые форматы и структуры или поддерживаете все механизмы отображения данных в вашей обхектной бд начиная с начала времен.
но если у вас объхектная СУБД не умеет валидировать данные (как например очень популярная легковесная MongoDB), а пишут в эту БД несколько систем, особенно если они от разных команд или производителей — то вы рано или поздно получите проблему когда вы с вашими коллегами ассинхронизируетесь в понимании как разбирать структуры в вашей бд.
т.е. объекты у вас будут, но понять что они означают вы не сможете. потому что давно потеряли информацию о том что записано и как трактовать эти json-структуры.
Если вам интересны примеры — сошлюсь на проект разработки первой версии ЕГРН для Росреестра давностью года 3 назад. Тамошние/тогдашние подрядчики создали именно такую ситуацию — в могно-дб лежали настолько разношерстные данные, что написать бота, который бы вытащил из этой БД хоть какие-то полезные данные было совершенно невозможно. и произошло это, по моей версии, как раз из за того что писали данные туда 2 системы, структуры данных развивались, а сама монго-дб не умела хоть как-то вализировать присылаеый ей мусор.
— ну так вот. я к тому, что метаданные для объектно ориентирвоанных БД или ОРМ которые скрывают работу с объектными БД — тоже нужны.
Только играют они иную роль и по другому выглядят, по другому называются.
XSD, Json-schema и тп — становятся неотъемлемой частью системы метаданных если вы используете объектныю бд на больших долгоживущих проектах.
UFO just landed and posted this here
на один ооп язык не предоставляет вам информации о том, как надо отображать объект.
потому вам надо что то дополняющее те метаданные которые вы можете вытащить например через рефлекшен в java, через систему метаданных в Qt или другие механизмы в вашем языке.
например вам надо отображать поле с типом Integer. какой контролс следует использовать системе генерации «формы редактирования по умолчанию» — поле ввода с калькулятор-дроп-дауном, поле со стрелочками вверх-вниз как в хроме, или может быть скроллер для повышения визуальности? где указать допустимые для ввода границы что бы еще на этапе ввода отсечь нежелательные значения?
метаданные синхронизируют в этих вопросах поведение универсальных механизмов MVC. метаданные, если можно так сказать, выступают 4м элементом, которые позволяют в одном месте указать информацию которой будут пользоваться и «модель», и «контроллер», и «вид». они по прежнему отвечают каждый за свое как и надо в модели MVC, но универсальные механизмы имеющиеся в каждой из этих частей, используют информацию из метаданных для того, что бы работа была синхронизированна.
можедь знала что надо обработать поле с числом типа int, контроллер что надо позволять только отрицательные числа от 0 до -20, а вид — что надо использовать дропдаун с выбором значения.
потому вам надо что то дополняющее те метаданные которые вы можете вытащить например через рефлекшен в java, через систему метаданных в Qt или другие механизмы в вашем языке.
например вам надо отображать поле с типом Integer. какой контролс следует использовать системе генерации «формы редактирования по умолчанию» — поле ввода с калькулятор-дроп-дауном, поле со стрелочками вверх-вниз как в хроме, или может быть скроллер для повышения визуальности? где указать допустимые для ввода границы что бы еще на этапе ввода отсечь нежелательные значения?
метаданные синхронизируют в этих вопросах поведение универсальных механизмов MVC. метаданные, если можно так сказать, выступают 4м элементом, которые позволяют в одном месте указать информацию которой будут пользоваться и «модель», и «контроллер», и «вид». они по прежнему отвечают каждый за свое как и надо в модели MVC, но универсальные механизмы имеющиеся в каждой из этих частей, используют информацию из метаданных для того, что бы работа была синхронизированна.
можедь знала что надо обработать поле с числом типа int, контроллер что надо позволять только отрицательные числа от 0 до -20, а вид — что надо использовать дропдаун с выбором значения.
UFO just landed and posted this here
вы говорите что «на js можно поместить в объект информацию о том как его отображать» — я же правил но вас понимаю?
тут 2 момента.
1) вы по сути подтверждаете мой тезис о том, что сам по себе ооп-язык не предоставляет механизмов и правил описания как отображать данные.
2) вы говорите про детали реализации, которые распределяют задачи функциональных подсистем на программные классы систем.
действительнь — почему бы не разместить в объекте его собственный кусочек метаданных, и отнаследовать откуда то кусочек для орм, который дает объекту самому сохраняться в хранилище — почему нет? это не более чем детали реализации тех же сущностей о которых я говорю: объект и метаданные.
только система метаданных у вас организована так, что каждый объект «знает о себе всё».
и я так делал. так был построен мой орм для qt.
но когда мне потребовалось реализовать вариативный орм который имел бы одинаковый н ерфейс и для 3nf бд и для datavault — я использовал другую идеологию.
тут 2 момента.
1) вы по сути подтверждаете мой тезис о том, что сам по себе ооп-язык не предоставляет механизмов и правил описания как отображать данные.
2) вы говорите про детали реализации, которые распределяют задачи функциональных подсистем на программные классы систем.
действительнь — почему бы не разместить в объекте его собственный кусочек метаданных, и отнаследовать откуда то кусочек для орм, который дает объекту самому сохраняться в хранилище — почему нет? это не более чем детали реализации тех же сущностей о которых я говорю: объект и метаданные.
только система метаданных у вас организована так, что каждый объект «знает о себе всё».
и я так делал. так был построен мой орм для qt.
но когда мне потребовалось реализовать вариативный орм который имел бы одинаковый н ерфейс и для 3nf бд и для datavault — я использовал другую идеологию.
У автора (по крайней мере из статьи вырисовывается) нет хорошего понимания о том, что ему нужно — а соответственно, объем работ тут точно так же очень неопределен. У автора есть запрос на «просто», но нет строгого описания (а значит и понимания, скорее всего), что в это «просто» должно входить.
Но это даже не обсуждается, что «фреймворку для генерации формочек» потребуется дополнительная информация — из чего же он эти формочки нагенерит иначе? И заострять внимание именно на этом — ну фиг знает, по-моему излишне. Это и так подразумевается, как например запрос «построить график» подразумевает, что есть данные, по которым его можно строить.
Но это даже не обсуждается, что «фреймворку для генерации формочек» потребуется дополнительная информация — из чего же он эти формочки нагенерит иначе? И заострять внимание именно на этом — ну фиг знает, по-моему излишне. Это и так подразумевается, как например запрос «построить график» подразумевает, что есть данные, по которым его можно строить.
Странно, почему минусуют этот комментарий.
На мой взгляд комментарий по делу:
1. просто фронт нарисовать — поверхностное решение. Желательна поддержка бэка.
В фронт должна идти масса информации от бэка и метаданных: типы данных, формат, валидации. Эта информация уже определена на бэке, так почему ее не транслировать на фронт?
2. аналогично с автором комментария, у меня на решение ушло в общей сложности 8+ лет и сейчас финальная, 4-я редакция, которая основана на метаданных и покрывает фронт и бэк.
Это охрененное количество работы и денег, с подключением экспертов из разных областей.
На мой взгляд комментарий по делу:
1. просто фронт нарисовать — поверхностное решение. Желательна поддержка бэка.
В фронт должна идти масса информации от бэка и метаданных: типы данных, формат, валидации. Эта информация уже определена на бэке, так почему ее не транслировать на фронт?
2. аналогично с автором комментария, у меня на решение ушло в общей сложности 8+ лет и сейчас финальная, 4-я редакция, которая основана на метаданных и покрывает фронт и бэк.
Это охрененное количество работы и денег, с подключением экспертов из разных областей.
есть ещё devextreme — формочки, и вполне себе декларативно.
причем под кучу фреймворков сразу
правда есть два "но":
- платно
- полностью от написания html не избавят
Если я все правильно понял, то более всего вашему подходу соответствует pureqml.com
Пока web, будет выглядеть вот так
<...>
</...>
он не перестанет вызывать у меня изжогу, ничего отвратительнее не видел(
WPF по этой причине долго не мог поднять для себя. Но кодируя контролы в самом коде, как то переборол эти тэги, а потом и вовсе смирился с ними. Но к HTML отношение ни капли не поменялось.
<...>
</...>
он не перестанет вызывать у меня изжогу, ничего отвратительнее не видел(
WPF по этой причине долго не мог поднять для себя. Но кодируя контролы в самом коде, как то переборол эти тэги, а потом и вовсе смирился с ними. Но к HTML отношение ни капли не поменялось.
UFO just landed and posted this here
Вариантов описания интерфейса куча, в частности, почему бы не быть ему как в Ammy
SQL читается как роман по сравнению с тегами:) А все что рябит в глазах, это зло.
SQL читается как роман по сравнению с тегами:) А все что рябит в глазах, это зло.
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);
};
полученный массив вставляем куда надо. Фреймворка такого нет потому что никто не будет десять строк оформлять во фреймворк.
полученный массив вставляем куда надо
Лейаута нет, где должна быть логика (обработчики) — непонятно, и т.д.
Ваши 10 строк просто позволяют хранить HTML в JSON. Нужно это примерно никому (зачем хранить HTML где-то еще, если можно хранить его прямо так?), поэтому и не оформляют.
как задача поставлена — так она и решена. Безотносительно рациональности самой задачи.
UFO just landed and posted this here
предполагается что response пришел по сети, то есть все таки json, но функции так можно передавать, главное что бы они были автономными (то есть все используемые в них символы — либо глобальны для js либо приходят в параметрах). Прикручивается при помощи еще пары строк. + еще пара строк — и можно сделать elements рекурсивными, то есть отражать в них вложенные элементы. Не стал этого писать потому что смысла нет, так же как и (на мой взгляд) смысла в поставленной задаче. Есть html templates/jsx/tsx, есть custom elements/react/vue/angular, в общем куча инструментов работающих на уровне view, выбирай на любой вкус. И вопрос декларативности на любом выбранном инструменте решается таким же десятком строк что я привел.
UFO just landed and posted this here
Попробуйте на чистом html вставить в каждую ячейку селект на сотню-другую опций.
UFO just landed and posted this here
Вы только не забывайте, что с «гипотетической ситуации» вы сами начали.
В браузере в 99.8% случаев не надо выводить таблицы на десятки тысяч строк. Браузер, как чисто презентационный движок — работает с такими объемами информации, с которыми удобно работать человеку. За подавляющим большинством ситуаций а-ля «я фигачу в HTML таблицы на 100500 экранов размером и чёт они у меня тормозят» стоит банальное неумение построить UI с более адекватным охватом, или же в крайнем случае — организовать разбивку на части.
Да, есть и 0.2% случаев, где безумные объемы данных в браузере таки нужны одним куском. И да, в этих случаях вам действительно не стоит брать реакт, да и вообще по большей части и JS брать тоже не стоит. Но эти случаи мягко говоря нишевые.
В браузере в 99.8% случаев не надо выводить таблицы на десятки тысяч строк. Браузер, как чисто презентационный движок — работает с такими объемами информации, с которыми удобно работать человеку. За подавляющим большинством ситуаций а-ля «я фигачу в HTML таблицы на 100500 экранов размером и чёт они у меня тормозят» стоит банальное неумение построить UI с более адекватным охватом, или же в крайнем случае — организовать разбивку на части.
Да, есть и 0.2% случаев, где безумные объемы данных в браузере таки нужны одним куском. И да, в этих случаях вам действительно не стоит брать реакт, да и вообще по большей части и JS брать тоже не стоит. Но эти случаи мягко говоря нишевые.
Зачем в каждую-то, может только в активную, и то после набора первой буквы?
Затем, что нативный селект не умеет ни в ленивый рендеринг, ни в фильтрацию. И вот, нам уже нужен кастомный контрол и фигурная работа с DOM, чтобы при ререндере селекта он не закрывался.
>Хоть Дарт, хоть Реакт — везде компоненты добавляются прямо в DOM, и фреймворки сразу попали в ловушку низкой производительности, которую сами и создали.
Я прикручивал биндинги к custom elements — получается тот же реакт только без головняков по оптимизации рендеринга, этим занимается броузер и не надо велосипедить. Небольшой проект по работе запустил — полет нормальный. Но средние и больше проекты не рискую переводить на эти рельсы — для народа выглядит непривычно, тим лидер смотрит на меня настороженно :)
Я прикручивал биндинги к custom elements — получается тот же реакт только без головняков по оптимизации рендеринга, этим занимается броузер и не надо велосипедить. Небольшой проект по работе запустил — полет нормальный. Но средние и больше проекты не рискую переводить на эти рельсы — для народа выглядит непривычно, тим лидер смотрит на меня настороженно :)
Что-то похожее, только фулстек, мы с напарником делали года три-четыре назад для себя — getblank.net. Декларативно определяем схему, по которой строится и фронт и бэк.
Описание с докой не самые актуальные сейчас, т.к. никому кроме нас эта платформа оказалась не интересной, зато сами мы немалое количество проектов выполнили с её помощью.
В данный момент идёт переосмысление проекта, т.к. оказалось, что излишняя гибкость заложена, что привело к усложнению всего.
Описание с докой не самые актуальные сейчас, т.к. никому кроме нас эта платформа оказалась не интересной, зато сами мы немалое количество проектов выполнили с её помощью.
В данный момент идёт переосмысление проекта, т.к. оказалось, что излишняя гибкость заложена, что привело к усложнению всего.
Любопытная статья.
Фреймворк не встречал, но последние 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
Фреймворк не встречал, но последние 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
Выглядит интересно. Я смотрю вы тоже выбрали буклетный дизайн (горизонтальный стек панелей), чтобы приложение имело одинаковый ux что на десктопе, что на мобилке?
Вроде того.
Текущая разметка — частный случай ( ibb.co/d6r8dX4 ) и может быть легко изменена.
Для мобильной версии проще нарисовать странички с функционалом, специфичным для возможностей и задач мобилки.
Текущая разметка — частный случай ( ibb.co/d6r8dX4 ) и может быть легко изменена.
Для мобильной версии проще нарисовать странички с функционалом, специфичным для возможностей и задач мобилки.
dhtmlx.com/docs/products/dhtmlxSuite
Позволяет писать декларативно описывая компоненты через json, xml.
Позволяет писать декларативно описывая компоненты через json, xml.
В свободное время писал такой фреймворк. На собеседованиях всегда просят показать примеры кода, вот и показываю.
www.youtube.com/watch?v=NYqVYc1du3Y
Потрогать можно тут
polarspa.coolpage.biz/demo.html
www.youtube.com/watch?v=NYqVYc1du3Y
Потрогать можно тут
polarspa.coolpage.biz/demo.html
Ох ёпрст ) намолотили тут за день — не ожидал такого интереса.
Всем спасибо кто откликнулся! В комментах много интересного. Спасибо за ссылки!
По поводу моей нечёткой формулировки того, чего я искал — я имел ввиду, что на входе подаёшь вот такое:
{
"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"
}Но повторюсь, в комментах накидали всякого, надо смотреть.
Ну если исключительно для форм то есть такая штука как Formly, например для ангуляру это https://github.com/ngx-formly/ngx-formly удобный, настраиваемый.
В моем проекте UI на Webix.
Начал работу с Webix в 2013, когда он был еще на стадии беты.
Согласен, хороший framework, но допиливать пришлось каждый контрол.
Начал работу с Webix в 2013, когда он был еще на стадии беты.
Согласен, хороший framework, но допиливать пришлось каждый контрол.
А нет. Показалось. Попробовал редактор форм — сам размещать похоже не умеет. Нужно руками задавать визуальные параметры контролов (ширину, и т. п.).
Вполне умеет, только не пользуйтесь редактором форм.
Лучше Snippet. Им пользуются для демонстрации proof of concept и траблшутинга.
Редактор форм не очень удачен, пусть он вас не сбивает с пути к Вебиксу. :)
Лучше Snippet. Им пользуются для демонстрации proof of concept и траблшутинга.
Редактор форм не очень удачен, пусть он вас не сбивает с пути к Вебиксу. :)
Спасибо. Обязательно попробую.
Хм… всё равно как-то не круто. Смотрите, вот код:
Вот результат:
Ну чтооо такое… ширина надписей — это просто константа. Чтобы увидеть весь текст, необходимо прописать в каждый элемент явно ширину надписей. Для этого нужно знать ширину самой широкой строки.
Можно конечно вот так попробовать:
Но всё равно, как-то не особо стало лучше:
Между надписями и полями ввода куча пустого пространства. Если убрать кнопку, то колонки становятся равными и снова остаётся место. В данном случае, возможно, должен быть какой-то автоподбор ширины колонки по содержимому, но в документации про это упоминаний не обнаружил.
Если столько манипуляций нужно произвести с простой формочкой на два поля ввода, то что же там дальше?
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"
}
]
}
]
});
Но всё равно, как-то не особо стало лучше:
Между надписями и полями ввода куча пустого пространства. Если убрать кнопку, то колонки становятся равными и снова остаётся место. В данном случае, возможно, должен быть какой-то автоподбор ширины колонки по содержимому, но в документации про это упоминаний не обнаружил.
Если столько манипуляций нужно произвести с простой формочкой на два поля ввода, то что же там дальше?
Форма значительно проще:
snippet.webix.com/r8qu5eds
webix.ui({
cols:[
{ view:«form»,
elementsConfig:{labelWidth: 130},
elements:[
{
view: «text»,
label: «Код»
},
{
view: «text»,
label: «Наименование»
},
{
view: «button»,
label: «Записать»
}
]
},
]
});
snippet.webix.com/r8qu5eds
webix.ui({
cols:[
{ view:«form»,
elementsConfig:{labelWidth: 130},
elements:[
{
view: «text»,
label: «Код»
},
{
view: «text»,
label: «Наименование»
},
{
view: «button»,
label: «Записать»
}
]
},
]
});
Спасибо. Я говорил как раз про необходимость этой строчки, что хотелось бы без неё:
elementsConfig:{labelWidth: 130}, Скажите, а зачем в данном случае заворачивать в "cols"?
Форма нарисуется и так:
webix.ui({
view:"form",
elementsConfig:{labelWidth: 130},
elements:[
{
view: "text",
label: "Код"
},
{
view: "text",
label: "Наименование"
},
{
view: "button",
label: "Записать"
}
]
});… вообще прикольный фреймворк.
хотелось бы без неёБез проблем, но тогда в каждое поле прописывать ширину label.
а зачем в данном случае заворачивать в «cols»Такова полная структура. На случай, если нужно отображать несколько ячеек вертикально или горизонтально. Вы привели упрощенную структуру со значением (cols) по умолчанию.
Ниже пример:
snippet.webix.com/plth3ogb
Думаю, наш диалог выходит за рамки статьи.
Sign up to leave a comment.
Поиск JS-фреймворка для генерации UI