Встроенный бэкэнд WSGI для настольного приложения Python с использованием webkit - PullRequest
Новая
       7

Встроенный бэкэнд WSGI для настольного приложения Python с использованием webkit

8 голосов
/ 19 августа 2010

Отказ от ответственности: я не очень хорошо знаком с вещами, упомянутыми в заголовке вопроса.

Можно ли использовать элемент управления браузера (например, Webkit) в качестве интерфейса для приложения WSGI (используяфреймворк, такой как Flask) без запуска локального сервера WSGI?

В основном запросы и ответы управляются промежуточным уровнем между пользовательским интерфейсом HTML и бэкэндом WSGI.Определенный URI может означать «Local», например «local: //» или что-то подобное, и будет перенаправлен во встроенное приложение WSGI со всеми оригинальными заголовками и т. Д.

Вы потеряете все функции, которыеобычный сервер WSGI обеспечивает, если вы не внедрили его самостоятельно или не внедрили сервер, который также можно использовать через API вместо реальных HTTP-запросов.

Теперь, когда я думаю об этом, это единственное реальное требование: Сервер WSGI, который можно вызывать через API, а не только через реальные HTTP-запросы.

Я знаю, что полезность этого сомнительна (и, возможно, даже не имеет смысла).У меня вопрос, возможно ли это вообще?

РЕДАКТИРОВАТЬ: Вот еще один способ выразить это:

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

Ответы [ 3 ]

1 голос
/ 09 декабря 2010

Теоретически возможно написать собственный WSGI-контейнер , который реализует полный API и адаптирует его к WSGI. флюп может принести вдохновение.

0 голосов
/ 07 октября 2011

Возрождая это, так как мы сталкиваемся с той же проблемой и собираемся масштабировать вещи от одного представления / виджета до всего приложения.

Я просто установил для базового URL-адреса что-то, где я работаю со статическим контентом, и из файла QRC это просто: 

html = jinjatemplate.render(...)
self._mainFrame.setHtml(html.decode('utf-8'), Qt.QUrl('qrc:///Orsync/html/'))

Для общения наш HTML использует AJAX поверх jQuery для большинства вещей. Вы могли бы обернуть это в слой, который или $.post(...) или api.post(...) выглядит так: 

self._mainFrame.addToJavaScriptWindowObject('api', self._webapi)

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

Данные, которые возвращаются, просто отправляются с использованием QMainFrame.evaluateJavaScript(...), либо в виде прямого вызова Qt, либо в виде набора строк кода, извлекаемых с использованием $.getScript(...) (который просто оценивает полученный код).

В настоящее время я немного перестраиваю вещи с помощью CherryPy, и он сразу отображает URL -> объекты Python, так что я надеюсь, что это что-то даст.

В противном случае, я хотел бы, чтобы кто-то мог запускать QWebKit по именованным каналам или что-то подобное локализованно, а не по tcp-сокету. :)

0 голосов
/ 07 декабря 2010

Ранее сегодня я увидел именно то, что вы просите - способ вызова WSGI через API без фактического соединения по сети.Тем не менее, это не должно быть так сложно.

Кстати, вы можете захотеть взглянуть на PySide, особенно вас может заинтересовать возможность привязывать элементы python к событиям DOM, поэтому, если вы просто хотите запустить код Python, этоболее короткий маршрут.

Если вы дадите более подробную информацию о том, чего вы надеетесь достичь, мы можем набрать его для вас.

...