Браузер в качестве View в десктопных проектах (WebUI)

[delphius]

Вдохновленный рабочим проектом врапера библиотеки WebView, нашел новый аналогичный проект WebUI (использование любого веб-браузера в качестве графического интерфейса, используя предпочитаемый язык в бэкенде и HTML5 во внешнем интерфейсе в легкой переносимой кроссплатформенной библиотеке), сам сделал к нему врапер и пару примеров, все работает, буду использовать в разработке, как замену обычным формам в десктопных приложениях LCL, реализация форм и RIA в целом с помощью Qooxdoo (аналог и ровесник Ext JS).

Если у кого-то есть наработки в этом направлении или желание и время покопать, то велком

[Снег Север]

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

[delphius]

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

Для унификации разработки. Когда используется, например, паттерн mvvm и модель и представление модели находится на стороне паскаля (на десктопе или на сервере) а само представление - в браузере. При этом, при запуске на десктопе, используется имеющийся браузер в ОС и связь осуществляется, например, с помощью websocets (например с помощью WebUI или WebView); при запуске на сервере, клиенты точно также получают доступ с помощью того же websocets, но уже удаленно.
Поскольку во всех ОСях есть браузеры, то представление будет также работать кроссплатформенно.
Тот же SPAR использует Qooxdoo уже много лет именно в RIA, а это не маленькая контора.
Пример интерфейса
Пока pas2js и webassembly доведут до ума и будет полноценная разработка веб приложений в Лазарусе, как это указано в дорожной карте, пройдет время.
Всё рано или поздно уйдет в облака и браузер, это пока модная фишка и новый тренд, но, пройдет время и это станет обыденностью, а пока паскаль в догоняющих.

[Снег Север]

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

[delphius]

даёт полную унификацию интерфейса

К тому же, в предлагаемом варианте очень солидный набор виджетов, вполне сопоставимый по объему с lcl.
Платное конечно круто, что ExtJS, что TMS, но идет в разрез со смыслом opensource разработки
А "desktop look&feel" (особенно в теме classic) + сама темизация и l18n из коробки тоже не могут не радовать.

Но, никто не мешает прикрутить на вебморду, например, React или вообще использовать ванильный js

[Alex2013]

Интересно, а плеер "на HTML5" ваш WebUI потянет ?
( Честно говоря сам сделать что-то похожее с помощью CEF4 но уперся в динамическую загрузку "DLL с формой" с браузером потому что нужен подгружаемый плагин viewtopic.php?f=1&t=43503 )

[delphius]

а плеер "на HTML5" ваш WebUI потянет?

А что там тянуть то?
Если поток будет с паскалевской стороны через websocets тянуться, то тогда конечно можно рассуждать о каких-то "потянет"
Хотя, и передачу потока можно реализовать, но скорее всего уже прямой связью паскаля с браузером, минуя webui и не с помощью сокетов
А если задача паскалевской стороны будет только в организации вывода:

1. Загрузка формы (читай запуск браузера) с плеером
2. Двухсторонее связывание элементов управления на стороне браузера с моделью представления в паскале (контроль нажатия кнопок, вроде "OnButton1Click")
3. Запуск потока из внешнего источника минуя webui напрямую на html5 плеер в браузер
4. Контроль процесса (элементы управления плеером), контроль потока с помощью javascript событий из п.2

то это именно та задача, для которой все это хозяйство предназначено.

А в целом, эта конструкция в разрезе применения в связке с паскалем нужна только для двух вещей:

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

Или, если по простому, паскаль только контролирует (слушает) связанные через webui события на форме (в браузере) и управляет (посредством передачи строковых данных обратно в javascript события) содержимым формы (браузера).

Но проще всего, "пощупать" вживую, с помощью простого примера

с помощью CEF4

Еще одно преимущество - не надо ничего "встраивать" (любой embeded web engine это объемное хозяйство, которое нужно тянуть с собой и обновлять), а тут используется любой! браузер, присутствующий в системе (в современных ОС всегда есть хотя бы один браузер)

[Alex2013]

Очень интересно буду разбираться ...
Зы
По поводу " не надо ничего встраивать" ренее в виндовс вполне успешно работал LazActiveX
См тему "Про интеграцию браузера."
Он и сейчас работает но в один "прекрасный" день или очедное обновление урезало функциональность этого интерфейса или порезали поддержку "древнего IE" на "целевом сайте" . Однако вместо чего-то вроде этого

...начал получать тонны ошибок в скриптах .

[delphius]

или порезали поддержку "древнего IE" на "целевом сайте"

Скорее всего именно вот это...

Очень интересно буду разбираться ...

Я почитал ветку, но так и не понял конечный сценарий использования, который предполагается? Можно пояснить в двух трех предложениях?

затолкать CEF4 браузер в DLL

