They’re sometimes using multisafepay for adding online payment for sites. They’re quite happy with it. It is relatively simple. The payment, like with most such providers, takes place on the payment provider’s website. This is often perceived as trustworthy by customers.
They have an xml api. For that, they had a couple of api implementations. Not in python, though.
So he investigated it and a transaction is a pretty straightforward exchange of urls and xml messages.
He made a python api based on the xml structure and their own provided non-python api examples.
It is not on pypi yet, but Jan Murre might put it there if there’s interest.
Jan-Jaap never uses Django, Boaz does :-) They got together to integrate fanstatic into the django world.
Jan-jaap presented fanstatic at the last python
and css resources available in python. You can just import resources in python
import js.jquery). Those resources are included in python packages, which
means they can have dependencies! Just specify something like
jquery.need() in your view.
Django doesn’t really include wsgi support out of the box. It does everything itself. Don’t do that! Just use wsgi. And use all the existing wsgi goodies. Why use your own gzip compressor when there’s one in wsgi already? Learn from zope/grok and become more open!
Fanstatic uses wsgi middleware to actually inject the js/css into your rendered pages. Django requires apache settings as django itself is too slow to host it. Just let wsgi do it.
django-fanstatic uses four integration hooks:
7 May there’s a hackathon in Rotterdam.
“A network of Python/Django professionals that have each others backs in case of ‘Bus failures’”.
(OK, I’m just re-reading a book about Roman history and I’ve just ended up at the part about the Punic wars. Well, it isn’t that kind of punic :-) )
When you’re a one-person company, the customer can get a bit squeamish when he thinks about your untimely demise or unplanned departure. What about his site, then?
That’s why the idea about a group of professional companies and developers willing to help each other in times of crises came up. The purpose is to provide a backup when the shit hits the fan. It is an answer to “what if” questions from clients or bosses.
When you join PUNIC, there are some requirements. For example always up-to-date documentation. On client, purpose, context, code, server setup. Some of the content might be confidential, so you have to give it to only one of the other PUNIC members.
If you’re interested: send an email. Directly to Alex; or to the PUN mailinglist.
(Jan Murre mentioned ZEA partners, a formerly zope-based European combination of companies with at least partially the same goal).
Django forms are cool, but they’re not easily composable: you cannot take a couple of them and combine them into one form. A common example is to include a foreign key’s form into the form of the items that has the foreign key: doesn’t exist.
Sometimes you can get by with making a custom widget. He demoed an example widget to encourage us to build our own widgets when we need them.
A suggestion from the audience: look at http://code.google.com/p/django-uni-form/
There are only a few tickets left!
The keynotes are booked already. And there are quite a lot of interesting talks already. Deadline for talk submission next Friday.
What’s still needed: a mobile app for the conference.
The audio-visual and wifi stuff is arranged already. And we’ve got a professional monitoring it, so it should be good.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):