I was really looking forward to get a chance to play with Google Wave. If you have not heard about this, Google is experimenting with a new means of communication and collaboration (to destroy any remains of your unused time!). Watch the video of the demo from Google IO conference to get a feel for the technology.
The catch line is - How would email be if it is designed today ?
Being Google, they are fairly open about the entire technology.Google Wave is a collection of several components which work in concert to bring us this amazing way to collaborate and communicate. There is the wave server (which hosts the waves. Google provides an implementation and others are free to implement it in their own control), federation protocol (which is open specifications protocol and allows the servers to talk to each other), the client (typically your web browser which you use to interact with the wave server, but there is a sample text client and emacs based client in development as well!), the gadgets (small pieces of code that are embedded in documents and provide rich look and feel and additional functionality to the wave) and the robots (robot participants in the wave which can do cool things like correct spelling as you type, syntax highlight code while it is being pasted in the wave, translate language etc.)
I have spent some time in developing a robot called Nokar (meaning assistant or servant in Marathi/Hindi) which can do several things when invited to a conversation - Insert images based on specified keywords, translate text between a set of 20 languages among some other geeky functions. The intention was to learn about the robot protocol. I also created some pages which use the embed API. This allows any web page to embed a wave conversation (or a subset of it). I am also going to experiment with the Gadgets in the next few weeks. I will try to document my process in next few posts.
I just upgraded django tree which recently merged in the unicode support. This immediately broke django templates for venus. Here is what you need to change in planet/shell/dj.py to account for new django changes:
> ss = t.render(context)
> if isinstance(ss,unicode):
This is probably due to render returning unicode strings which need to be converted to byte-streams.
Update: I found out that my changes broke it for people using older version of django. I have updated the patch above to account for that.
I needed to reset the django admin password and found this page which tells us how to do this. It did not work for me, however I tried to get the user object explicitly, reset the password and save it and it worked!
Here is a session describing the behavior:
> python manage.py shell
In : from django.contrib.auth.models import User
In : u=User.objects.all()
In : u.password
In : u.set_password('testme')
In : u.save()
In : u.password
In : q=User.objects.get(id=1)
In : q
Out: <user : root>
In : q.set_password('testme')
In : q.save()
In : q.password
Maybe this is related to queryset caching, which would print the same password even after calling set_password. But it looks like in the first method, the password does not even get written to the database. This might be a bug. I will need to run more tests and report (or possibly patch) it...
Update: Perhaps I am not clear in the above post. The weirdness is that in the above two scenarios u and q should essentially reference the same user object, but calling set_password (and later save) method on the u reference does not seem to work (i.e. the password attribute remains unchanged and changed password cannot be used on the admin pages) but calling the same method on q reference seems to work!
Update2:I got it finally. Thanks all (Esp SmileyChris) ! every array slice is a new query! so in the first solution, I need this to make it work:
u.password # to display current hash (Query #1)
q=u # (Query #2)
u.password # (Query #3) this should print updated hash!
In the django project settings there is a key called MIDDLEWARE_CLASSES which is a tuple of strings implementing the middleware methods. Django base handler (TBD explain what this class does) reads this setting and initializes three of its own attributes: _request_middleware, _view_middleware and _response_middleware. It goes through the list of middleware classes instantiates each of them and adds the bound method process_request to the _request_middleware attribute, process_view method to view_middleware and process_reponse method to _response middleware.
If the middleware class method returns something (indicating that it has taken some action), the basehandler get_response method returns immediately. Otherwise it proceeds further.
There are 4 middleware classes built in:
- AdminUserRequired middleware class implements the process_view method and silently returns if the user in the request is logged in and is a valid admin user. Otherwise it returns login page with appropriate error message.
- CommonMiddleware implements process_view and process_response methods. process_view rejects forbidden user-agents and prepends URL with www and appends trailing slash if desired. process_response checks if there is a matching flat file present that can be sent for 404's and can also send email note to managers about broken links. process_response also manages ETags
- CacheMiddleware implements process_request to check pages (not containing any query string) against cache. process_response adds pages to cache as needed.
- XViewMiddleware (used internally for documentation) implements process_view and attaches 'X-View' header to internal HEAD requests.
Update: 10/14/2005. There are some updates to the middleware that ships with django and is now "officially" documented here.
Django framework has used some design patterns. There is a directory called decorator which currently has two decorators: (decorator is just a method which dynamically adds additional functionality to original method depending on the situation)
funcA = login_required(funcA)
This replaces the funcA with a function which checks if the user is logged in and calls original function if the user is indeed logged in and redirects the anonymous users to login page.
The original function is changed to look into the cached pages.
I was just about to abandon python and join the ruby camp to be able to use the wonderful rails framework for web application development. (They do have very good documentation and impressive video demo which you should check out!) But then came the announcement of Django. I really like the python language and feel that I can understand someone else's python code, (though ruby looks equally fascinating). I read through the tutorials and checked out the svn repository and worked with the tutorials. This framework looks easy to use and seemingly makes your application portable enough to use any of the underlying database backends (postgresql, mysql, sqlite) and webservers (apache, lighthttpd, twistedweb etc). The initial few days after the announcement, there were very hectic updates on the code and documentation front (with support for sqlite backend , standalone server and new tutorial and documentation about generic views and form fields coming in a matter of a couple of days). This has now gradually slowed down.
I decided to write a sample application (rebate tracking) and immediately hit some issues. I am trying to make the user registration and login/logout part work, but am not following how that is hooked into the framework. The users added with admin interface do not get recognized by the authentication code. Tried IRC help, but haven't been able to get anyone who can help. I am studying the code right now. I am going to look closely into the decorator and middleware code now. I will write about my progress here.