Здравствуйте, Михаил Романов, Вы писали:
МР>Единственное, что здесь все рисуется в рамках браузера, но зато вам как разработчику придется писать отдельное приложение, а не просто виртуализовать свое имеющееся.
То есть можно проектировать приложение, как с VCL без оглядки на ограничения html-разметки?
Здравствуйте, rfillipenko, Вы писали:
R>То есть можно проектировать приложение, как с VCL без оглядки на ограничения html-разметки?
Я не очень понял, о каких вы ограничениях, если честно.
Я подозреваю, что пока вы будете оставаться в рамках сценариев, которые продумывали разработчики фреймворка — всё будет работать более-менее нормально.
Но надо будет сразу смириться, с тем, что:
Требуется аккуратное управление ресурсами в рамках сессии. Т.к. в одном процессе, по сути будут хоститься сразу все подключения (даже если они могут раскидываться по множеству процесов в том же ISAPI варианте, это сильно ничего не меняет).
Использование сторонних компонентов будет затруднено или невозможно. Также, скорее всего будут сложности с использованием сторонних JS библиотек.
Многие, привычные в Web-приложениях, сценарии будут невозможны или сложно реализуемы (например, описанный мною пример с авторизацией, или задание разной авторизации для разных частей приложения).
Могут быть проблемы с реализаций некоторых привычных пользователем сценариев. Например, навигации (кнопки "Назад"), то что это SPA уже много лет как не является оправднием, пользователи привыкли переходит по ссылкам (которые можно сохранить в Favorites или переслать коллеге) или нажимать кнопку "Назад", чтобы вернуться к предыдущей странице — здесь этого нет (хотя сам ExtJS вроде как всё это поддерживает).
Ну и если возникнут проблемы придется влезать и в JS (а его там очень много: ExtJS — одна из первых JS GUI библиотек, они понаписат ьуспели изрядно), в собственный механизм uinGUI (который нигде не документирован)...
И собственно вопрос — на сколько возможно (в описанных условиях) переиспользование кода (например от имеющегося Desktop приложения). Как по мне — практически никак.
А раз так, то резонен следующий вопрос — а зачем тогда оно? Может всё же выделить небольшой ресурс на изучение параллельного стека и сделать нормальное веб-приложение?
T>>Это ж разные наборы VCL, где ты видишь единость? I>Это замена для стандартного VCL.
Честно говоря не представляю как можно заменить десктопный TForm на вебовский без существенных изменений.
I>Я подробностей реализации не знаю, но полагаю что этот набор VCL генерирует html/js фронтэнд. Т.е. вместо формы будут html страница. I>В некоторых случаях — это удобно. Но не во всех.
Может для генератора отчетов это и сойдет, но для полноценных веб-приложений нужно намного больше чем тупая генерация HTML.
Здравствуйте, Михаил Романов, Вы писали:
МР>А раз так, то резонен следующий вопрос — а зачем тогда оно? Может всё же выделить небольшой ресурс на изучение параллельного стека и сделать нормальное веб-приложение?
Позвольте полюбопытствовать, а что в Вашем понимании "нормальное вэб-приложение"?
просто интересно...
Здравствуйте, turbocode, Вы писали:
T>Честно говоря не представляю как можно заменить десктопный TForm на вебовский без существенных изменений.
В чем проблема? VCL — это визуальная библиотека. Ее можно заменить на FireMonkey.
T>Может для генератора отчетов это и сойдет, но для полноценных веб-приложений нужно намного больше чем тупая генерация HTML.
Не спорю. Область применения ограничена. Смысл в том, чтобы оставить текущую бизнес логику и заменить только пользовательский интерфейс.
Для нового проекта я бы не стал это использовать, а вот для старых — неплохая экономия времени.
Здравствуйте, wamaco, Вы писали:
W>Позвольте полюбопытствовать, а что в Вашем понимании "нормальное вэб-приложение"? W>просто интересно...
С моей точки зрения, нормой для современных вэб-приложений является (с точки зрения пользователя):
Хорошая масштабируемость.
Поддержка широкого спектра разрешений экрана.
Удобство работы как с desktop (клавиатура и мышь) так и с мобильным (тач) экраном
Поддержка привычного user experience. Тут еть сложности с тем, что для Web и Desktop приложение UX — весьма различается. Например, для Web-приложения является нормой наличие навигации, причес возможностью скопировать ссылку и вернутся по ней на то же место (или передать её кому-то чтобы он смог отктвть ту же страницу), тогда как для настольного приложение — это что-то из мира фантастики.
Для разработчиков также будут важны:
Простота разработки и отладки
Простота расширения функционала
Простота интеграции с другими сервисами
Для того, чтобы этим критериям удовлетворят, для современных вэб-фреймворков является фактически нормой:
Работа в stateless режиме. Сессии стараются избегать или делать её разделяемой между узлами кластера
Работа в Geo-распределенном режиме, т.е. когда ваше приложение может быть расположено не просто на нескольких узлах в одном дата-центре, а одновременно работать в нескольких центрах. При этом активно используется CDN для доставки единого статического (и не очень статического контента).
Использование адаптивной верстки и вообще широкий контроль за версткой со стороны разработчика. Здесь не просто проблема в том, что есть, условно, настольные и мобильные компьютеры, а в том, что у них разрешения экрана плавают (от нескольких пикселей до десятков и сотен), и ваше приложение должно быть готово подстроится под них.
Большой процент вычислений на стороне клиента. Начиная от банальной валидации в полях и автозаполнения, заканчивая переносом солидной части логики (иногда вообще всей).
Поддержку одновренменно Web и Desktop UX (на сколько это позволяют текущие технологии). Например, навигации в стиле Web, и перетаскивание Drag-n-Drop'ом файлов для загрузки, как это принято на Desktop
Явное разделение фронтенда и бэкенда и организации их взаимодействия на базе устояышихся протоколов и практик. Например, использование REST (или GraphQL) как базы для приложения. Это позволяет проектироват бэкенд сразу же готовым и для Web-фронтенда и для мобильных приложений (если таковые появятся) и как API для интеграции.
Следование стандартам или устоявшимся практикам (если еще нет стандартов) в части интеграции. Это касается и аутентификации (например, очень популярной ныне аутентификации третьей стороной — тем же Facebook), и API для интеграции, о котором я говорил в пункте выше.
(по крайней мере в enterprise) Использование как базы одного из устоявшихся Web-фреймворков (Angular, React, Vue, ...) — это позволяет легко переиспользовать готовые сторонние компоненты или дорабатывать имеющиеся.
Как-то так.
Из всего выше перечисленного у uniGUI есть
простота разработки (с точки зрения привычек Desktop-разработчика) в определенных сценариях.
некие заделы на адаптивную верстку, но там есть определенные проблемы (я пробовал открывать мобильный пример в нескольких браузерах и на нескольких устройствах — увы, разметка плывет, а вот поправить её не так и просто — управлять разметкой нет возможности),
частично сделано разделение фронтенд-части и бэкенда, но удобство разработки более-менее серьезной логики фронтенда под вопросом (а значит в сложном приложении будут сплошные запросы на сервер), ну а реализуемый протокол обмена бэкенда с фронтендом и вовсе ни для чего, кроме этого самого обмена и не предназначен.
Здравствуйте, icezone, Вы писали:
I>Здравствуйте, loginx, Вы писали:
L>>чего чего, какие такие ограничения? скорее наоборот, безграничная свобода
I>Вот тут не соглашусь — ограничения есть везде. На десктопе HTML будет всегда проигрывать GDI в плане быстродействия.
это отчего ж? обоснования такого мнения не увидел...
я вот в игре весь гуи в 3D на js — gdi не тянет плавность...
Здравствуйте, loginx, Вы писали:
L>это отчего ж? обоснования такого мнения не увидел... L>я вот в игре весь гуи в 3D на js — gdi не тянет плавность...
ты не находишь, что это немного разные вещи? GDI — это окна с контролами, а 3D — это DirectX/OpenGL
ты же не будешь на OpenGL делать текстовый редактор? для этого нужна HTML верстка и скрипты, которые будут дергать GDI/Direct2D
т.е. добавляется лишняя прокладка между GUI и WinAPI
Здравствуйте, icezone, Вы писали:
I>Здравствуйте, loginx, Вы писали:
L>>это отчего ж? обоснования такого мнения не увидел... L>>я вот в игре весь гуи в 3D на js — gdi не тянет плавность...
I>ты не находишь, что это немного разные вещи? GDI — это окна с контролами, а 3D — это DirectX/OpenGL I>ты же не будешь на OpenGL делать текстовый редактор? для этого нужна HTML верстка и скрипты, которые будут дергать GDI/Direct2D I>т.е. добавляется лишняя прокладка между GUI и WinAPI
Мне как прикладному прогеру пофиг, дай мне плавность, если для этого тебе надо переписать все на 3D — переписывай
И это уже сделано с некоторой степенью удачи в WPF и Delphi
И даже в Лисе я не знаю как там это сделано но сейчас, прямо сейчас я кладу контролы прямо на 3D канву и оно работает!
т.е. одноременно 3D объект крутится, а надписи поверх него на html и все Ок. все работает.
Здравствуйте, icezone, Вы писали:
I>Здравствуйте, loginx, Вы писали:
L>>это отчего ж? обоснования такого мнения не увидел... L>>я вот в игре весь гуи в 3D на js — gdi не тянет плавность...
I>ты не находишь, что это немного разные вещи? GDI — это окна с контролами, а 3D — это DirectX/OpenGL I>ты же не будешь на OpenGL делать текстовый редактор? для этого нужна HTML верстка и скрипты, которые будут дергать GDI/Direct2D I>т.е. добавляется лишняя прокладка между GUI и WinAPI
гуи элементы много разных на 3D сделаны в Дельфи и MS ВПФ, умеренное число гуи контролов закрывающих потребности игроделов 3D сделаны в юнити 3D
ты что-то сильно отстал от жизни
Здравствуйте, loginx, Вы писали:
L>гуи элементы много разных на 3D сделаны в Дельфи и MS ВПФ, умеренное число гуи контролов закрывающих потребности игроделов 3D сделаны в юнити 3D L>ты что-то сильно отстал от жизни
это какие контролы на 3D сделаны? кнопки, списки, меню?
не нужны юнити и 3D в обычных приложениях от слова совсем
