If you use Google AppEngine and want to use the sites and sitemaps contrib apps you can use this modified version of the google-app-engine-django helper here: http://code.google.com/p/dherbst-app-engine-django/wiki/Sitemaps
Posts Tagged ‘django’
Using django.contrib.sitemaps on AppEngine
Monday, May 17th, 2010Bit by ModelForms
Tuesday, January 26th, 2010Put all the callable defaults you want into a Model, the ModelForms aren’t evaluating them properly in Django 1.0.4. Luckily there is a patch: http://code.djangoproject.com/ticket/11940
Google App Engine – django login_required Google Accounts
Tuesday, September 9th, 2008I like to use Google Accounts with App Engine and django. The django login_required decorator depends on the django auth model – so I rewrote it for use with Google Accounts authentication.
I’m not sure if it is better to cache the create_login_url or not, but this works well enough for now.
from django.http import HttpResponseRedirect from google.appengine.api import users def login_required(fn): """ checks to see if the user is logged in, if not, redirect to login """ def _dec(view_func): def _checklogin(request, *args, **kwargs): user = users.get_current_user() if user: return view_func(request, *args, **kwargs) else: return HttpResponseRedirect(users.create_login_url('/')) _checklogin.__doc__ = view_func.__doc__ _checklogin.__dict__ = view_func.__dict__ return _checklogin return _dec(fn)
Soap in your eyes can be painful
Monday, August 18th, 2008Coming from the .Net world to django and writing web services for consumers is a welcome change. .Net SOAP web services require a lot of designing and work to make them expressive yet perform well – whereas django REST services flow much more easily. However, whereas in .Net you normally throw Exceptions which turn into SoapExceptions – with django and REST I find I have to write documentation for clients/consumers explaining how to check results:
- Success
- Failure case 1
- Failure case 2
- and so on…
So, one of the painful aspects of REST is there is no predefined concept of an exception.
Another painful thing with REST I need to get used to is there is no ‘framework’ for calling REST services. Looks like an opportunity to define a common calling convention – but the drawback is I’m dictating customers/consumers use a factory-h library – because the calling conventions are well defined. If there is one thing I’ve learned – let the customer/consumer write it – guide them, but don’t write it for them. The reason being, there’s always something they want, or think they need, that I never would consider a priority.
The end result for me is that REST is quicker to write, but requires more discipline.
After kicking myself for not implementing a versioning scheme in the first .Net soap web services I designed, it’s something I started doing since. I see it over and over with the other services I’ve worked with like Amazon. I like putting the design year into the REST url: domain/2008/service-name/operation/instance
Years seem much easier, and let you know how long they’ve been baked in than version numbers.
old django newforms
Saturday, August 16th, 2008For those of us not using django 1.0 (yet)
Newforms are great, and ModelForms will be a welcome release. However, I find I can’t utilize the over simplified workflow:
myform = MyForm(request.Post)
myform.save()
because I have to process one or more fields before saving. But there aren’t a lot of explicit examples – for some strange reason, you are required to call .is_valid() on the form before trying to access the clean_data, like this:
myform = MyForm(request.POST)
myform.is_valid() # this creates the clean_data dictionary
attribute = myform.clean_data['attributename']
Seems like the sort of thing I would code an exception into the clean_data accessor – ‘you must first call is_valid() before using’. Maybe that’s just me.