On Jun 14, 7:30 pm, Stephen Hansen <me+list/pyt...@ixokai.io> wrote:
> On 6/14/10 11:47 AM, lkcl wrote:
>
> > On Jun 14, 4:17 pm, Stephen Hansen <me+list/pyt...@ixokai.io> wrote:
> > yes. that's effectively what pyjs applications are about: as much
> > HTML/CSS as you can stand, then _absolute_ pure javascript from there-
> > on in... only using a compiler (python-to-javascript) so as not to go
> > completely insane - and, from the rest of your message, i _know_ you
> > know what i'm talking about, there :)
>
> Yeah. It sounds very interesting. I just wish it, like, somehow bundled
> webkit cross-platformly. :)
>
> > to be absolutely honest, i very rarely even write my own widgets: i
> > advocate that people, myself _especially_ myself included, perform
> > literal line-for-line translations of GWT widgets from java to
> > python. why? because, again: on the basis that google have tons of
> > money to put into GWT widgets, doing full regression tests, and have
> > thousands of users, they can afford to get the widget right across all
> > the browsers. ergo, why duplicate that effort - just code-translate
> > it verbatim!
>
> > oh, btw, that's turning into quite a powerful project on its own: the
> > goal is to have a fully automated java-to-python translator!
>
> > http://github.com/thoka/java2python
>
> Somehow this is getting perverse. Java, to Python, to JavaScript. It
> just sounds sort of incestuous. :)
>
> But also worth looking into for my next web project.
>
> >> Traditional GUI models vs the web layout model are just alien to one
> >> another, and the latter is -extremely- convoluted.
>
> > we've found that there's a third "hybrid" case, and it's hinted at
> > through RIA javascript libraries such as extjs: a traditional GUI
> > model *implemented* as a web app.
>
> > so those RIA JS libraries are not "vs", they're _both_. except...
> > javascript has its own headaches, so that's why both pyjamas and GWT
> > remove _those_ headaches, by using language translators.
>
> Well, yes. I have some experience with extjs (and making some pretty
> fantastic real-world seeming apps on the web with it), and yeah,
> removing Javascript headaches is a very interesting goal. (Pet peeve to
> end all pet peeves: trailing commas in objects breaks IE. I always leave
> trailing commas, always, in Python code: makes adding stuff easier
> later. And I can't shake doing it in my javascript instinctively).
>
> The current project occupying my time involves a fairly complicated mix;
> on the server-side we have Pylons, but its interfacing with an external
> application server, so about half of the Pylons layers are "outsourced"
> (i.e., data and model access).
>
> Then the web interface is ExtJS. Its just getting very, very -- ungainly
> from a maintenance point of view. Maybe on its next iteration I'll look
> into pyjamas.
>
> >> Now, I do not know QT, but I know wx -- which is implemented
> >> in temrs of gtk, so somehow the wx team got it working on GTK.
>
> >> wx uses a complicated recursive layout engine (unless you're mildly nuts
> >> and try to do absolute layouts) which in all essence does *exactly* what
> >> you are describing there.
>
> > oooOo. that's _very_ interesting to hear. i'd assumed that there
> > wouldn't be anything "beneficial" that wx would bring to the table, by
> > using gtk. ha. that might be worthwhile doing a pyjd-wx port, then,
> > after all. hmm.
>
> Well, I may have overstated it a little bit by mistake.
he he. rats!
> wx does not require you use this model, and it does not do it on its own
> -- you do have to "design" the flow a little bit.
>
> wx has two separate containment hierarchies. The first is a
> hierarchical, parent->child relationship. This is what a lot of people
> think is its layout: but its not. It has nothing to do with layout, but
> instead its more about event propagation.
oh crap, yeah, i forgot about that. event propagation rules. darn
it. y'know what? forget it - i might as well, seriously, help
implement an entire modern web browser in python, and use that.
> Ahem. /Rant. I'm not saying its the best layout system in the world, but
> like your DOM/HTML example -- its resolution independant (and
> cross-platform), so you can start resizing things and changing the
> window size and it all reflows things as the window resizes. Lots of
> toolkits can do that, but I just really find the sizer approach both
> flexible and very powerful to achieve very usable interfaces. (And its
> very web-like, except the semantic difference of the two hierarchies)
*sigh* i think i'm just going to have to try it, just to find out. i
can't have me saying "all desktop widget sets are rubbish!" if i
haven't _actually_ gone and done my homework, can i?
> > from there, you just... open it up in a web browser, just like you
> > would any other HTML/CSS/Javascript app.
>
> Well, I got that much; I more meant the Pyjamas-Desktop thing.
ohh, right - sorry.
> It makes
> regular "seeming" application/client-based user interfaces, right? Are
> those all entirely, once run, 100% JavaScript (post-compilation)?
nope not in the slightet - the javascript is literally out the
window, bypassed entirely. that same application you had which was
the input to the pyjsbuild compiler "pyjsbuild Hello.py"? you just...
run it! just like a pygtk2, pyqt4 or python-wx app:
python Hello.py
in the background, what happens is that the "shim" library DOM.py
(which is the one with the most javascript in it) is *replaced* by an
alternative which is pure python, and which uses the COM wrapper
(MSHTML), or the XPCOM wrapper (XulRunner) or pygobject (pywebkitgtk)
to *directly* do the *exact* same equivalent jobs of the JS-converted
code... only this time, now "direct" in python to the exact-same-named
DOM functions, properties etc. the whole damn hog: everything that's
in JS in a web browser, it's accessible via python bindings to MSHTML,
XulRunner or (a hacked version of) pywebkitgtk.
but, as a developer/user you _do_ not need to know that - all you
need to know is: the python code runs, it throws up a window, the
application's in it, it's on the desktop, it's not a web browser,
that's the deal.
> If so, Desktop at least isn't useful to me. :( I can't access omniORB
> with it :)
yeahh, you can... but then if you actually wanted it to be a web app
as well, you'd be hosed (unless you want to create a browser plugin /
extension which can talk omniORB!)
what we typically recommend is that _even_ though you're going to run
the application "desktop" - as pure python - you still use JSONRPC [or
XmlHTTPRequest if JSONRPC is overkill]. so, _even_ though it's a
desktop application, you still run a local 127.0.0.1 web service (even
python -m SimpleCGIServer.py will do the job!)
rick's article is highly illustrative on all these points:
http://www.ibm.com/developerworks/web/library/wa-aj-pyjamas/
there are kiinda good house-keeping reasons for taking this approach:
it forces a developer to break the app along MVC-like lines. that
service is _only_ going to be serving data; you could even write unit
tests using a python-based JSONRPC client, and so on:
http://pypi.python.org/pypi/lovely.jsonrpc
http://lkcl.net/jsonrpclib.tgz
i think rick points out these json clients or better, and demos how
to use them.
so it's not as "forced" a development approach as it seems.
but, yeahh, if you absolutely must, you can use "standard" python
libraries - the only thing you'd have to watch out for is that
anything you call musn't take too long, because you're in the middle
of the (effectively single-threaded) GUI loop at the time. this is
another very good reason for taking the client-server approach _even_
though you'd be running the server on 127.0.0.1.
all the methods by which you would have to deal with that GUI loop
problem have to be asynchronous _anyway_... aaand, what the heck, why
not just go with the flow and use the pyjamas.HTTPRequest or
pyjamas.JSONService recommended services, neh?
l.
--
http://mail.python.org/mailman/listinfo/python-list