Это просто механизм, а конечная цель, насколько понимаю, какое-то управление (сайтом, содержимым и т.п.)?
Понятно, что нужен браузер на форме (или, как сейчас, с WebUI или WebView, имитация формы в браузере), но паскаль сам зачем?
Какая логика будет реализовываться?

На последних скринах вижу какую-то базу данных по фильмам, типа Кинопоиска, но нужно понять именно, что должно происходить? Или это что-то десктопное с sqlite базой, или кушает по api какой-то сайт и выводит его базу или вообще какая-то комбинация с парсингом сайта и локальной/удаленной своей базой?
Или просто приложуха, как вебморда к пиратским сайтам с фильмами, типа lostfilm?
Всё, поиск рулит) онлайн кинотеатр))))
Вот бы его еще и на гитхабе увидеть

[Alex2013]

Я почитал ветку, но так и не понял конечный сценарий использования, который предполагается? Можно пояснить в двух трех предложениях?

Идей много но что-бы не "растекаться мыслью по дереву" пока что в основном волнует все тот-же запуск плеера с сайтов разнообразных онлайн кинотеатров.
Краткая история развития идеи:
Вначале была отличная программ Просмотра/Записи/Создания коллекций/Комментирования фильмов, сериалов , аниме, телепередач
FS Клиент

(Очень качественный продукт который радовал его пользователей в течение нескольких лет )

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

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

(Честно говоря я вообще был не уверен, что моего уровня знаний хватит на сколько нибудь даже отдаленное подобие FS Клиента но дело написания аналога несмотря все мое грандиозное невежество лень и разнообразные внешние "обстоятельства непреодолимой силлы " понемногу продвигается )


Для чего конкретно нужен "браузер в форме"? В первую очередь для возможности запуска плеера "в режиме предпросмотра". Для чего это надо понятно : далеко не все "сайты онлайн просмотра" удается проанализировать вплоть до получения "прямой ссылки на медиа контент" + "режим превью" должен быть простым универсальным и удобным, а что либо проще и надежнее запуска "штатного плеера" с сайта придумать довольно сложно .

Добавлено спустя 30 минут 45 секунд:

Вот бы его еще и на гитхабе увидеть

