21 Feb 09 Event Calendar – Experiments with Google Calendar
I haven’t had a lot of time to explore implementing an event calendar with Google Calendar, but I did try a few things out. First of all, it is pretty easy to embed a Google Calendar into your website:
Google Calendar Embedded on Website
As I mentioned in the last post, I downloaded the Google Python gdata client library. I wrote a small Python script based on the provided example code. I was able to add events to my calendar from this Python script:
import gdata.calendar
import gdata.calendar.service
import gdata.service
import atom
import atom.service
import time
cal_client = gdata.calendar.service.CalendarService()
cal_client.email = 'xxx@gmail.com'
cal_client.password = 'xxx'
cal_client.source = 'Google-Calendar_Python_Sample-1.0'
cal_client.ProgrammaticLogin()
title = 'My Test Event from Python'
content = '''This is the content of the event in some fashion.
<a href="http://google.com">My Link</a>
http://surfguitar101.com.
<b>Bold</b> text.
<p>Here is a paragraph.</p>
<p>And another</p>
<ul><li>Item 1</li><li>Item 2</li></ul>
<img src="http://surfguitar101.com/modules/Forums/images/smiles/icon_cool.gif" alt="Smiley" />
'''
where = 'An undisclosed location.'
#cal_path = '/calendar/feeds/default/private/full'
cal_path = '/calendar/feeds/xxx@group.calendar.google.com/private/full'
event = gdata.calendar.CalendarEventEntry()
event.title = atom.Title(text=title)
event.content = atom.Content(text=content)
event.where.append(gdata.calendar.Where(value_string=where))
# Use current time for the start_time and have the event last 1 hour
start_time = time.strftime('%Y-%m-%dT%H:%M:%S.000Z', time.gmtime())
end_time = time.strftime('%Y-%m-%dT%H:%M:%S.000Z', time.gmtime(time.time() + 3600))
event.when.append(gdata.calendar.When(start_time=start_time, end_time=end_time))
new_event = cal_client.InsertEvent(event, cal_path)
As you can see, I was testing to see if I could insert HTML into the event, and if it would display correctly on the Google Calendar. According to my tests, it does appear you can insert simple HTML. The only thing that did not work was <img> tags. Unfortunately, if you log into your Google account, and then go to your Google Calendar and try to edit this event using the Google GUI, all HTML will be stripped. This will make it difficult to edit an existing event and will probably steer me towards keeping the user added event around in the database for future editing until that event has expired.
I have to say I am not really impressed with the Python API. It seems rather “un-Pythonic”. Why do I have to construct atom objects and assign them to the event title and content fields? The API should do this for me. Why do I have to format my own date strings? The API should accept Python datetime objects and do that for me. Pretty disappointing coming from Google.
I am starting to see a way forward here. I think I need to do the following:
- Build a view to let registered users submit events. Allow the event description to be submitted in Markdown format, but warn the user that images won’t work.
- In the admin interface, allow the admin to approve events by marking a boolean field in the database.
- Build a custom admin view that contains a form that prompts the admin for their Google password, and batch inserts all approved events to the Google calendar.
Initially I will support only non-repeating events. I’ll go back and try to add support for repeating events in “phase 2″ once I get the above functionality working.
I was looking through the Django docs and came across a new feature in trunk that allows you to extend the set of URLs supported by a model in the admin section. This will allow me to create a custom admin view to insert the events. I think this is just a new way of doing something that was already supported, and is described in the online Django book. I’ll have to update my working copy of Django trunk and try this out.
15 Feb 09 Event Calendar – Use Google Calendar?
I wrote a pretty complex event calendar for my PHP-Nuke site. You can find it here on sourceforge. It allows users to submit events for admin approval. Once approved they appear on the calendar. The application does all the calendar logic, including the drawing of the calendar. Repeating events were added, and they are pretty hairy as well. There are some pretty massively complicated SQL queries in that code, not to mention some crazy PHP logic to figure out if repeating events belong on a particular calendar view. It is also possible to make exceptions to repeating events.
I’ve been thinking about how to port this to my new Django powered site. One day I stumbled across the Google Calendar API, and I’m thinking about leveraging this. I will let Google handle all the crazy calendar logic, as they are no doubt better at it than I am. I will still let users submit events to the admin, but this time I will use the Google API to add events to a Google Calendar. Google can do the heavy lifting for me when it comes to displaying events and handling repeating events. Am I cheating by doing this? Ha. Well there are some advantages to this idea for my end users:
- Anyone can display the site calendar on their blog or website. It won’t just be available on my site.
- Users can use the RSS feed that Google generates. It was always on the to-do list for the existing calendar to add this feature, but I never got around to it.
- If a user has a Google account of their own, they can add events from the new calendar to their own calendars.
- Google can configured to notify users by email or SMS text messages of events.
So I’ve decided to explore this approach. If it doesn’t look like it will pan out, I will fall back to a more direct port of my old PHP code.
This approach isn’t without its own challenges. I can see right now I am going to have to think carefully about how to provide authentication to the Django code to allow it to add events to one of my Google calendars. I obviously don’t want to hard code my Google login and password in the Django application.
I think I will attack this problem in phases:
- Get a calendar to display on my site. This should be pretty easy; just use Google’s iframe code.
- Add an event through the Python API to gain experience with it. This is prototype, throw-away code.
- Build a front-end interface to let users create events, as was done in the PHP application.
- Think about an interface for letting users change or edit events. This could range from just sending an email to the admin, who could make the changes using the Google interface on one end of the spectrum, all the way to letting Python code programatically making the changes.
- Add support for repeating events.
I’ve already downloaded the Python version of the gdata library and have started reading the API docs. It looks interesting. Once I get familiar with this library, it looks like I could use it for other cool things like interfacing with YouTube and Google Docs.
14 Feb 09 Member Map Part 2
I’ve gotten the Member Map application ported to my Django powered site now. This was pretty straightforward and a lot of fun because of the Javascript aspect. Let me address the points I made in part 1 of this post, below.
- Leveraging jQuery. I did make use of jQuery for the client side Javascript. This really did simplify things. In the old version of the code, I had a 282 line Javascript file. The new version weighs in at 161 lines, which is 57% the size of the earlier version.
- Use of JSON encoder library. It turns out that Django includes a version of the simplejson library already. This is used in Django’s serialization feature. I probably could have used this feature, but I didn’t need to serialize an entire model, and wanted to rename some of the fields. So I simply did a “import django.utils.simplejson as json” and went to town. My server side code was now much simpler than the previous version where I encoded by hand.
- I did continue to use the markItUp! editor to let users edit their message to go along with their location. I learned that the size of the editor is easily adjusted through the use of CSS. So I was able to override the default size of the editor by including my own CSS style sheet below the default sheet.
- Reducing complexity. Here is where it got interesting. I decided to add a “json” field to the MapEntry model. This field is populated whenever a model object is saved by providing my own save() method. Inside my save() I use Django’s template render_to_string() to render the HTML message that appears in the pop-up balloon on the map. This consists of the user’s avatar followed by a message that is marked up in Markdown. I then build a JSON representation of the MapEntry using Django’s simplejson. This representation consists of the following fields: name, location, latitude, longitude, and the HTML message. By pre-saving all of this information, it makes it much more efficient to retrieve 200+ users’ information when the map is first loaded. In the view function, I make use of the values_list() queryset method to retrieve all the json fields. I don’t need the ORM to convert each MapEntry to an actual Python object.
Another thing I did differently for the port was when a user updates or adds their position on the map, I don’t reload the entire map. I just adjust their information to reduce bandwidth with an AJAX post. I’m not sure why I didn’t do this before, perhaps because it was to tedious to do without jQuery. It was just easier to reload the whole thing.
This was all well and cool, doing all this pre-computation, but what happens when a user changes her avatar? Her entry on the map will likely have a broken graphic. No problem. Here I took advantage of Django’s signals. I attached a signal handler to listen for changes to the UserProfile model. Whenever the UserProfile is saved, my signal handler runs and re-saves the corresponding MapEntry to regenerate the JSON. Very slick.
And finally, another thing that I learned about Django was that simple_tags can have defaulted arguments. I added an argument to my avatar tag so that I could apply CSS to the generated HTML img tag if needed. In the Member Map pop-up balloon, it looked nicer if the avatar was floated to the left.
So all and all, again, I’m very happy with how easy Django makes writing an application like this. Using jQuery was also a big productivity booster.
Here are some screenshots. You can also see the new Blueprints CSS in action as well.
Member Map 1
Member Map 2
06 Feb 09 Member Map Part 1
I started working on the Member Map application last weekend. This will be a port of the PHP-Nuke module I wrote, which you can find here. In a nutshell, this application displays a Google Map on your site, and allows site members to place markers representing their location on the map. If you click on a marker, a balloon pops up which displays the user’s avatar, a link to their profile, and a short message that they have typed previously. The Nuke version of this application is a big hit on the current site, and last time I checked, we had over 220 members on the map.
The existing application consists of the PHP-Nuke code, written in PHP, on the server side, and a fair amount of Javascript on the client side. All interaction with Google Maps is done through the Javascript code.
For the port to Django, I want to do a couple of things different.
- Leverage jQuery in the client-side Javascript. The existing version was written before I was aware of Javascript libraries, and it is all “vanilla” Javascript. By using jQuery, the amount of code I have to write will be much smaller. And by taking advantage of jQuery, it should be more portable and browser robust.
- On the server side, the existing application did not use any JSON encoder library. I simply constructed the JSON by hand. I can’t remember why I did this. I think it was partly because I didn’t know any better, and partly because the PHP version I had on the original hosting server may not have had it. I will explore what Python and/or Django options exist.
- I’ll leverage the markItUp! editor that I’ve been using for comments to let the users enter Markdown comments. I’ve used this in the last couple of apps I’ve written and it will be easy to implement. The only concern with doing this is the user may be tempted to write a lot more than in the older app, and it may make for large “balloons”. We’ll see.
- I want to make the new application less database and computationally intense than the older version. I don’t have any problems running the current version with 200 users, but I think I could do it a bit smarter this time around. This means I am going to try to save marked up and JSON encoded strings in the database rather than compute them on every page load. I am also wary of instantiating 200+ map entry model objects with the Django ORM (albeit in a loop) just to generate the JSON. Luckily Django lets you use raw SQL when needed. But in this case I think a simple use of the values() method will really be useful here.
So, those are my going in goals. I’ve already started working on this, and I’ve learned a lot so far. In the next post or two I will detail the progress and what problems I ran into.
