GUIs - A Modest Proposal

[lkcl]

On Jun 14, 5:57 pm, rantingrick <rantingr... at gmail.com> wrote:
> I'll have to very much agree with this assessment Stephan. There
> exists not elegant API for these "web" UI's. The people over at
> SketchUp (my second love after python) have this problem on a daily
> bases with WebDialogs. Even the javascript gurus have a dificult time
> juggling javascript, CSS, and Ruby code to make these grumpy beasts
> come to life, and when they do it ain't really pretty.

 ah.  again, the "recommended" pyjamas development model vs the
"standard" development model comes to the rescue, here.  in a pyjamas
app, the app loads ONCE and ONLY ONCE, as one whopping great
javascript behemoth which can be somewhere around 2mb if the original
python (pyjamas) source is around... 15 to 20,000 lines of code.

 from thereon in, you DO NOT do *any* HTML page "GETs": it's a one-
time static HTML/JS load, and THAT's IT.

 the only further interaction that we recommend is first and foremost
JSONRPC (and so, out of the 30 or so pyjamas wiki pages, about 10 of
them involve HOWTOs for interacting with django, pylons, web.py,
web2py, twisted and so on) and the second one, because you have to, is
HTTP POST of Multi-Part FORMs.

 even with the HTTP Forms, you _still_ don't have to leave the "main"
pyjamas (static JS) application page, because the GWT team, bless 'em,
came up with a way to do a hidden iframe which does the HTTP POST in
the background.  _well_ smart cookies, them GWT boys - and we just...
lifted it straight into python :)

 so there's _zero_ further "webuhhh pagizz lohdinn".

 we found some really smart cookie's jsonrpc server-side code, which
turns out to be a stonking JSONRPC service in under 30 lines of code,
where you can turn absolutely any python code, pretty much, into an
RPC service with one import line, one line of code and then one
decorator per function you want to be in the JSON RPC service.

 this approach, on its own, drastically simplifies python web service
development.  now your entire server-side web service is implemented
in terms of *data* _not_ the presentation-of-the-data-mixed-in-with-
the-data-and-oops-er-maybe-a-little-bit-of-javascript-oh-hell-actually-
it's-a-lot-of-javascript-and-oh-god-here-we-go-again-how-do-we-debug-
this?

the only down-side of this approach _would_ be that you'd now have to
do everything as a JSONRPC client, which if you were in "pure
javascript land" would truly be absolute hell on earth.

 _but_... as we're talking python... ta-daaa! easy :)

 ok, not _entirely_ easy, because it has to be done asynchronously.
make the call, then wait for a response, timeout or a server error -
but, guess what?  you can create a python class with functions
"onResponse", "onError" and "onTimeout" which will be called when the
function has completed (or not) on the server.  ta-daaa :)

 running example:
    http://pyjs.org/examples/jsonrpc/output/JSONRPCExample.html

 pyjamas client-side code:
    http://pyjs.org/examples/jsonrpc/JSONRPCExample.py

 so - pyjamas developers _don't_ have the same "juggling" problems
that the "average" advanced AJAX + web-service programmer has, because
everything's compartmentalised along MVC lines:

   http://www.advogato.org/article/993.html

 i would say that GWT developers don't have the same problems, but
because java is a strongly-typed language, they have a biatch-and-a-
half god-awful time carrying out type-casting of JSONRPC parameters
and the function return type when it comes back from the server,
_even_ though the target language of the compiler is dynamic -
javascript!

 poor things.  haw, haw :)

 l.