Re: [Gnumed-devel] web client via pyjamas

[lkcl]

Sebastian Hilbert wrote:
> 
>> Note that I have little knowledge on the various toolkits but from the
>> link
>> you provide it looks like if anyone feels home at python but not at
>> javascipt has a toolkit here to develop an UI as an wxpython alternative.
>>
>> Two humble questions.
>> How does this compare to tubogears or django which is python as well ?
> 

 ah.  those are server-side frameworks.  they are designed to create
primarily static HTML as a first priority, throwing in a bit of javascript
(woo-hoo!) if you feel comfortable with that as a second priority, and maybe
(yippeeee!) doing some AJAXey nicey stuffey which makes everrbodey sooo
happey as a third priority.

 pyjamas is _purely_ a client-side (widget set) framework, where we have
over 50% of the wiki pages as HOWTOs on how to connect using AJAX (actually
JSONRPC) to the various python web server frameworks.  because we like them
:)

http://pyjs.org/wiki/ - you can see direct mod_python access, cherrypy, kay,
bobo, turbogears, pylons, webpy, web2py, django - you name it, it's there.



Sebastian Hilbert wrote:
> 
>> Is database access possible through psycopg ?
> 

 ah.  no.  this is on the FAQ: it's a very common misconception.  you're
running javascript: how could you?  do all web browsers have a psycopg
plugin?  no.  therefore, it's out the window.

... but that's ok, because you can split the application along MVC lines,
use JSONRPC to perform the data query to the server, which performs the
psycopg query on your behalf, and returns the data.

simple.  dead simple.

two important things:

1) you go and download lovelyjson or jsonrpclib.tgz and you write unit
tests, to test the JSONRPC service directly from python.

2) direct use of psycopg - even from the gnumed current wxWidgets
application - "hangs" the application, doesn't it?  because it's a
synchronous function call.  the entire gnumed application grinds to a halt,
becoming totally unresponsive to mouse and keyboard input and to screen
redraw requests, if the database query is particularly large or takes a long
time, doesn't it?

by splitting the app along MVC lines, and using the "a" of AJAX (actually
JSONRPC on top of Asynchronous Javascript And XML), you get the
"responsiveness" back.

a pyjamas application DOES NOT "hang" just because there is an outstanding
JSONRPC request underway... because it's been done *asynchronously*.

this makes for a slight mental adjustment and initial obtuseness BUT if you
stick rigidly to that MVC principle, you'll do okay.

but - you've been doing asynchronous app design for what... years already,
with event handling in python-wxWidgets on keyboard, mouse and other events,
so i'm telling you nothing new here: you're just extending those event/async
concepts over to the data as _well_, and gaining some advantages in the
process.



Sebastian Hilbert wrote:
> 
>>
>> So my question really amounts to how much code can be reused from the
>> middleware or is pyjamas the option to only rewrite the frontend code and
>> reusing large parts of the GNUmed middleware ?
> 

 take a look at what i did in fontforgeplugins:
   http://github.com/lkcl/fontforgeplugins

 basically i simply added a JSONRPC service into fontforge, as middleware. 
with only about... 80 lines of code, i was able to get enough out of
fontforge, over JSONRPC, to be able to display and draw fonts inside a
pyjamas app.

 if the GNUmed application is _already_ divided into middleware, then GREAT! 
the job will actually be incredibly, incredibly easy.  and probably really
quite boring to code up, or possibly it could even be automated with a
little care and thought, if your meta-python-programming skills are up to
it.


Sebastian Hilbert wrote:
> 
>>
> I have read through some of their documentation an it seems like pyjamas
> could 
> be the develop once, deploy anywhere toolkit.
> 
> In the past I was looking for something like a wxwidgets-to-webapp (insert 
> your toolkit here) wrapper , or a qt-to webapp wrapper. There are some
> efforts 
> to bridge the gap between the desktop and the web but most are just
> starting.
> 

you find something like that _please_ tell me - i really want to know about
it.


Sebastian Hilbert wrote:
> 
> 
> On the other hand the web has started to go for the desktop. Ajax and co
> have 
> started to immitate desktop applications.
> 

it's more that it's dawned on people that AJAX _can_ be used to create web
applications that imitate desktop applications.  by the time you get to
creating RPC systems out of it (such as JSONRPC) then you're into much saner
and safer territory, and the application _really_ begins to become
"desktop-like".


Sebastian Hilbert wrote:
> 
> 
> Mozialla and google are starting to work on solutions where you write a
> webapp 
> and have them running like desktop apps (invisible to the user).
> Technologies 
> like Adobe Air and so on are appearing.
> 

_don't_ even think about using Adobe AIR.  it's proprietary.  you'd likely
lose the status of gnumed as a GNU application if you did.

i am curious to hear about the solutions you're referring to about
mozilla/google transparently running desktop apps in a browser.  are you
referring to the efforts of google chrome to add (sandboxed) x86
code-execution into the actual browser engine?


Sebastian Hilbert wrote:
> 
> 
> Having said that it seems that pyjamas is the first FOSS effort to make
> apps 
> written in python run in the browser and the desktop off the same
> codebase.
> 

ya.  basically - yes.  an ambitious and bold but entirely true claim.  two
things:

1) it's a cheat :)  i'm using python bindings *direct* to the exact same W3C
DOM functions that are made available via javascript when you run javascript
directly inside web browsers.  so, you chuck away the "firefox" U.I. and you
use xulrunner (actually hulahop, the OLPC browser GTK plugin).  you chuck
away "Safari" and you use WebKit (actually a modified version, and a
modified version of pywebkitgtk); you chuck away "Internet Explorer" and you
use Python COM bindings (!) to an IWebBrowser2 OCX control, running the
MSHTML engine *direct* into a Win32 GDI window!

in this way, you can see that the exact same functions
"getElementsByTagName" and so on, all of which are hidden from you behind a
convenient Desktop-Widget-Set-looking API _anyway_ - are accessible from
pyjs because you converted the entire code to javascript, or from pyjd
because you threw *away* the javascript entirely, bypassed it entirely, and
made a beeline for the DOM functions - all of them - using python.

2) of all the runtimes, ironically, the MSHTML one - the one that uses
non-free proprietary software - is the most "stable", thanks to lack of
interest and in some cases outright hostility by the free software
developers behind the alternative competitor products to IE.

i'm looking to alleviate 2) by taking the old "grailbrowser" - don't laugh -
the old web browser in python which used to run under python 1.5 and 2.0 -
and creating a pyjd runtime based around it which will be entirely pure
python and will not have any dependencies on the whims of microsoft, the
mozilla foundation or on apple employees.

i say "don't laugh" but please feel free to, it really is hilarious to think
that code written for python 1.5 is still relevant, when the internet has
moved on so much.

l.

-- 
View this message in context: 
http://old.nabble.com/web-client-via-pyjamas-tp24343193p29122204.html
Sent from the GnuMed - Dev mailing list archive at Nabble.com.