Comments 75
Поздравляю, вы изобрели HTML и HTTP, только на JSON и WebSocket. Дальше добавьте поддержку стилей, учредите комитет для выработки единого стандарта, чтобы разные AppBrowser-ы показывали ваш GUI одинаково, добавьте возможность запускать локальные скрипты на AppBrowser-е (чтобы логику репрезентации отделить от бизнес-логики, потому что наш API-сервер ведь занимается только важными бизнес-вещами)… работы непочатый край.
Оборачивает всю разметку в JSON
Оформляет в JSON даже таблицы
Никакой разметки
ну-ну
{‘name’:’My table’, 'headers'=[‘Name’, ‘Synonym’], rows = [
[‘young’, ‘youthful’],
[‘small’, ‘ meager’],
...]
}
Знакомьтесь, это — разметка. Вы взяли какие-то данные и сказали "я хочу, чтобы эти данные были в форме таблицы".
Или вот:
{‘name’: ‘Switch something’, value: ‘choice1’, options=[‘choice1’, ‘choice2’,’choice3’]}
Найдите 3 отличия от <select><option>choice1</option><option>choice2</option><option>choice3</option></select>
.
То, что вы решили не упоминать напрямую имена контролов, и вместо этого маскируете их за утино-типизированным списком аттрибутов, всего лишь делает ваше произведение неудобной, плохо формализуемой разметкой.
Нет, ну почему же все? Только приведенные вами примеры. Вот, например, данные без какой-либо разметки:
{
"users": [
{ "name": "John Doe", age: 42, roles: ["admin", "bureaucrat"] },
{ "name": "Jane Doe", age: 34, roles: ["nobody"] },
],
"session": {
"expires": "2020-05-13T04:17:46.298Z"
}
}
Не-а. У вас идет разметка — "это таблица, и вот ее строки". "Это чекбокс, и вот его состояние". "Это метка, вот ее текст". "Это комбобокс, вот варианты выбора".
Данные же лишены вариативности выбора (это не схема, где можно было бы подсмотреть варианты возможных значений), данные не содержат подписей, данные не имеют в принципе поля "name", потому что name — это имя некоего контрола, это аттрибут разметки, где сами данные, возможно, находятся в поле value.
Так что у вас обычная разметка, смиритесь.
Ну и да, назовите отличия вашей совершенно-не-разметки от HTML. Пока выглядит как брат HTML, но который болел в детстве.
Я передаю именно данные таблицыДанные — это чистая информация, ее можно представлять разными способами — таблицей, диаграммами, текстом с разделителями. Вот эти перечисленные способы — это и есть разметка.
По этому если вы просто передаете некий словарь в виде JSON — это данные, если Вы при этом явно указываете, как они должны быть отображены (таблица, диаграмма и т.п.) — это данные с разметкой.
а по моему всё XML подобное должно уйти в прошлое, пусть это и разметка, но имеет право на жизнь
Что-то подобное видел в ExtJs, правда там данные от разметки разделены, но представление так же в json подобном виде
"Как выглядит разметка без разметки". Когда вы говорите "таблица", вы уже изъявляете желание придать данным определенную форму, разметить их под определенное представление. Вы не можете просто взять выхлоп GraphQL-запроса и "показать" его через ваш uniGUI — вам нужно сконвертировать объект, обладая знаниями о его схеме, в нечто, что uniGUI поймет как таблицу — т.е. разметить.
Нет совершенно никакой разницы, выразите вы это как
{
name: 'My table',
headers: ['Name', 'Synonym'],
rows: [
['young', 'youthful'],
['small', 'meager']
]
}
или как
<table>
<caption>My table</caption>
<tr><th>Name</th><th>Synonym</th></tr>
<tr><td>young</td><td>youthful</td></tr>
<tr><td>small</td><td>meager</td></tr>
</table>
[
{"word":"young", "synonym":"youthful"},
{"word":"small", "synonym":"meager"}
]
Описание того что «word» нужно писать в колонку «Name», а «synonym» в колонку «Synonym» — это разметка.
Для получения все более универсального GUI необходимо рассматривать проблему со все более высокого уровня абстракции (хочешь получить универсальный калькулятор — рассматривай и решай задачу с уровня абстракции «Фортран» и тд). Для сегодняшнего случая следующий уровень абстракции это ИИ. Простое упорядочивание, удаление повторов и не оптимальных элементов не поможет в решении проблемы — вы просто создадите еще одно не совместимое подмножество.
Статья занимательная. Есть о чем задуматься. Вот только я не уверен, что у Вас на этом страдания закончатся.
Более того, велосипедные поделки на эту тему — они все без исключения наступают всё на те же грабли, по которым уже от души походили крупные фреймворки.
У автора классический случай «своего болота», когда успешно реализовав свой собственный узенький кейс, он считает, что его решение достаточно общее, и взлетит за пределами этого узенького кейса.
И это вам еще не начали задавать вопросы про безопасность и авторизацию. Протокол у вас HTTP? А если кто-то еще подключится к этому же серверу?
А, например, если у вас поле ввода пароля есть на форме — вы содержимое в открытом виде передаете?
вот событие [Glossary, Terms, =, 658] значит что юзер в блоке Glossary выбрал строку в таблице Terms с id 658.вот нажали кнопку на тулбаре с именем _Back [toolbar, _Back, =, _Back] и т. д.
2. есть мультивыделения (см. переключатель с иконкой 1 на скрине) тогда появляются checkbox слева от каждой строки.
про задержку/игнор событий — дело сервера. игнорить или нет — дело обработчика. он вызовется всегда если пришло событие.
1.Websocket гарантирует очередность доставки событий, насколько я знаю.
2.нет событие — нет реакции. событие занимает ~ 20 байт. 3 события за секунду при интенсивном наборе чего-то максимум.
правда это скорее заслуга больше flutter чем моя в скорости отрисовки.
Будет отрисован в виде кнопочной группы. На скрине справа вверху пример такой Stable, Virtual, Both.
это app, который не требует затрат на программирование, дизайн, обслуживание и способный одинаково работать с любыми языками, и на любой платформе без всяких подстроек
Почему-то подумал о командной строке. Но даже она требует затрат на программирование.
Идеи X11 появились еще 36 лет назад. В общем случае, приложение может работать на удаленном сервере, но формы и весь интерфейс вы можете использовать локально на своем ноутбуке с Mac, Linux или Windows — поддерживается довольно много транспортов.
Но, в общем-то я вас понимаю — скучно разбираться с чужими и уже реализованными протоколами и уже найденными граблями — интереснее придумать свой велосипед и покрасить свои грабли
(еще раз картинка про 14 стандартов), (шутка про фатальный недостаток)
Тогда гляньте ещё попытки упрощения xserver через отрывание сетевой подсистемы и уменьшение количества примитивов и утилит.
Из живых ныне wayland, mir.
Но по серьёзному у вас получается ещё один гуи фреймворк теперь с JSON вместо "стандартных" биндингов.
Дополнительный вопрос:
— что будет, если клиент ещё старый, а сервер выдаёт ему формы с новыми контролами, которые только что появились(ведь не все сразу появятся в начальной реализации)? Скажем, добавили combobox в который можно текст вписывать, а до этого были только read-only comboboxes.
Edit: убрал остальные дополнительные вопросы :)
2. Я не предусмотрел такие вопросы пока. но если он встанет, то по логике uniGUI если не сможет определить тип должен отрисовать пустое пространство с сообщением об ошибке, если данные не подходят ни какому виду-виджету. Если подходят — отрисовать им и предупреждение.
1. Начинаю не понимать, что будет делаться на сервере, если еще нужна какая-то прослойка на каждую конкретную платформу. Кто будет писать эти прослойки? И где они будут бежать?
2. Что делать тем, у кого интернет отсутствует(здравствуйте режимные предприятия) или нестабильный(нажали кнопочку сохранить, прога пошла на сервер за формой диалога сохранения, да и повисла)?
3. Кто и когда будет отрисовывать формы? Что будет отвечать за перевод JSON от сервера в картинку на экране? Если локальная прослойка, то опять же не ясно, что делает сервер.
4. Цитата "… сервер получает поток сообщений JSON, которые полностью описывают что сделал юзер...". Хм, то есть предлагается всем на какой-то сервер слать свои пароли/логины(а как иначе рассказать серверу, что было нажато)? Как вообще будет работать то, что должно быть под грифом «секретно»?
5. Многие GUI библиотеки имею классную штуку, позволяющую расширять набор контролов и менять отрисовку (custom controls), чтобы реализовать приятное и выделяющееся из остальных приложение. Да, это не для каждого типа приложений подойдёт. Как это будет при универсальности?
Прослойки — это адаптеры для языка которые только обеспечивают автоматизм отправки-синхронизации данных пользователя <-> данные GUI. для питона например такая прослойка занимает ~ 250 строк кода. и она универсальная а не прошитая под мои потребности.
2. Локально запускайте сервер-app. Без сервера работать не должно)
3.Сервер дает описание данных. Клиент обеспечивает все остальное.
4.https соединение. клиент шлет только свои события.
5. Расширение типов. Сейчас на некоторые типы данных возможна отрисовка по разному. Если на один тип данных более одного виджета, просто всунуть type:MyNewTree. Если такие типы будут написаны на Dart, то динамическая стыковка вполне реализуема. но как по мне то что в Google MD поддерживать автоматом не морочиться этим.
2. Почему всё вдруг в строку и нужно нажать кнопку, чтобы увидеть невлезшее? Почему не flow?
3. Кроме UI есть UX, а его так просто в JSON не запихнешь. Вернее запихнешь, но, как сказали выше, получится еще один html/javascript.
сложные элементы управления такие Таблицы, Viewers, могут иметь дополнительные параметры, как то ‘colors’, ‘params’,… которые могут использоваться для специфической отрисовки или выбора доступных опций
По умолчанию — максимальный набор опций,
2.Здесь дело вкуса и информативности. вы сразу видите, что в экране еще чего-то есть, не скроллируя.
нажать кнопку и переместиться на нужный блок быстрее чем скролл и поиск. Но такие мелочи могут настраиваться в опциях автодизайнера, который учтет вкусы пользователя, пользователем.
3. все можно описать декларативно, кратчайшим образом. Все то, что за пределами логики стандартного GUI описывается в сервер логике. Маски, допустимость ввода обрабатываются сервером когда получил событие. Прослойка автоматом имеет на все обработку по умолчанию. Свой обработчик позволяет принять или откатить и сделать в ответ все что угодно с экраном пользователя, послав ему новый экран или апдейт экрана.
Универсальный GUI ~= конец страданиям