Pyjamas: Write your own AJAX Framework
pyjamas is a stand-alone python to javascript compiler, an AJAX framework / library and a Widget set API.
Nope. "standard" AJAX frameworks and widget sets are written in javascript, a low-level alien language with weird complexities that is often confused with not only the browsers it runs on but also the DOM model set of functions that are provided as standard with the browsers. When you use a "standard" AJAX framework, there is an expectation that you will just "use" it - never look at the framework, never get involved with its development or improvement, and if that AJAX framework doesn't do what you want, tough luck - find another one.
Pyjamas is a totally different approach: it brings "Declarative Programming" (in python) to the Web. You are given a comprehensive set of base classes and modules - written almost 98.5% in python - and you can then write your own applications, classes and modules and call it "My Own AJAX Framework". And, as you are writing in a much higher level language than Javascript, it's a darn sight easier.
No.
No.
No.
No.
No.
You can't: browsers only support javascript. So, all source code - libraries and applications - are translated into pure javascript. No python is left. at all. Otherwise, it wouldn't work, would it?
It's magic. smoke. mirrors. the usual stuff.
Nope.
Nope.
It helps if you know a little bit about how CSS works, because the Pyjamas User-Interface widgets, like all Widget Sets, are designed around "function" and "purpose", not "form" or "look". It would also help if you had a basic grasp of a tiny bit of HTML, such as what <b> etc. does. For everything else, such as tables, there are Widgets such as Grid that are much more practical to use.
Pyjamas Web development actually has more in common with Python-Qt4 and Python-GTK2 than it does with "traditional" web development. The base widgets (of which there are over 50) have almost exact corresponding analogues in Desktop Widget sets. The nice thing about Pyjamas, though, when compared to the Desktop Widget frameworks is that you get "true" HTML / CSS interoperability, and "true" plugin support such as Adobe Flash, all for free.
We get quite a number of people who have never done user-interface programming before in their lives on the pyjamas-dev mailing lists, let alone having done any web programming: you're in good company.
Start with the "getting started" tutorial, ignoring the first paragraphs because they don't apply to you! Many web designers actually have to "unlearn" their expectations that this is going to be horrendously painful, and you are at a distinct advantage because you've not experienced their disillusionment and frustration of the past decade, over CSS, browser and AJAX incompatibilities.
Absolutely anything you like. Literally anything. CGI-Scripts, ASP/.NET, PHP, Apache, WSGI - you name it, you can use it. The reason is simple: the Pyjamas python code gets compiled to some HTML and some Javascript - that's it. So, just like any web pages, you simply need something that will load ... web pages. duh.
This is a highly subjective question, but if you are new to web development, you will be asking these kinds of questions. Given that you're considering python, logically it makes sense to pick a python-based web framework. If you're going to do AJAX, you should really use JSONRPC. If you're using JSONRPC, you should pick a framework that is known to have mature JSONRPC server-side support, and that means Django, Web2Py, and many more. See the Pyjamas Wiki for links to various JSONRPC integration HOWTOs.
That having been said: if you're starting entirely from scratch, Django has to come out overall on top, even though you will not be using all of its features. The SQL ORM in Django is excellent; the tutorials to get started are excellent; the developers and users on the (busy) IRC channel are very helpful and responsive.
Unless you have already designed the application to exclusively use AJAX in one form or another (REST, JSONRPC etc.) then it's pretty much a complete redesign. The reason is simple: "standard" web applications load up one page at a time from the server, with possibly some bits of javascript thrown in. Pyjamas applications are loaded once, as they are pure javascript.
From that point onwards, unless you want another large javascript "hit", the entire application should use AJAX to fetch any data, including HTML. If that sounds like it's a bit different from "normal" web applications, you'd be right. It's more like "Desktop" application development.
So - you can convert the Django (or other web app) one page at a time, to a format which separates out the data from its display. In other words: by the time you're done, there will be no templates left, only JSONRPC services (or other AJAX service / system). If that sounds like a lot of work, then you can temporarily embed the templates on-demand into iframes, either using a pyjamas.ui.HTMLPanel or by using a pyjamas.ui.Frame widget. If you've been told that Frames are a bad idea, you'd be right in the "normal" web development world, but completely wrong in this "Desktop-like" case. Thanks to the Pyjamas API, it's possible to set width and height and to react to Window Resize events, and thus to change the entire layout of the application depending on the user preferences, requirements, browser type and window size (as is done in the Pyjamas Mail example).
Pyjamas is an independent free software project that is used by people who prefer to actually get on with the job of writing apps, rather than glorying or revelling in the frustration of "traditional" web development. Hitting your head against a wall continuously every day doesn't hurt any more when you stop doing it, and much of "traditional" web development - of dealing with all the browser incompatibilities at a low level - can be considered to be the same as brick-wall-nutting.
In other words, you're here gaining the benefit of the experience of people who have spent quite some time searching out - and then improving - the Pyjamas Technology, to make their own lives easier. If there's an area which isn't clearly documented, you might like to consider funding them to tell you about it.
That having been said, there is actually one heck of a lot of documentation: see the main Pyjamas site for links to the tutorials, the Pyjamas Book, the API reference guides, the Showcase example which includes source code examples for each type of Widget and Panel (that can be cut/pasted into your app), and much more. If that wasn't enough, the GWT User-Interface modules on which the Pyjamas UI modules are based are so similar that even the GWT documentation is still relevant and useful.
That's because there's a ton of documentation on the W3C standard DOM Model and the W3C standard browser XML standard, and duplicating that in the Pyjamas project would be a great deal of work and would imply that the Pyjamas project is somehow an authority over-and-above the W3C. Use a google search for "W3C DOM XML", "W3C DOM", "W3C DOM Javascript" and other such searches to find so much documentation and help on the subject that you'll be staring at it for days.
Then, start by looking at pyjamas/DOM.py and you will notice that there is a massive prevalance of javascript snippets (way more than any other pyjamas module). It should be plain as day that DOM.py is a way to make the W3C DOM model of web browsers appear to be easily accessible, in python.
Lots of things.
[Personal note from lkcl: I've done a lot of free software development, and I've never, despite trying, been able to cover exactly everything, first time, on reporting a problem / asking for help. Software development is complex. "Full" reports are rare and time-consuming for the person writing them, but that's just part of your job of writing your app. The key thing is that there should be enthusiasm behind what you're doing: a good developer on a free software project will be able to instantly tell that you're being enthusiastic (and are showing a willingness to adapt), and will likely make allowances that they would otherwise not tolerate. The bottom line is, therefore: use your judgement; provide as much information and context as you can; give some sort of indication of willingness to follow the advice given; follow the advice given; provide people with evidence that you've followed it (or an explanation as to why you haven't), and say thank you if the advice helped.]
There are so many things you should be doing to determine the cause of "it ain't working" it's almost unreal. But before answering in more detail, it's important that you know what pyjamas is and is not. First off: pyjamas is a compiler, not a debugger. It's the equivalent of "gcc". Actually, if you know how gcc works, pyjsbuild is the equivalent of "gcc" and pyjscompile is the equivalent of, for example, "/usr/lib/gcc/x86_64-linux-gnu/4.3.3/cc1". In other words, gcc and pyjsbuild are the general-purpose "front-ends", and cc1 and pyjscompile are the actual nitty-gritty compilers.
You need to be aware of this because you cannot expect pyjamas, a specialist compiler, to also take on the task of being the debugger, or to incorporate the tasks performed by tools such as pylint, or to be the virtual machine under which the javascript executes, or to be a javascript code-compressor, or to do any other task other than actual compiling.
With that in mind, here are some things that you can do:
Overall, then, it's important to remember that pyjamas is a compiler, not an interpreter, not a debugger, syntax checker or anything else other than a compiler. This may be a bit of a shock if you are used to the python interpreter throwing helpful stack traces for you - which is what Pyjamas-Desktop is there for: it actually runs Pyjamas applications as real python, not as javascript.
There are four main ways:
from pyjamas import Window
Window.alert("Hello, here is an error")
My favourite: add some HTML to the end of the page:
from pyjamas.ui.RootPanel import RootPanel
from pyjamas.ui.HTML import HTML
RootPanel().add(HTML("hello, here is an error")
Another approach is to follow what examples/libtest/write.py does,
which you should just consider blatantly copying:
from pyjamas import DOM
def getBodyElement():
JS(""" return $doc.body; """)
def write(text):
global data
data += text
DOM.setInnerHTML(element, data)
def writebr(text):
write(text + "<br />\n")
data = ""
element = DOM.createDiv()
DOM.appendChild(getBodyElement(), element)
If you have followed the advice above of the previous question,
and have installed Firebug, then just insert a "print" statement, exactly
as you would in "standard" python. All output is directed to "console.write",
where Firebug will add an object called "console" to the global namespace
of your browser, and will "write" anything that goes to that console.write()
function into a special debugging window. If you haven't installed Firebug,
and you use "print", you will get an error (because there will be no object
called "console") in your browser's global namespace. So make your life
easier, and install Firebug. or not.
A Window.alert is the easiest but also the most annoying. It has the advantage however of not disrupting the screen layout. Perhaps some day someone will do something really sophisticated, like provide a "logger" module which throws up a nice separate window.
In the Immortal Words of Bjorne Again, at the free concert on Parker's Piece, Cambridge, in the mid 1990's, "Tough Titty: We Play Abba, Now". But seriously - this is a Desktop-like Widget Set. You use the high-level API. Why would you care if the low-level implementation, which you're never going to have to get involved with, uses HTML Tables instead of your personal preference, CSS "div" pseudo-tables?
Also, think about this: your personal preference, for CSS pseudo-tables, is based on an aversion that was brainwashed into you from having to hand-code and hard-code HTML markup. If you use hand-coded hard-coded HTML in Pyjamas for complex layout, you're really doing something wrong. The whole point of Pyjamas is to leverage the simplicity and ease of the Python programming language, along with a declarative programming style, to create an application in terms of Widgets, not in terms of HTML.
Not only that, but the whole reason why CSS pseudo-tables are recommended over HTML tables is because of lack of control over layout. Well, with the declarative programming style from Pyjamas UI Widgets, that lack of control when compared to static HTML is more than adequately compensated for. For example, you can easily use Window Resize Change Notify to completely restructure the application layout, dynamically (see lkcl.net for an example, including source), or you can just resize the Grid itself and its child widgets to fit 100% on-screen, as is done in the Pyjamas Mail example.
Then, also, there's what happens when you create a CSS pseudo-table, and a user shrinks the screen size. What happens? The layout goes completely haywire, because by hard-coding the width of the outer DIV, the inner items now have nowhere to go, and thus your site looks absolutely rubbish. Summary: CSS pseudo-tables are not the panacea you were expecting.
So, the short version is: Pyjamas U.I. Widgets provide far more flexibility and better layout than either of the two "plain" / "static" HTML solutions. Ultimately, if you really don't like the HTML-based widgets, feel free to create your own, and submit a patch.
Pyjamas is a compiler - it's a specialist tool that focusses specifically on the job of turning python into javascript. It does not include "compression" technology. That task is done by specialist technology such as the "YUI Javascript Compressor", the use of which will make it damn hard for you to debug an application as it completely trashes all of the names of functions and variables. So only make use of compressors if you absolutely have to.
HTTP 1.1 GZip Compression is usually enabled by default in both browsers and Web Servers, giving anywhere between an 8:1 and a 10:1 compression ratio in network traffic of pyjamas-compiled output. So, although the output from pyjamas looks scarily large, it's actually not as bad as it looks. 500k is not uncommon: the actual amount of network traffic can be as little as 50k to 80k, which you can verify by installing a network sniffer on your network. So, you actually get the best of both worlds: human-readable javascript and efficient transfer of your application to the users.
If for example your app is so large that you are hitting, for example, the limits of GAE, you can switch on "dynamic module" compilation (pyjsbuild -m). This option will split your app into several shared javascript files, one per python module. It gives something like a 65% reduction in the size of the application cache files, across the five supported browsers (Opera, Safari, Netscape, Old Mozilla and IE). It's only just been added (to Pyjamas 0.5) so a) be advised b) watch this space.
You should immediately stop trying to do too much, and eliminate pyjamas from the equation. Download jsonrpclib.tgz and add some python-based client-side code to the server-side testing. As you are a good web developer, who follows good code standard practices, this should have already occurred to you and it just temporarily slipped your mind that there should be an automated test suite based on something like jsonrpclib.tgz which you can use to prove to yourself that the JSONRPC server-side services of your app are absolutely perfect. You already considered the distinct advantages of being able to do automated tests such as pretending to be a user, interacting with the server-side forms, adding and deleting of records etc., but you had juuust not quite got round to doing that yet. well - now you have to.
Once you have demonstrated to your satisfaction that there is nothing wrong with the JSONRPC services, you can then reintroduce Pyjamas, as a second client, into the equation. The difference between then and now is that you now know that there is nothing wrong with the JSONRPC services, server-side. So, anything that's wrong has to be something like you've specified the wrong URL in the use of the pyjamas.JSONService module. Check that the URL is the same as the one that you used in the client-side usage of the python jsonrpclib.
You have to remember that you are using AJAX, with JSONRPC. So, the same standard rules apply: you can not access AJAX URLs other than those which match the URL from where the web browser downloaded the HTML and the Javascript. In other words, if your app is downloaded from http://fred.foo.com/myapp.html, then you can not put http://fred.foo.com:8080/jsonservice as the URL for the JSONRPC service, you can not put http://somewhere.else.com as the URL. It has to be http://fred.foo.com/somewhere.
Welcome to the world where people used to use AJAX to do cross-site scripting attacks, downloading viruses and doing phishing attacks and other crap, but can't any more, and you, as a developer, have to pay for that.
You should have read the CHANGELOG, which says this:
convert app "loading" to require the use of "if __name__ == '__main__'"
bringing pyjamas into line with "standard" python. apps can convert with
contrib/pyjamas_0.4-0.5_upgrade/add_name_main.py to add a small codefragment
at the end: "app = MyApp(); app.onModuleLoad()"
In other words, Pyjamas 0.4 and below used to spoon-feed you by calling a function "onModuleLoad()" in the exact same class as named after your application. As this is somewhat tacky, and places an unnecessary restriction onto how you can lay out your app, it was removed, and replaced with something that is much more akin to how a "standard" desktop python app would work.
The consequences are that your apps will, if you don't explicitly do anything, do absolutely nothing. So, when you get a blank screen, that is actually technically correct, as exactly the same thing would happen with a standard python app! Declare an instance of your app's class and call its onModuleLoad() function.
svn r785 or so started supporting XULRunner (python-xpcom) as well as pywebkitgtk, and underwent something of a minor code-shuffle, to make the style of PyJD apps look much more like PyQT4 / PyGTK2. So, for example, instead of gtk.main() you would do pyjd.run(). There's also some "setup" required, which kick-starts the underlying web engine into life. In a web browser (PyJS) of course the web browser is already running (duh) so pyjd.setup() and pyjd.run() do nothing, in PyJS. The functions still have to be there, of course, so that the app can be identical under both PyJD and PyJS. To convert apps to use PyJD, add three lines:
# at top:
import pyjd # this is a dummy in pyjs and has no effect
# rest of imports
...
...
# declare classes etc.
...
...
# at bottom:
if __name__ == '__main__':
# equivalent to starting a web browser, does nothing
# in pyjs, because duh, you're already running the web
# browser.
pyjd.setup("./public/{thehtmlloaderfile}.html")
...
...
# last line
pyjd.run() # equivalent to gtk.run and does nothing in pyjs
Not being funny or anything, but unless you have the resources of google or lots of money or lots of time, or you can gather enough people to make it so that everyone has less work to do: you don't.
You are not in Kansas any more. Pyjamas is declarative-style programming, using a "real" programming language. All those widget-sets were designed to be driven from inside HTML (a style of web development which, using Pyjamas, you have just left far behind) and by inserting javascript snippets into the HTML. If you try that with a Pyjamas app, you are not only likely to get yourself into an awful mess, but also you will be unlikely to run the same (python-based) app under Pyjamas-Desktop, as you will still have a Javascript dependency. You can run javascript under Pyjamas-Desktop but it's not easy to interact with (the python code) which is why we went to all the trouble of replacing all the javascript with equivalent python, doing exactly the same things with python-DOM bindings rather than javascript-DOM bindings.
Shoe-horning an alien AJAX toolkit into Pyjamas takes a considerable amount of attention to detail, and is also likely to have unintended side-effects as the two interact. Not only that, but you are in for a bit of a shock when you actually start looking at the number of lines of code in some of these javascript "rich" widget tooklits, and an even bigger one when it comes to linking the two together.
Take gwt-ext as a successful example of a wrapper between GWT and ExtJS. The "startup" glue code is 8,000 lines of dedicated javascript, the sole purpose of which is to get extjs initialised in a way that's compatible with GWT. 8,000 lines of javascript is about 70% the size of the entire pyjamas codebase, including widget set and compiler, at the time of writing. Then, the "wrappers" are a further whopping 80,000 lines of Java-javascript hybrid.
So, at the end of all that work, you have a wrapper which is itself a monstrous hybrid to maintain, which will need changing every time the Javascript Widget Library API changes, and, on top of that, if the Javascript Widget Library doesn't do what you want, you are screwed, because the whole reason why you're here working with Pyjamas is because you prefer working with python instead of Javascript. And if there's a bug - one that wasn't introduced by the custom-written wrapper - in the Javascript Widget Library itself, then you still have to delve into Javascript and fix it.
Overall, then, does it not make much more sense to rewrite the "pretty" widget in python, and contribute it to the community under the same license (Apache 2.0) so that everyone else in the Pyjamas community can benefit from it and help you improve it? Especially since the amount of code that you will be writing will be significantly less than if you tried the same thing in Java or Javascript.
So, instead of hurting yourself with javascript, perhaps you might like to consider enjoying Web programming, using python?
Yep. Someone didn't bother to check that python-hulahop actually worked, in Ubuntu 9 before uploading it. You'll need to rebuild the python-hulahop package, from source:
>https://bugs.launchpad.net/ubuntu/+source/sugar-hulahop/+bug/390475 > > Just to be clear I'm running from svn and it works on Ubuntu if you > rebuild python-hulahop to get the python 2.6 bindings you don't need > to set the python path to xulrunner. nice one michael - thank you for investigating.You can download a couple of .debs here for ubuntu 9, i386 architecture.
You're comparing apples and oranges. You're comparing a community-led effort against a corporate-funded one; you're comparing a good couple of hundred thousand lines of code against tens of thousands; you're comparing a strongly-typed language against a dynamically-typed one; you're comparing a system which is tightly integrated into the Eclipse IDE against one which follows the unix ethos to "do one thing and do it well".
you really do need to look at the differences between the GWT infrastructure and the Pyjamas infrastructure. take a look for example at GWT's i18n and l10n internationalisation support: it's _tens_ of thousands of lines of code, and _hundreds_ of files, supporting over one hundred individual languages, each with number formats, date formats and so on. pyjamas internationalisation support: a pattern, comprising about .... 50 lines of code, because in over a year of development, only two people have ever asked about how to do internationalisation of applications.
our focus, as a community effort rather than a google-corporate-full- time-multi-man-team-funded effort, is therefore on the tools and the infrastructure that _we the contributors_ need and enjoy working on, which is a much smaller subset of functionality than "that which 'employees of google' are tasked with".
so, like lovelysystems, who have some amazing python and javascript engineers, you should utilise pyjamas if a) you feel that the use of GWT's infrastructure and libraries is not going to be worth tolerating the pain barrier of java b) you are prepared to dive in to the (very compact and readable) pyjamas libraries if the code doesn't do what you need, and to contribute.
There's a simple answer: the regression tests these regression tests actually run under the standard python prompt, so you add a test, run it in standard python, then compile it and test it in the browser.
we are also working to get the regression tests to run under spidermonkey (the mozilla js command-tool), python-spidermonkey (the python bindings to the spidermonkey library) and pyv8 (the python bindings by flier liu - http://code.google.com/p/pyv8 - to the google v8 library).
once _that_ is done, then there is the plan to start running the STANDARD http://python.org regression tests, all 25,000+ of them, through the pyjamas compiler. yes, this is possible. basically, pyjamas becomes a python accelerator, by translating to javascript and using the JIT google v8 engine to execute the resultant code.
Ultimately, though: trust is always given. In other words: it's entirely up to you.
See MS KB974455. Basically: nothing to do with pyjamas. Apply known MS patches.