CODEWITHSUNDEEP
pythonlocalwsgi
user93202
user93202

Reputation:

Embedded WSGI backend for Python desktop app using webkit

Disclaimer: I'm not very familiar with any of the things mentioned in the question title.

Would it be possible to use a browser control (like Webkit) as a frontend for a WSGI app (using a framework like Flask) without starting a local WSGI server?

Basically the requests and responses are managed by a middle layer between the HTML UI and the WSGI backend. A certain URI could mean "Local", for instance "local://" or something similar, and will be routed to the embedded WSGI app with all the original headers etc.

You will lose any features that a normal WSGI server provides unless you implement it yourself or somehow embed a server that is also usable via an API instead of real HTTP requests.

Now that I think of it, this is the only real requirement: A WSGI server that is callable via an API and not just real HTTP requests.

I know the usefulness of this is questionable (and maybe doesn't even make sense). My question is whether this is at all possible?

EDIT: Here's another way of putting it:

I want a single codebase to be both a web app and a desktop app, using an HTML frontend and a Python backend. I don't want to run a server on any port for the desktop app. What's the easiest way to achieve this?

Upvotes: 8

Views: 994

Answers (3)

Macke
Macke

Reputation: 25690

Reviving this, since we're facing the same problem and are about to scale things up from a single view/widget to the whole app.

What I did was to simply set the base URL to something where I serve static content, and from a QRC file that's easy:

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

For the communication, our HTML uses AJAX over jQuery for most things. You could wrap that in a layer that either does $.post(...) or api.post(...) like this:

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

You'd need to decode the URL and create a request object yourself, but maybe that's not too hard to do? We use very few URLs currently (who are mapped directly to python objects/functions) so it's easy to do the mapping ourselves.

Data that goes back is just sent using QMainFrame.evaluateJavaScript(...), either as a direct Qt call or as a bunch of code lines fetched using $.getScript(...) (which just evaluates the code received).

I'm currently rebuilding things a bit using CherryPy, and it maps urls -> Python objects straight off, so I'm hoping there's something to be gained by that.

Otherwise, I would wish one could run QWebKit over named pipes or something similarly localized and not a tcp-socket. :)

Upvotes: 0

Ignacio Vazquez-Abrams
Ignacio Vazquez-Abrams

Reputation: 799170

It is in theory possible to write your own WSGI container that implements a full API and adapts that to WSGI. flup might bring some inspiration.

Upvotes: 1

synthesizerpatel
synthesizerpatel

Reputation: 28036

Earlier today I saw exactly what you're asking for -- a way to call WSGI through an API without actually connecting over the network. However, it shouldn't be that hard.

On a side note, you might want to look at PySide, of particular interest to you may be the ability to bind python elements to DOM events, so if you're just looking to trigger python code that's an even shorter route.

If you give some more detail on what you're hoping to achieve we might be able to dial it in for you.

Upvotes: 0

Related Questions