Ugh. That's all I can say. I spent a few hours the last few nights trying to get GoogleCal able to add events. I was finally able to do so with some help from Teddy Payne and a nice fellow on Google Groups. But wow. What an experience after working with the Yahoo services. How bad was it? This is how you add an event in Google's Calendar API.
-
First you make a request passing in your username and password. This returns an authentication string.
-
Then you make a second request where you pass in your event data. The funny thing is here that Google says they may or may not return a redirect. In all my tests, it did return a redirect and you need to grab another authentication string called a gsessionid.
-
Guess what? Now you make a third HTTP request passing the same event data again.
That's right - it takes three HTTP requests to add an event. Now I was able to cache the first one at least, but wow. What a royal pain in the rear. I mean - seriously - could they make it harder? Maybe I'm just not "Google Smart".
Anyway - enough complaining. I've attached a zip of the new GoogleCal.cfc. I have not updated the core zip. I'd like folks to give it a quick test if they can (code snippet below). I don't think it is very stable yet, but give it a try.
<cfset title = "Test Event 2">
<cfset description = "This is a test event.">
<cfset authorName = "Raymond Camden">
<cfset authorEmail = "rcamden@gmail.com">
<cfset where = "Mars">
<cfset startTime = createDateTime(2006, 9, 30, 3, 0, 0)>
<cfset endTime = createDateTime(2006, 9, 30, 3, 30, 0)>
<cfinvoke component="#application.gcal#" method="addEvent" returnVariable="result">
<cfinvokeargument name="username" value="rcamden@gmail.com">
<cfinvokeargument name="password" value="imnottelling">
<cfinvokeargument name="title" value="#title#">
<cfinvokeargument name="description" value="#description#">
<cfinvokeargument name="authorname" value="#authorname#">
<cfinvokeargument name="authormemail" value="#authoremail#">
<cfinvokeargument name="where" value="#where#">
<cfinvokeargument name="start" value="#starttime#">
<cfinvokeargument name="end" value="#endtime#">
</cfinvoke>
Archived Comments
Ray,
It was good fun trying to sort through the returned results. The Google API instructions are not the best when explaining how to consume and connect to it.
I look forward to possibl contributing perhaps a couple helpful methods for the API.
This type of API is really going to help users who want to programmatically manage their google calendar from a CF app.
Thanks for taking your time to humor me!
Always,
Teddy
Sounds slow Ray
TJ: Well, I do cache the first hit. For the next two - well, I can't do anything about it. In my testing however it still seemed to work pretty quickly. I just think it's silly.
hmmm... getting a Google Calendar Authentication Error.
If you can, directly email with your test script. I'll keep myself out of your personal data of course.
let me try straight invoking it - i was trying to tie it in to my gCal Flash Form, but let me test directly first...
success when i just run the cfinvoke...must have goofed up on the flash form somehow.
I found the API pretty responsive in my tests yesterday. I will test it again tonight and report the results or Ray can do it too.
I'm using the Google Maps API, but overall, I've found Yahoo APIs to be easier to work with as you've shown in your recent examples. The documentation and community support seems to be better on the Yahoo side.
Ray,
http://groovy.codehaus.org/...
Am not sure if this is too Java heavy, but it seems that well, this is indeed some very goovy code to hook into the Google API and data.
I was looking at this after finding the link to Groovy from the Freemind Wiki. Freemind is a very goog Open Source Mind Mapping program.
It's great to see work on a CF library for Google Calendar.
You can also 'cache' the result of the second request as well.
In step #2 of the processes listed above, when a gsessionid is returned, you should also get a cookie named 'S'. Store this cookie and use it for further requests. This greatly lessens the chances you'll get future redirects.
Interesting. I wonder why this wasn't documented anywhere?