[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Freemed new features

From: lkcl
Subject: Re: [Gnumed-devel] Freemed new features
Date: Fri, 9 Jul 2010 13:02:50 -0700 (PDT)

Sebastian Hilbert wrote:
> There are various other effort like pyjamas which tries to compile python
> into 
> javascript.

it doesn't "try" - it _does_ :)  i think you have the same feeling that i
did when i first looked at the concept.  i thought, "how in seven kinds of
hell's teeth do i connect the dots, mentally, here??" and it was about a
year before i got sufficiently sick to the back teeth of HTML/CSS
time-wasting that i decided to bite the bullet.

that wooliness went away once i had (really quite excitedly!) created my
first application, only to be replaced with a sense of... unease at the lack
of debugging support from web browsers...

... which is _precisely_ why we added a "-d" option which emulates the
python stacktraces by recording what function you are presently in, and
throwing a try { } catch {} block around *every* single line of (translated)
code - yes you can imagine how much code this adds (4x) but if you haven't
anything else, you _will_ use it...

... and it is also precisely why i did a desktop port of pyjamas, turning
"from pyjamas.ui.HorizontalPanel" etc. into a REAL python application.

i'll repeat that again, because it often takes a while for the significance
to sink in: a pyjamas application can be run as a *DESKTOP* application. 
_unmodified_.  the pyjamas UI Widget set API, thanks to pyjd, is a
competitor to python-wxWidgets, python-gtk2, python-qt4 and so on.

so by developing the application as _both_ a desktop application _and_ a web
application, you've made the development cycle easier and you've gained the
advantage of only having to write and maintain ONE application.

Sebastian Hilbert wrote:
>  In the end there is a huge variety of toolkits and frameworks

 yah.  the thing about javascript is that it is obtuse and archaic, and is
also often confused with the W3C DOM TR1-3 and HTML5 specifications.  i
don't want to scare you at all, but if you look at the HTML5
implementations, by tracking down the IDL files for WebKit, XulRunner and
MSHTML (IE's engine), there are a whopping 400+ DOM node/object types,
3,000+ functions and 20,000+ properties.

toolkits and frameworks attempt to simplify this, but because they do so in
"javascript" it's like trying to make intricate gold jewelry with a rusty

by making a framework so much like a desktop widget set API that it
LITERALLY CAN BE run as a desktop widget set API, you take away a
significant amount of the pain and massive learning curve.

... not all of it, but at least some :)

Sebastian Hilbert wrote:
> There seems to be no straighforward way to have a python application use
> GWT 
> or extJS or any Javascript toolkits.

 yes there is - pyjs! :)

 ... oh, you mean actually run python _in_ the web browser engine, < script
language="text/python" > style?  ahh, then you want some of the technologies
i've been keeping an eye on and listing here:

for example, pyxpcomext (along-side xpcom) _literally_ does exactly that:
adds language="text/python" ahhh.. wait... but it only adds it to firefox,
not webkit and not IE.

or... how about Silverlight, with appcelerator and titanium?  oh... wait....
that only adds python (and ruby) DOM access to IE, not to firefox, and
certainly not to webkit.

so, whoops, you're screwed :)

Sebastian Hilbert wrote:
> Feel free to correct me as the above statements are made knowing little
> and 
> reading a lot lately about web developement.

 honestly be delighted to :)

Sebastian Hilbert wrote:
> I guess the biggest problem with webinterfaces it that developers often
> mimic 
> desktop applications. However on the desktop there is no back button. User 
> like me put a lot of effort into breakin any webapp by creative use of the 
> back button.

ah.  web 2.0 applications are completely different (such as GWT and pyjs
apps).  you load the "page" ONCE AND ONLY ONCE, and from there-on-in you
*only* use AJAX, and the AJAX fetches data.

thus, you've automatically subdivided the application down along MVC lines.

just like you would with any well-designed desktop application (except here
you're forced to take those steps).

but the reason for mentioning that is that there is a sliiight problem: the
"back" button now has only one page.  so, if you ever press it, you leave
the entire application.  to "workaround" this problem, there's a known
"trick": you create a hidden iframe (not kidding!).  you target this iframe
with the "click" that you made, and you have a timer (!) which watches the
hidden iframe's target URL, and you then "take action" based on the URL.

it's crazily higgley-piggledy but at the "top level" API it's incredibly
simple and involves.. what... five lines of code, and you now have "History"
again, and can now properly use "Back" and "Forward" to change tabs and so

and the neat thing is that because you're using AJAX to fetch data, the
entire "problem" of "breaking" the web application by users randomly
clicking back and forward is.... gone.


because "back" and "forward" now are turned into "select the previous
application tab" and so on, under the developer's control, via a callback in
the application's class instance, "onHistoryChanged(self, token)".

View this message in context:
Sent from the GnuMed - Dev mailing list archive at

reply via email to

[Prev in Thread] Current Thread [Next in Thread]