Ну вы слишком много хотите ( хотя кстати исходники FS Клиент-а там есть https://github.com/fsclient/fs-clone )

[delphius]

пока что в основном волнует все тот-же запуск плеера с сайтов разнообразных онлайн кинотеатров

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

запустил свой собственный до сих пор сильно "экспериментальный " проект

Отличный способ развиваться в теме, если программирование - хобби, не связанное с работой

В первую очередь для возможности запуска плеера "в режиме предпросмотра"

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

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

2. Вторичная проблема, это связывание медиаконтента с основной базой, но она, скорее всего больше техническая (навскидку - парсингом id медиаконтента из ссылок на imdb или кинопоиск) или же, если провайдер один, то вообще без связывания, просто "оборачивая" его сайт путем парсинга и вывода в приложении только необходимых элементов. Можно вообще не использовать стороннюю общую базу, а просто будут не связанные провайдеры. Но тогда это чистый парсинг.

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

Ну вы слишком много хотите

Ссылки на FS клиент вполне достаточно, хороший проект на c#, жалко, что все кончилось, насколько понял автор устал от правообладателей и не советовал никому продолжать его дело

И вывод: если сузить проблему до "точки изменений", то если сделать универсальный информационный проект без парсинга + часто изменяемый плагин на каждый "провайдер" для автоматической привязки контента к основной базе. И проблема тут в том, чтобы сделать его мало что универсальным, но и таким, чтобы его могли поддерживать в актуальном состоянии не специалисты (скриптовый метод + регулярные выражения).
З.Ы. Наверное, есть еще куча тонкостей (какие-то прокси и прочие ключи и авторизации), но я пытался оценить в "крупную клетку".
З.Ы.Ы. Про "крупную клетку" хорошо получилась аллюзия на "Небо в клеточку", с учетом спорности рассматриваемого вопроса
З.Ы.Ы.Ы. С api тоже беда, есть Кинопоиск, есть OMDB, все неофициальное и с маленьким лимитом бесплатных запросов, TMDB API - есть non-commercial purposes использование.

Upd.
Из доступного по парсингу у нас нашёл:
WebDriver4L Selenium Webdriver for Lazarus V 0.2 для Selenium.
Internet Tools библиотека для free pascal + статьи на русском
Все же XPath гораздо удобнее будет, чем ручками

Ну...или из Javascript на стороне браузера (API), но тогда теряется смысл полного контроля на стороне паскаля.

[Alex2013]

Начну с конца.
1 "Спорности вопроса" нет . Подобные программы вполне легально существуют в ассортименте.
И вообще они в принципе не предлагают ничего из того что нельзя делать прямо в браузере. ( я в свое время занялся поиском пробных программ даже не из за "навязчивой рекламы" ( ее можно отлично порезать прямо в браузере) просто программная оболочка позволяет пользоваться контентом в более комфортной среде и наиболее умные держатели ресурсов или сами озаботились написанием чего-то похожего или даже выложили в открытый доступ специальный АПИ )

2 Я сильно сомневаюсь, что в закрытии "ФС Клиента" виноваты именно "реальные правообладатели" или даже гипотетические "наезды пиратов" . Просто сложность доступа к медиа контенту на "серых сайтах" постепенно возрастает ( причем совершенно точно не по причине появления любительских "программных оболочек" для личного или обще-халявного использования ) просто одни пираты начали пиратить других "более благородных" ( ну или с "более далеко идущими целям и планам" ) реально держащих контент и оплачивающих место на серверах. ( Ведь сделать зеркало под другим названием и другой оболочкой или вообще "фишинговый сайт" и забить его своей рекламой заметно проще и несравнимо дешевле )
.
Разумеется, это моментально сказалось на усложнении доступа к контенту. Да и просто сайты онлайн кинотеатров растут и программы их поддержки тоже заметно усложняются. ( кроме того "реальные пираты" очень не любят слишком открыто светить сервера где лежит медиаконтент пусть это и довольно бессмысленное занятие ) .

3

. Вторичная проблема, это связывание медиаконтента с основной базой, но она, скорее всего больше техническая (навскидку - парсингом id медиаконтента из ссылок на imdb или кинопоиск) или же, если провайдер один, то вообще без связывания, просто "оборачивая" его сайт путем парсинга и вывода в приложении только необходимых элементов. Можно вообще не использовать стороннюю общую базу, а просто будут не связанные провайдеры. Но тогда это чистый парсинг.

и

И проблема тут в том, чтобы сделать его мало что универсальным, но и таким, чтобы его могли поддерживать в актуальном состоянии не специалисты (скриптовый метод + регулярные выражения).

УЖЕ !


"Лесхоз" практически изначально "идеологически " заточен на возможность "поддержки без автора" и вообще в будущем совершенно точно может не ограничивается парсингом ТОЛЬКО онлайн кинотеатров ( это просто наиболее "очевидно полезный" тестовый шаблон для привлечения армии добровольных бета-тестеров) Уже сейчас практически весь пирсинг происходит помощью очень простых скриптов и никак непривязан к конкретному сайту ( то что источник пока один виновата моя лень, а так-же желание в первую очередь "доработать функционал" и довести его хотя бы примерно до уровня сравнимого с комфортабельным "ФС Клиентом" )
Зы
Спасибо за ссылки! Посмотрю.

[Kopa]

Интересно, что заменив m64 на опцию m32 в makefile библиотека Webui нормально собралась под Linux32 (Puppy Linux Xenial)
а также примеры из Example собираются и запускаются c такой же заменой из каталога C (только с примером редактора есть неувязки с нахождением gtk/gth.h подключаемых файлов для сборки у меня)

[delphius]

библиотека Webui нормально собралась под Linux32 (Puppy Linux Xenial)

Если не сложно отписать об этом в в тему Is it possible to compile webui for 32bit systems?, конечно только в том случае, если контекст совпадает и есть желание

примером редактора есть неувязки

Их пример редактора меня не вдохновляет, если честно, начали бы со связывания данных и внедрения концепции "все на стороне ЯП", браузер - просто View

Добавлено спустя 49 минут 50 секунд:

программная оболочка позволяет пользоваться контентом в более комфортной среде

В качестве proof of concept, в режиме выходного дня накидал в реакте макет компонента для карточки, прикрутил к паскалевской части WebDriver4L, правда его пришлось основательно покурочить под fpc (закомментить все функции работы с изображениями + изменить через функции Windows API запуск chromedriver.exe в скрытом режиме, чтобы не отсвечивал, плюс переключить браузер в headless режим, чтобы тоже не светился в работе )


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

Мне работа через WebDriver4L для продакшена не понравилась, оч долго и слишком сложная конструкция получается: паскаль - библиотека WebDriver4L - chromedriver.exe/msedgedriver.exe - сам хром/edge - загрузка страницы - парсинг - закрытие. Проверил два движка, задержка сопоставимая.

Надо будет попробовать Internet Tools.

Но XPath - вещь, вся магия с данными для карточек уложилась в две строки кода:

Код: Выделить всё

films := Robot.FindElementsByXPath('//*[@id="dle-content"]/div[*]/div[1]/a/img');
paths := Robot.FindElementsByXPath('//*[@id="dle-content"]/div[*]/div[1]/a');

[Alex2013]

Ух ты! "Говорящая рыба"! Очень интересно.
( У меня в принципе тоже были идеи сделать все через Web-тех но она завяла после попыток написать чуть более продвинутый функционал с простыми JS-скриптами так что просто немного перекурочил обычный TListView )